割り当て済み仮想 IP 上の IKEv2 クライアントに到達する

IKEv2 で接続されたノート PC に対して、ゲートウェイがそのクライアントの割り当て済み仮想アドレスを使って接続を開始する必要がある。トンネルは上がっており、クライアントはゲートウェイの先のすべてに到達できるが、逆方向は依然として失敗する。この非対称性は正常であり、ネゴシエートされたポリシーが示すのは、どのアドレス同士が通信できるかであって、どちら側が開始できるかではない。ゲートウェイ起点の要求が機能するには、三つの条件が揃わなければならない。

トンネルは送信元アドレスを直さない

CHILD SA はトラフィックセレクタの組を一対ずつカバーし、その組の双方向のトラフィックを許可する。どちらのピアが先に IKE 交換を開始したかは示さない。もともとトンネルを待ち受けていたゲートウェイでも、選択した送信元と宛先がインストール済みのセレクタ内にあれば、最初のアプリケーションパケットを送信できる。要求が誤ったインターフェースから出ていく場合、その要求はトンネルの対象にならないだけである。

クライアントへのルーティングは必要だが、十分ではない。ポリシーが実際に使用した送信元を許可していなければならない。

インストールされたポリシーを読み、設定ファイルは読まない

動的割り当てはカーネルにインストールされる内容を変えるため、アクティブなアソシエーションとそのセレクタから確認する。

ipsec statusall
ip xfrm policy

status の出力には、接続名、割り当てられた仮想アドレス、そのピアに対して現在有効なセレクタが表示される。ポリシーのダンプは同じセレクタをカーネル状態として示し、パケット選択が実際に参照するのはこちらである。ゲートウェイ側のセレクタを、アプリケーションが使用する送信元と比較すれば、不一致は失敗をすぐに説明する。クライアントの現在のアドレスを読み、以前のセッションのものは読まない（VIP が再割り当てされると古いポリシーは無効になる）。

クライアントはパケットが届く場所で待ち受ける必要がある

サービスがループバックにしかバインドしていなければ、完璧なポリシーでも閉じたポートに届く。リスナーは割り当て済みアドレスか、ワイルドカードのローカルアドレスに置く必要がある。

ss -ltnp 'sport = :9090'
iptables -S INPUT

ソケット一覧はポートが仮想アドレスにバインドされているかを示し、ファイアウォールのルールは保護された送信元からの新規接続が許可されているかを示す。確立済み接続向けに書かれたルールは、ゲートウェイが開始する接続を許可しない。トンネル経由で到達したという事実はどのネットワークから来たかしか示さないため、サービスの認証はそのまま維持する。これらの要求は既存のトンネル内を通るため、自前の NAT の背後にあるクライアントでも受信ポート転送は不要である。

新しい方向を単独でテストする

クライアントからサーバーへの正常な要求は、この経路を決して通らない。ゲートウェイから要求を生成し、両端を観察する。

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

ルート検索は、ゲートウェイがどの送信元とインターフェースを使うかを答え、ポリシーが許可すべき値はこれである。キャプチャでは、要求がパブリックインターフェース上の平文 TCP ではなく、ESP の内側で出ていく様子が見えるはずだ。クライアント側では、復号後のトラフィックをキャプチャして、到着とサービスの応答を確認する。要求が ESP なしで消える場合は、クライアントのファイアウォールより先に送信元アドレスを疑う。

VIP が変わりうるので、鍵の再生成や再接続の後にテストを繰り返す。次のセッションまでしか機能しない経路は、機能する経路ではない。