ドメイン単位のVPNルーティングとIPルートの比較：どちらを選ぶべきか

IPルートはアドレスのプレフィックスに一致し、カーネルはそれ以上の問い合わせをせずに適用します。ドメインベースのVPNルールは名前に一致するため、その名前が現在どのアドレスを指すのかをスタック内の何かが判断し、その判断を最新に保ち続ける必要があります。両者は仕組みが異なり、故障の仕方も異なりますが、ベンダーは同じ言葉で呼びます。機能一覧で比べても要点はつかめません。答えが変わったときに何が起きるかで比べるべきです。

有用な分け方は、名前解決を行うルールと行わないルールの違いです。

各ルールが実際に何に一致するか

プレフィックスルールは、ルーティングテーブルの宛先アドレスに一致します。名前解決も期限切れもなく、すべてのパケットで一致は正確です。ドメインルールは、アプリケーションからの名前の要求に一致します。名前とは何かについて、RFC 1034はアドレスではなく、ラベルの木として定義しています。製品によっては名前を一度だけ解決し、得られたアドレスをルートとして登録します。この場合、ルールは更新タイマーが付いたIPルールにすぎません。

デバッグの前に、自分がどちらを使っているのかを把握してください。故障の見え方がまったく違うからです。

ドメインルールはスタックのどこにあるのか

ローカルプロキシ経由でドメインルールを実装している場合、トラフィックはそのプロキシに届く必要があり、システムプロキシを無視するアプリケーションはルールを完全に迂回します。名前を解決してルートを追加する実装なら、アドレスは最後の更新時点のものにすぎません。リゾルバにフックする実装なら、DNSの挙動がルーティングポリシーの一部になり、フォールバックのリゾルバがそれを静かに打ち消すことがあります。

設定のラベルではなく、ベンダーのモデルを読んでください。Split Tunnel という欄があっても、二つのクライアントが三通りの異なる動作をしていることがあります。

何が壊れるかを比べる

三つの点で壊れ方が異なります。アドレスの変動：CDNのホスト名は数分で別のアドレス集合に解決されることがあるため、コピーした一覧はすぐに古くなります。サブドメインの範囲：example.com のルールが api.example.com をカバーするかどうかは製品次第で、通常はドキュメントに明記されています。解決の失敗：リゾルバが落ちると、名前解決を行うクライアントはトラフィックをトンネルに回すか、直接送るかに切り替わることがあります。

設定の問題なのは二つ目だけです。残り二つは、製品がどこまで推測するかという設計の問題です。

プレフィックスのほうが適切な場合

安定したプライベートサブネットなら、明示的なプレフィックスのほうが明確で速く、監査もしやすいです。解決する必要がないため、リゾルバの障害にも耐えます。ドメインルールを使うのは、サービスがホスティングされている場合、アドレスが頻繁に変わる場合、宛先の集合を本当に列挙できない場合です。たまたまホスト名だけを知っているという理由で選ぶべきではありません。

推測で作った静的リストは最悪です。保守されているように見えて、プロバイダがホストを追加した日に静かに取りこぼします。

新しいリクエストで検証する

通常の再接続後にコールドリクエストで試す。キャッシュされたページはルールに触れないことがあるからです。名前を解決し、接続が実際にどこへ行ったのかを確認してください。dig +short app.example.comを実行すると現在のアドレス集合が得られ、クライアントの接続一覧を見れば、どのインターフェースが通信を運んだかがわかります。

製品がドキュメント化している更新間隔の後に、もう一度試してください。アドレス集合がずれているのにルールが追従していなければ、それが実際の挙動です。

リゾルバのポリシーも別に扱ってください。ドメインルールには正しい名前データが必要ですが、どのリゾルバが問い合わせに答えるかは、それだけでは決まりません。