稼働中の IPsec ゲートウェイから ike-scan が応答を得られない

そのゲートウェイは毎日スマートフォンとノートパソコンにサービスを提供しているのに、ike-scan はどのホストも応答しなかったと報告します。この出力は、IPsec がデバイスに存在しない証拠のように読めます。通常は、デバイスがプローブ内のすべての提案を破棄し、何も答えないことを選んだという意味です。沈黙も応答であり、ツールが返せる最も情報量の少ない応答です。

パケットは届いたか、一致する提案はあったか、別の何かがピアを拒否したかという三つの別々の問いを順に確認します。

ステップ 1: ツールが送る提案を読む

メインモードは、イニシエーターが受け入れるトランスフォームを列挙した SA ペイロードで始まり、ike-scan はコンパイル済みの既定値からその一覧を埋めます。既定のセットは意図的に古く、暗号化に DES と 3DES、ハッシュに MD5 と SHA1、鍵交換にグループ 1 と 2、認証に事前共有鍵を使います。AES も SHA-2 もグループ 14 もありません。AES-256 と SHA-256、modp2048 で構成されたゲートウェイとは何も共通していません。

実装によっては、一致しないプローブに NO-PROPOSAL-CHOSEN 通知 で応答します。単に破棄する実装もあり、未知のピアを雑音として扱う機器ではよくあることです。どちらにしてもスキャンは何も出力せず、その「何も」は外から見たフィルタ済みの UDP 500 とまったく同じであり、ike-scan プロジェクトのドキュメント も既定セットについてそう明言しています。

ステップ 2: 現代的な提案を一つ送る

既定のセットを --trans に置き換えます。属性形式は IKE の属性番号をそのまま取り、暗号化に 1、ハッシュに 2、認証に 3、グループに 4、アルゴリズムが鍵長を取る場合は 14 を指定します。出力は、変更レビューで読み上げられる一行です。

位置形式は同じ値を順番に運び、コマンドがシェルを通るときに重要になる括弧を避けます。

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

列挙するときはパケットごとに一つの提案では遅いので、妥当な値をループします。暗号化 5、7/128、7/192、7/256、ハッシュ 1、2、5、6、7、グループ 1、2、5、14、15、19、20、21、認証は事前共有鍵なら 1、RSA 署名なら 3 であり、実行する前に各コマンドを出力して、何がどの順序で提示されたかを記録に残します。

ステップ 3: 応答を解釈する

応答が証明するのはちょうど二つ、そのアドレスに IKE レスポンダーが到達可能であることと、提示した提案の一つが受け入れ可能だったことです。事前共有鍵や L2TP 層、ユーザーアカウントの有無については何も語りません。スキャンの成功は、その後のすべての段階が失敗することと完全に両立します。

運用しているゲートウェイでは、ここが本当に役立つ部分です。スキャンはデバイスがまだ受け入れる提案を教えてくれ、レガシーなトランスフォームだけに限られた結果はデバイス ポリシーに関する発見であり、クライアントを弱める理由にはなりません。

ステップ 4: 沈黙を解釈する

沈黙は見た目より弱い証拠です。すべての提案が拒否された可能性も、UDP 500 と 4500 がフィルタされている可能性も、バースト後にレート制限された可能性も、サービスがスキャンしたのとは別のアドレスで待ち受けている可能性もあります。その機器について何かを結論づける前に、ゲートウェイの IKE ログを、有効な資格情報ですでに接続しているクライアントと比較してください。

バースト時の挙動も、列挙が短い時間窓に多数のパケットを生むためにその一覧に入ります。最初の試行に答えてから静かになるゲートウェイは、提案セットではなく anti-DoS ポリシーを語っています。

ステップ 5: 証明したことを記録する

受け入れられた組み合わせをファームウェアのバージョンの隣に書き、関心のあるクライアントが既定で提示するトランスフォームと比較します。その二つの一覧の差が構成の問題であり、スキャンはそれを可視化しただけです。受け入れられる提案が選ばないものだけなら、修正はゲートウェイ ポリシーかクライアント プロファイルに属し、プローブではありません。

決して答えなかったプローブも、このデバイスがどの提案を議論する意思があり、どれをむしろ捨てたいかを示すという点で、何かには答えています。