サイト間 VPN に二つ目のサブネットを追加する: 二つの道筋

稼働中のサイト間トンネルに二つ目のサブネットを追加する作業は、一方の設計なら五分、もう一方ならほぼ半日かかります。トンネルが指定したプレフィックスにルートを導入する設計なら、ルートを一つ足せば通信はそれに従います。固定のセレクター対を一つだけ交渉する設計なら、両側が一致する対に合意するまで新しいプレフィックスは保護されないままです。判断を分けるのは三つです。各側の設定が実際に何を記述しているか、交渉された通信が最小の一致対に狭められるか、新しい範囲の戻り道を誰が持つか。

状態ラベルではなくカーネルを読む

接続済みと報告するトンネルでも、導入されている子アソシエーションは一つ以上あるだけで、期待したものとは限りません。Linux ではカーネルが適用内容を示します。ip xfrm policy はセレクター対を一覧し、swanctl --list-sas (または古い ipsec statusall) は両側が交渉した内容を方向ごとのトラフィックセレクター込みで示します。新しいプレフィックスがどちらにも無ければ、設定ファイルが何と言おうと保護されていません。

ルートテーブルと比べてください。ルートベースの構成ではトンネルデバイスが保護対象プレフィックスの次ホップです。ポリシーベースの構成では、遠隔サブネット向けの個別ルートが無く既定ルートだけのことが多く、通信を選ぶのはテーブルではなくポリシーです。

ポリシーベース: 両側が新しいプレフィックスを列挙する必要がある

strongSwan の用語ではセレクターは子設定の local_ts と remote_ts にあり、leftsubnet と rightsubnet の後継です。新しいプレフィックスは両側に鏡のように現れる必要があり、拠点 A がローカルと呼ぶものを拠点 B はリモートと呼びます。不一致がきれいなエラーになることはまれです。両側は共通部分まで狭まり、古いプレフィックスは動き続け、新しいものだけが静かに失敗します。

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

pfSense や OPNsense では、新しいローカルサブネットと新しいリモートサブネットを組にする二つ目の Phase 2 エントリを追加し、適用します。古いエントリは残してください。置き換えると元のサブネットが追加ではなく移動します。既存の Phase 2 が 0.0.0.0/0 のようなスーパーネットや集約範囲を既に覆っているなら、その隣に狭いエントリを足さないでください。重複するセレクターは競合するポリシーを導入し、評価順が勝敗を決めます。

IKEv1 はサブネット対ごとに独立した Phase 2 を作り、一交換につき一対だけ受け取る側は残りを捨てます。IKEv2 は一つの子に複数のセレクター対を載せられますが、両実装が受け入れる場合に限ります。swanctl --list-sas の一覧が真実で、入力した内容は要求にすぎません。

ルートベース: ルートがポリシー

XFRM インターフェースや VTI デバイスはルートテーブルに従って通信を運びます。新しいプレフィックスを両拠点でデバイスに向ければ、インターフェースの変換に結び付いた状態が適用されます。同期すべきセレクター対が無いため、サブネットが増えてもこの設計はよく拡張します。strongSwan の転送ガイド はカーネル側を詳しく扱っています。

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard はさらに進みます。AllowedIPs は暗号の許可リストであり、また wg-quick を通じてルートテーブルの項目にもなります。片側にだけプレフィックスを足すと、ハンドシェイクと外向きパケットは通るのに無音になります。遠い側は送信元が許可リストに無いパケットを捨てるからです。wg set の形式はリスト全体を置き換えるので、既に動いていたプレフィックスを書き直さないと切り落とします:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

wg-quick ではなく wg set を使った場合、この二つ目のコマンドは任意ではありません。カーネルは新しい許可リストを即座に受け入れますが、ルートを足す者は無いため、ローカル生成の通信は既定ゲートウェイから出たままです。新しい WireGuard サブネットがトンネルのホストからは動き、ノート PC からは動かない最も一般的な理由です。

戻り道はトンネルより頻繁に壊れる

新しい遠隔サブネットのホストは、応答を VPN ゲートウェイ経由で返す必要があります。そのゲートウェイが既定ルーターでない場合、応答は LAN ルーターへ行き、破棄されるか、プライベートな送信元アドレスのままインターネットへ転送されます。ゲートウェイではなく遠い側のホストから試してください。Linux では ip route get 10.30.20.15、PowerShell では Find-NetRoute -RemoteIPAddress 10.30.20.15 が実際に使う次ホップを示します。応答がトンネルの端点でなければ、そこに新しいプレフィックス向けの静的ルートを追加します。

戻りルートが無い拠点で送信元 NAT を使うのは正当な代替で、多くのハブアンドスポーク構成が全サーバーに手を入れずに済ませる方法です。宛先側ゲートウェイでも新しいプレフィックスに適用してください:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

代償は現実です。遠隔のログは個々の送信元アドレスを出さなくなり、元のサブネットを前提としたファイアウォール規則はゲートウェイ用の一規則に畳まれます。ルートが無かったからではなく、意図して選んでください。

ファイアウォールは戻り道のもう半分です。ゾーンベースの機器は既存トンネルインターフェースのゾーンを新しいサブネットへ自動で広げず、古いプレフィックス向けに書いた規則は一致しません。IPsec を責める前に、新しいサブネットをゾーンか両方向の規則対に追加してください。

三つの問いで決め、通信で検証する

短く言えば、側の設定がプレフィックスを名指すのか (ポリシーベース)、通信がインターフェースへルーティングされるのか (ルートベース)。両端が新しいプレフィックスを列挙しているか。新しいサブネットから元の送信元範囲へ戻る道はあるか。

検証は多くの変更が早すぎる段階で閉じられる場所です。ゲートウェイからの ping はほとんど証明になりません。ゲートウェイは自分を送信元にし、ホストとは別のポリシーに一致することが多いからです。新しいサブネットのホストから ping し、変更のきっかけとなったアプリケーションを動かし、状態アイコンではなくカウンターを見てください。

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

ポリシーベースのトンネルでは ip xfrm state のカウンターが両方向で増えるはずです。平らなままなら、パケットはルーティングされているが選択されていません。WireGuard では wg show が側ごとの転送量を示し、受信バイトがゼロのハンドシェイクは遠い側の許可リストか戻りルートを指します。

最後に、プレフィックス、側のセレクターまたはルート、戻り道の判断、ファイアウォール項目をトンネル台帳の残りとともに記録します。そのうえでゲートウェイを一台再起動して再試験してください。手で足したルートは消えるので、次の担当者がそれを再発見せずに済みます。