IPsec ゲートウェイ向け WireGuard プロファイル：代わりに何を尋ねるべきか

応答のないゲートウェイでのハンドシェイク タイムアウトは、通常、決して出会わない 二つのプロトコルを意味します。WireGuard のピアは Noise を話し、IPsec ゲートウェイは IKE を待ちます。正しいアドレスとポートでもそれは変わりません。

プロファイルでエンドポイントを再利用しても両者は橋渡しされません。次の一歩は、ゲートウェイを運用する人への依頼です。

最初の依頼：プロトコルのバージョン

IPsec は単一のワークフローではなく、一族を指します。IKEv2 と IKEv1 はやり取り、認証の選択肢、ネットワーク変更時の振る舞いが異なります。IKEv1 だけを終端するゲートウェイは、IKEv2 を提供するゲートウェイとはかなり違う動きをします。クライアント設定もそれに伴って変わります。

サービスがどのバージョンを終端するのか、標準準拠の実装か独自クライアントを持つベンダー版かを尋ねてください。OS のメニューはその答えを 一つのラベルの裏に隠すことがよくあります。ラベルはプロトコルではありません。

二番目の依頼：クライアントの認証方式

認証こそが実際の作業の大部分を占める場所です。サービスは、特定の拡張鍵用途を持つマシン証明書、ユーザー証明書、IKEv2 上の EAP 方式、または ID に紐づく事前共有鍵を期待しているかもしれません。どれが当てはまるかで、クライアントに必要なものが決まります。

WireGuard の秘密鍵はそのどれでもありません。特定の 一つのハンドシェイクで使われる Curve25519 の鍵です。どんな変換でも証明書や EAP 資格情報にはなりません。そう主張するツールは、ファイル名を変えているか、無関係なものを生成しているだけです。

RFC 7296 の IKEv2 仕様は、そのバージョンの実装が何をサポートすべきかを記述しています。運用者の曖昧な回答に対する参照であって、クライアント設定の手引きではありません。

三番目の依頼：信頼された ID と宛先

クライアントが見るべきゲートウェイの ID と、それを検証するトラスト アンカーを求めてください。次に、サービスが配布するプライベート範囲とリゾルバーを尋ねます。この二つの答えが、トンネルが実際に何を運ぶかを決めます。

それらがなければ、つながっている接続でも作業に失敗することがあります。リゾルバーが配布されていないトンネルでは、内部名が解決されません。トラフィック セレクターが欠けていれば、ハンドシェイクが成功していても宛先はトンネルの外に残ります。

エンドポイントの調査は、クライアントのエラーとは別の問いに答えます。関連付けのない到達可能なポートは認証を指し、到達できないポートは経路を指します。

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

クライアントを変更する前に、その調査を実行してください。ポートが応答し、それでも関連付けが失敗するなら、問題は資格情報かポリシーです。まったく応答しないなら、プロファイルの編集では解決しません。

両方のプロトコルを共存させる必要がある場合

両方のネットワークを管理することは、両方のプロトコルを維持する正当な理由です。通常の設計では、WireGuard と IPsec を別々のインターフェースまたは別々のゲートウェイで終端します。承認されたトラフィックはその間でルーティングされます。

その設計は信頼と認可の境界を導入するので、境界として明文化すべきです。どのピアが通過でき、どの方向で、誰のポリシーの下かは、ルーティングとファイアウォールの判断です。どちらのプロトコルもそれを提供しません。

それが違うのは、透過的な変換ではないということです。WireGuard 経由で到着したトラフィックは IPsec トンネルに再生成され、その間のあらゆるポリシーが適用されます。

まずサーバーのプロトコルと認証の要件を確定してください。次に運用者がサポートするクライアントと登録経路を使い、その間、秘密鍵を Web コンバーターに近づけないでください。