/var/log/hdk.log コメント

2025/07/21 のコメント

2025/07/21 の日記を表示する

• 2025/07/22 09:47:49 通りすがらない さん 『 IPsecは元々の発想が「遠隔サブネットを防護トンネルで繋ぐ」で、そもそもクライアントが一台ずつ個別に接続する想定じゃないし、接続相手の動的な移動・増減への対応部分がもう完全に不法増築状態なんですよねぇ。 』
• 2025/07/22 09:48:59 通りすがらない さん 『 一番基本的な「既知の遠隔サブネットを既知(≒グローバル固定IP)のエンドポイント間の防護トンネルで繋ぐ」だけなら普通に直観的にできているんだけど、今のご時世それだけでは使いどころが・・・。 』
• 2025/07/22 22:56:20 hdk さん 『 トンネルモードはそうですね... 日記で触れたトランスポートモードはサブネット云々ではなくて、L2TPなど併用しないケースで単なるホスト間の通信なんですけど、ESPはTCPやUDPヘッダーのポート番号を暗号化してしまうのでNAPTは手が出せない... 』
• 2025/07/23 00:43:08 通りすがらない さん 『 いえその、トランスポートモードがどーとかいう以前に最大に根本的な問題があって、IKEがauth.する時点では「使うべき鍵を特定するIDが外側IPしかない」んですよ。 』
• 2025/07/23 00:48:18 通りすがらない さん 『 実装次第でDNS引けるのは有りますけど、今度は鍵の照合発生(=IKE要求の受信)のたびに毎回鍵束全部のDNS引き直しとかいうわりとひどい事態。そして絞り込みが利かなければあとは総当たりしか手が無い。 』
• 2025/07/23 02:11:28 通りすがらない さん 『 この辺りの問題はPKE認証にしてcert使えば回避できるんですが、今度は証明書ファイルの取り回しが必須でパスワードのコピペでは済まなくなるわけで。大量展開ならむしろ楽になるとしても単発のトンネルには面倒。 』
• 2025/07/23 06:36:02 hdk さん 『 ID問題はIKEv2で大きく変わったので、IKEv1がdeprecated扱いの今はもう過去の話でいいのかなと思っていて... でもESPがNAPTを超えられないからNAT-Tを使う、ファイヤーウォールのフィルタリングが面倒くさいというのが変わらないんですよね。 』
• 2025/07/23 08:08:50 通りすがらない さん 『 確かにプロトコルの規格としては対処した筈なんですけど、現実の実装はIKE(1)用の構成機構の上にIKEv2を上っ面かぶせただけで鍵管理が1の頃のままだったりして、IKEv2を選択してもそういう風には使えなかったり... 』
• 2025/07/23 08:10:00 通りすがらない さん 『 ID payload 自体が1の頃にはトラヒックセレクタ(TS)と(本来は)同一視されていた部分で、トランスポートモードあるいは所謂 route based VPN しようとするとすぐにダミー(両側0.0.0.0/0とか)になる役立たずなので、 』
• 2025/07/23 08:15:06 通りすがらない さん 『 IKE(1)の構成機構として(最初からPSK認証は捨てて)IDを鍵選択に含めようとしても機能面でかえって束縛されるという悲しい話が。跡継ぎはもっと偉いんだぞ！ ちゃんと敬え！ と後から言われても歴史は覆りませんで。 』
• 2025/07/23 08:28:27 通りすがらない さん 『 勿論(構成情報の)後方互換性を投げ捨ててIKEv2専用に最初から作り直せばいいんですが、そこまでいくと今度は、どうせプロトコル自体が非互換なのにわざわざIPsecの形に収める意味は何か、という。わりと手遅れ感。 』
• 2025/07/23 11:18:19 hdk さん 『 それですよねー。トランスポートモードもなければパスワード認証も証明書もないシンプルなWireGuardがはやるのも納得です。 』

コメントを書く