プライベートルートを残しリダイレクトを捨てる：OpenVPN の分割トンネル

トンネルが上がり、アプリケーションが読み込まれ、そのあとノート PC の他のすべてが妙な挙動を始める。これは一行を削除して実装された、プライベート専用方針のよくある姿だ。押し出された既定ルートを外すと、トラフィックがどこへ行くかは確かに変わる。だが、代わりにどこへ行くべきかは語らず、名前解決にはまったく触れていない。方針には二つの積極的な半分が要り、それから初めて検証できる。

リダイレクトの削除は変更の半分にすぎない

全トンネルのリダイレクトとプライベート専用方針は、世界について何を主張するかが違う。リダイレクトはあらゆる宛先を主張し、プライベート方針は一覧を主張して残りは放置する。一覧を書かずに主張を削除すると、LAN の外に何も届かないクライアントができあがる。これは方針の穴というより経路の障害に見える。主張を外す前に一覧を書けば、この二つの手順の順序は問題でなくなる。

どちらの半分も既定ではなく要件だ。プライベート接頭辞はトンネルに入り、通常の宛先は接続前の経路を保たねばならない。

組織が全トンネルを義務づけるなら、ここに書いたことは当てはまらない。プライベート専用の設計は、分割経路が承認された配備に属する。

pull-filter は照合であり、スイッチではない

pull-filter 指令は、名前が接頭辞に一致する押し出されたオプションを削除し、それだけのことをする。リダイレクトを無視すれば、他の押し出されたオプションはそのまま残り、通常はそれが望ましい。経路、DNS 設定、ルートゲートウェイの値はどれも届くのだ。ローカルプロファイルに書かれた指令は削除できない。フィルタはサーバーが押し出すものに働くからだ。

route で始まるオプションをすべて無視したくなる誘惑に抗うこと。その型は接続に必要なプライベート経路まで捨ててしまい、トンネルが依存するゲートウェイ情報を落としかねない。

route-nopull は見た目より広い判断だ。押し出された経路と DHCP 風のオプションをまとめて受け取ることを止める。これは一つのオプションを除外するのとは別の方針である。

経路一覧はアプリケーションから外側へ書く

利用者が実際に開くものから始め、次に支える部品を足す。10.60.20.15 のアプリケーションはそのサブネット 10.60.0.0/16 を含意し、プライベート名はそれに答えるリゾルバーを含意する。したがって一つのアプリケーションを求めた利用者には、二つの宛先と一つの DNS 判断が要る。その一覧の外は構造上スコープ外であり、これが方針を検証可能に保つ。

協力するサーバーでは、それらは二つの押し出された経路になり、どちらもリダイレクトではない。既存サービスが与えるトンネルのトポロジーとルートゲートウェイの値を保つこと。

一部の利用者だけがこの方針を必要とするなら、クライアント単位かグループ単位で適用する。一つのチームの要件を直すために全員の経路を変えるのが、分割トンネルを障害に変える道である。

DNS にも同じ経路をたどらせる

リゾルバーへの経路はリゾルバー方針ではない。systemd-resolved のクライアントでは、意味上の結果はプライベート名前空間に対する経路ドメインであり、それが内部リゾルバーを指す。だからこそその名前だけがそれを使う。Windows のクライアントには代わりに独自の名前空間方針の仕組みが要る。プロファイルの DNS サーバー行は、どちらも単独では導入しない。

プロファイルが要求したことではなく、OS が選んだことを確認する。Linux では resolvectl status がリンクごとのドメインとサーバーを示す。Windows では名前空間方針の表が同等の証拠になる。

リゾルバーをトンネル経由で到達可能に保つこと。そうでなければ方針は問い合わせできないアドレスを指す。トンネルが届かないリゾルバーのアドレスは、機能する方針をタイムアウトに変える。

再接続で両方の半分を検証する

変更後にクライアントを再接続し、プライベートアドレスと公開アドレスへの実効経路を調べる。次にプライベート名と公開名を解決し、それぞれが意図したリゾルバーを使ったことを確かめる。公開サイトが読み込めることは後半だけの証明であり、その後半はたいてい偶然に動いている。

仕上がった方針を一文で記録する。これらの接頭辞と名前はこの接続を使い、それ以外はローカルの経路に従う。そしてログインのたびにアダプター設定を直すのではなく、プロファイルに保つこと。