デュアル WAN の VPN ポリシーはどのパケットに一致させるべきか

VPN を二本目のアップリンク経由でルーティングしたいという要望は、少なくとも二つの異なる作業を指しており、片方を直すポリシーはもう片方には触れません。一つ目の作業では、二つの端点の間の暗号化トランスポートが別の WAN アドレスへ移ります。二つ目では、接続中の利用者の復号済みアプリケーションフローが別のネクストホップへ出ていきます。どちらも正当で、どちらもルーティングを使い、それぞれが判断が行われる地点に存在するパケットへの一致を必要とします。最初の確認が後のルールの指すパケットを決めるため、以下の確認を順番に進めてください。

二つの会話に名前を付ける

拠点のゲートウェイにつないだ遠隔勤務者が、社内のアプリケーションサーバーへ HTTPS を開く場面を考えます。 回線の上には二つの独立した会話があり、両端でそれぞれ異なるアドレスを持っています。外側の会話は、ゲートウェイのアドレスからピアのアドレスへと、導入が合意したプロトコルとポートで、二つの VPN 端点の間を流れます。内側の会話は、クライアントに割り当てられたアドレスから、ポート 443 のアプリケーションサーバーのアドレスへ流れます。

アプリケーションの宛先ポートは VPN のトランスポートポートではなく、TCP 443 のポリシーをいくら積んでもトンネルは動きません。同様に、ピアのトランスポートアドレスを付け替えるルールは、その利用者の HTTP 要求が復号後にどこへ行くかを何も語りません。この分野の混乱のほとんどは片方に名前を付けてもう片方を設定することから来るので、ルールに触れる前に両方の会話を実際のアドレスとともに書き出してください。

ポリシーが実際にパケットを見られる場所を突き止める

一致は、パケットがまだ説明した形のままであるチェーンと名前空間で評価する必要があります。LAN の入口に付けたルールは、トンネルへルーティングされる前の暗号化されていない内側のパケットを見ます。 ローカルで生成されたトラフィックに適用したルールは、ゲートウェイ自身が作るパケットを見ますが、ゲートウェイが単に転送するトラフィックを自動的に覆うわけではありません。カプセル化された出力はまた別の三つ目のケースで、通常は LAN 側ではなくトンネルを運ぶインターフェースで扱います。

同じ設定の断片が二つのプラットフォームで違う挙動をするのは、取り付け位置が異なり、ベンダーのポリシーフックが暗号化の前にも後にも置かれ得るからです。別のベンダーの図から順序を推測するのではなく、その製品のパケット経路を読んでください。

合意したトランスポートを確認する

UDP でカプセル化した IPsec では、RFC 3948が ESP を UDP の中に置き、共有ポート上で IKE を区別できるよう非 ESP のマーカーを使います。素の ESP は IP プロトコルであり TCP や UDP のポートではないため、ポート番号で書いたファイアウォールルールはまったく一致しません。この区別が、WAN ポリシーに UDP のルールが必要か、プロトコルのルールが必要か、両方かを決めます。

記憶した値より合意した値が優先です。TCP 4500 や古いベンダーのポートを念のため足すと無関係なトラフィックを拾って本当の分類の問題を隠すので、機器から現在のポートとアドレスを読んでください。

コミットする前に戻り経路を確認する

外向きの成功は設計の半分を証明するだけです。遠隔クライアントのプールへ戻るパケットは、カプセル化が置き換えた時点でクライアントのアドレスの下には見えず、外側の宛先はピアのトランスポートアドレスです。二本目のアップリンクが別の事業者を通ってそのピアに届くなら、その変換とフィルタリングは一本目と食い違うことがあり、関連付けは移行ではなく再構築が必要になる場合があります。

ネットワークアドレス変換の状態は、WAN の切り替えで犠牲になりがちなところです。選んだアップリンク、想定される外側の送信元アドレス、使用中の変換、ピアからそこへの到達性を記録し、そのうえでトランスポートが運ぶトンネルへ送り込まずに到達可能なまま保ってください。

二つのキャプチャで両方の層を確認する

WAN インターフェースでのキャプチャと、トンネル内でのキャプチャは、どんな設定差分よりも速く疑問を片付けます。承認済みのクライアントが一度だけ要求を行う間にゲートウェイから実行し、両方のファイルを保存してください。

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

一つ目のキャプチャは、意図したインターフェースを外側の会話が想定どおりの送信元アドレスで出ていく様子を示すはずです。二つ目は、内側の会話が重複せず一度だけ、クライアントのアドレスを送信元に、アプリケーションサーバーを宛先として示すはずです。ルート検索は、その送信元と宛先の組に対してルーターがどの表を使うかを確かめ、ポリシーの誤りはたいていそこで現れます。どちらかのキャプチャが現れないなら、判断ポイントはルールを付けた場所ではなく別のところにあり、修正も広い一致ではなくそこに属します。