ルートベースとポリシーベースのサイト間VPN：何が違うのか
ポリシーベースのIPsecはセレクターでトラフィックを選び、ルートベースはトンネルインターフェース経由で送ります。どちらもファイアウォール規則と戻りルートが必要です。
どちらの設計も同じIPsec機構で同じトラフィックを保護し、どのパケットがトンネルに入るかを何が決めるかという点で異なります。ポリシーベースの接続ではネゴシエートされたトラフィックセレクターがその役目を果たし、ルートベースではトンネルインターフェースを指すルートがその役目を果たします。両者を混同すると、トンネルは確立済みと報告するのにアプリケーションは何にも届かない、というよくあるサポートのやり取りになります。この区別が最も重要になるのは、ネットワークを追加するとき、ルーティングプロトコルを動かすとき、あるいは誤った出口から静かに抜けていく経路をデバッグするときです。
トンネルに入るものを決める二つの方法
ポリシーベースのVPNは送信元と宛先のプレフィックスに一致するセキュリティポリシーを構築し、適合するものを暗号化します。ピアは互換性のあるセレクターをネゴシエートする必要があるため、実効スコープは双方が提案したものの共通部分になります。その共通部分の外は、ルーティングテーブルが何と言おうと保護されません。
ルートベースのVPNはトンネルを表すインターフェースを作成し、ルーティングテーブルからそこへトラフィックを送らせます。IKEデーモンは依然として状態とインターフェースごとのポリシーをインストールしており、これがルートが暗号化を置き換えたと判断するときに見落とされる詳細です。どちらの設計もIPsecで暗号化し、違うのは選択の仕組みだけです。
以下の比較は採点表ではなく障害の兆候の集まりとして読んでください、どちらの列も単独では勝ちませんから。
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
ポリシーベース：セレクターが契約
セレクターは設定するだけでなくネゴシエートされます。片側で10.10.0.0/16、もう片側で10.10.1.0/24を提案すると、アソシエーションはネゴシエーションが決着した範囲を覆い、他のすべてのホストはその外に残ります。
設定ファイルではなくインストールされた状態を読みます。Linuxのピアではカーネル自身のテーブルが根拠であり、ネゴシエーションを生き残ったものが分かります。正しいプレフィックスを挙げているのに一致する状態がないポリシーは、アソシエーションが一度も立ち上がらなかったことを意味します。間違ったプレフィックスのポリシーと対になった状態は逆の問題で、あるサブネットが何にも届かないのにトンネルは健全に見える状況を生みます。
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas両方の出力を、保護していると考えているプレフィックスと比較してください。この一度の比較で、トンネルは動いているのにサーバーに届かないという報告のほとんどが解決します。また、不一致は通常一方向にしか見えないため、どちらのピアを変えるべきかも示します。
ルートベース：インターフェースが契約
XFRMインターフェースはトンネルに名前と識別子を与え、ルーティングテーブルがそう指示するのでトラフィックはそこへ届きます。すると複数の遠隔プレフィックスはセレクターの問題ではなくルーティングの問題になり、ルーティングプロトコルがそれらを広告できます。これが本当の利点であり、暗号化ではありません。
インターフェースはポリシーの必要性を取り除きません。デーモンはインターフェースの識別子に結び付いたインターフェースごとの規則をインストールするため、誤ったインターフェースに届いたパケットは依然として失敗します。ピアが受け入れない送信元アドレスも、完璧なルートがあっても失敗します。ルートベースとはルートが入り口を決めるという意味で、ポリシーが消えたわけではありません。
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10ルートを配置したらインターフェースのカウンターを監視します。ルートが存在するのにカウンターがゼロのままなら、何もトンネルに一致していないことを意味し、通常はルートの欠落ではなく状態の欠落を示します。
二つの設計が実際に分かれるところ
ネットワークの追加は、どのモデルが自分に合うかを試す最も明確なテストです。ルートベースの設計はルートを一本追加し、セレクターを広げるのはせいぜい一回です。一方、ポリシーベースの設計は両方のピアでプレフィックスの組を編集して再ネゴシエートし、安定したサブネットが二つならその編集は取るに足りませんが、二十あればプロジェクトになります。
どちらのモデルもファイアウォールを置き換えませんし、比較は通常この点の手前で止まります。広いセレクターや広いルートは何が暗号化されるかを決めるのであって、何が許可されるかではありません。
MTUの挙動も実際には異なります。カプセル化は利用可能なペイロードを減らし、ルートベースのインターフェースは独自のMTUを持つため、両方のゲートウェイでMSSをクランプすれば、小さい応答は届くのに大きい応答が消えるブラックホール症状を避けられます。ポリシーベースのトンネルも、セレクターはパケットサイズについて何も語らないため、反対側から同じ壁に突き当たります。ピアを責めるのではなく、クランプを意図的に設定してください。
戻り経路を失わない移行
何かを変える前に既存のプレフィックスの組を記録し、その後でアプリケーションの経路を一本移して端から端まで観察します。確立するトンネルは転送するトンネルではなく、その差は戻り方向に現れます。
ピアは接続するのにLANのホストが接続できない場合は、戻りルートと遠隔ホストが使う送信元アドレスを調べます。二つのインターフェースを持つホストは誤った側から応答することがあり、セレクターの変更では直りません。アルゴリズムを編集する前に両端でトラフィックを取得してください。
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns作業中はトンネルに依存しない管理経路を確保してください。ゲートウェイ自身のアクセスがデバッグ中の接続に乗っていなければ、切り戻しは容易です。