1つのIPv4宛先をOpenVPNトンネルの外へ送る方法

ほとんどのフルトンネル構成はすべてのパケットをVPN経由で送り、redirect-gatewayがそれを可能にするディレクティブです。それでも一つの宛先だけを除外できます。そのアドレスにnet_gatewayプレースホルダー付きのホストルートを追加すると、クライアントはマシンの元のゲートウェイ経由でそこへ到達し、他のすべてはトンネルを使い続けます。

この行は無害に見え、実際にそうであることも多いのですが、決めるのは一つの問いだけです。その正確なIPv4アドレス宛のパケットがどこへ行くのか。DNS、IPv6、ファイアウォールポリシー、どのプロセスが接続を開いたかは変えず、そのどれもが例外を静かに無効にできます。

net_gatewayが実際に指すもの

その例外のプロファイル行は一行です: route 198.51.100.77 255.255.255.255 net_gateway。最初のアドレスは宛先のためのドキュメント用プレースホルダーで、マスクは単一ホストのルートにし、最後のトークンはゲートウェイのプレースホルダーを指します。OpenVPNはルートをインストールするときにゲートウェイのプレースホルダーを解決します。vpn_gatewayはトンネル自身のゲートウェイ、つまりVPNリンクの遠い側を意味します。net_gatewayはVPNが何かを変える前にホストが持っていたデフォルトゲートウェイを意味し、通常は物理ネットワーク上のローカルルーターです。

三つ目のプレースホルダーremote_hostはVPNサーバーのアドレスを指し、トンネルが物理的な経路でサーバーに到達できるように存在します。この三つを混同することが、例外が誤った場所へ行ったり、まったくインストールされなかったりする最も一般的な理由です。

値は接続時に読み取られ、ファイルには書き込まれません。マシンが別のネットワークへ移動すると、VPN前のゲートウェイが変わり、ルートは新しいものに従います。ふつうはそれが望ましいのですが、例外の動作がクライアントの起動時のネットワークに依存するという意味でもあります。

ホストルートがトンネルのデフォルトに勝つ理由

ルーティングは最も具体的に一致するプレフィックスで決まります。redirect-gateway def1は通常デフォルトルートを置き換えません。アドレス空間の下半分へのルートと上半分へのルートという二つの半分を追加するので、元のデフォルトルートは他の用途のために残ります。その半分は単一アドレスより広いものです。

マスク255.255.255.255の単一アドレスへのルートは/32で、IPv4で得られる最も具体的な指定です。そのアドレス宛のパケットを評価するとき、/32が一致し、どのルートが先にインストールされたかにかかわらず勝ちます。これが例外の仕組みで、ルートが実際に存在するかぎりLinux、macOS、Windowsで同じように働きます。

Windowsは第二の次元を加えます。二つのルートが同じくらい具体的なときはメトリックの低いほうが勝ち、VPNアダプターが結果を変えるインターフェースメトリックを持つことがあります。/32は半分より具体的なので例外は通常保たれますが、以前のセッションの古いルートが同じくらい具体的だと紛らわしい結果になり得ます。

例外がカバーしないもの

DNSが最初の隙間です。クライアントは内部リゾルバーの設定を押し込むことがあり、OSはそれを照会に使い続けます。接続前に名前を解決するアプリケーションは、直接行くべきサービスの内部アドレスを受け取ったり、正しく解決されても次の隙間でつまずく外部アドレスを受け取ったりします。

IPv6が二つ目です。ルートディレクティブはIPv4だけを扱います。デュアルスタックの宛先はIPv6を好むことがあり、ポリシーに応じてトンネルかホストのIPv6デフォルトルートをたどるので、IPv4の例外は決して働きません。対応するIPv6ルートか、そのクライアントでIPv6を無効にする意図的な判断が必要です。

アプリケーションの範囲が三つ目です。ルールは宛先ベースなので、そのアドレスに接続するすべてのプロセスが直接経路を使います。意図したプロセスかどうかは関係ありません。逆に、ウェブサイトは複数のアドレスから応答できるので、一つの/32を除外してもサイトを除外したことになりません。本当の要件がアプリケーションごとのルーティングなら、Communityクライアントのルートテーブルは間違った道具です。

自分を欺かずに例外を確認する

ブラウザーではなく、インストールされたルートから始めます。Linuxではカーネルに、その特定のアドレスに使うルートと次のホップを尋ねます。Windowsではその/32のルートテーブルを読みます。ゲートウェイがトンネルではなく物理的なものだと確認します。エントリがなければ、プロファイルが適用されていないか、クライアントにルートを変更する権限がありませんでした。

次に二つの宛先を試します。除外したアドレスへの要求は物理インターフェースから出るはずで、対照用の内部アドレスへの要求は依然としてトンネルを使うはずです。除外したアドレスだけを試してもトンネルの残りについては何も証明できず、公開ウェブサイトを試すとそのサイトが解決されたアドレスを試すことになり、ルールのアドレスとは限りません。

最後に、ルートを覆せる制御を確認します。クライアント側のkill switchやWindowsのblock-outside-dns設定は直接トラフィックを禁止でき、ルートが正しくても接続が失敗する形で現れます。例外が動くように見せるためにそれらの制御を無効にしないでください。ポリシーが直接経路を禁じているなら、例外はVPNサービス所有者にとって設計上の問題です。

VPN前のゲートウェイと利用可能な経路はプロファイルではなくその時点の性質なので、再接続やネットワーク変更のあとに再確認してください。