下流サブネットとデスクトップVPN:中継を除外し、アプリは除外しない
アプリ単位のバイパスが分類するのはローカル出力だけです。ワークステーション背後の機器には、独自の受信・転送・戻り経路のポリシーが必要です。
一台のマシンに二つの役割、一つのファイアウォール。Wi-Fiの上流回線、その背後にある小さなEthernetサブネット、そしてマシンから出るものはすべてローカルだと想定するデスクトップVPNクライアントがある。ローカルで起動したアプリはローカル出力経路から出る。ワークステーション背後の機器はEthernetポートに届き、転送の判断を必要とする。最初の経路向けに書かれた除外は二番目の経路を決して見ない。だからブラウザはトンネルを迂回し、機器は迂回しない。
二つのパケット経路、一つのポリシー
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
最初の行は、ほとんどのsplit-tunneling解説が説明しているものだ。二番目は、たまたま同じマシン上にあるルーター設定である。両者を一つのメンタルモデルに溶かすのが誤りだ。両者はカーネルを共有するが、ポリシーは共有しない。どのルールを編集する前にも両方の経路を描き、欠けている経路がどちらかから設計の残りが決まる。
この表は、一台のマシンが一方のテストに合格し他方で失敗する理由も説明する。ワークステーション上のブラウザはローカル経路を証明し、Ethernetポートに接続したノートPCは転送経路を証明する。変更はどちらでも検証すること。さもなければ、ブラウザを何度再読み込みしても二番目は未検証のままだ。
アプリの除外が実際に分類しているもの
アプリ単位の除外は通常、プロセスやユーザーのパケットにマークを付けてから、マークされた通信をトンネルの外へルーティングする。これはローカル出力の構築物だ。下流の機器からのパケットにはローカルプロセスがないため、セレクターが何であれ、決してセレクターに一致しない。
セレクターが何であれ、二つのリストは同じリストではない。そこが要点だ。MullvadのLinuxガイドは、そのファイアウォールとルーティングポリシーが消費するマークを説明しており、例はローカル出力を対象にしている。下流ルーターのサポートされた説明ではない。これをコピーすると、除外があると信じながらすべてをトンネルへ転送するマシンができあがる。
中継の契約を書く
下流の送信元プレフィックスと受信インターフェースを一緒に名指しし、そのプレフィックスを受信側で制限する。制限がなければ、ポートに到達できる機器は除外アドレスを主張してバイパスから出られてしまう。これを二つの問いとして扱う。これらのホストはそもそもこの上流回線を使ってよいのか、ワークステーションやトンネルのプライベート範囲に到達してよいのか。これらは追加の許可であり、回線選択の副作用ではない。
転送を許可し、それから絞り込む。Linuxゲートウェイには転送の有効化、意図した通信を両方向で許可するルール、そして上流への戻り経路か意図的に範囲を限った送信元変換のいずれかが必要だ。NATだけでは上流回線を選ばず、フィルター通過も許さない。アドレスの書き換えはそれらの判断の後に行われるにすぎない。
中継の分類は転送ルートの判断より前、つまりoutputではなくpreroutingの段階で行う必要がある。判断の後に置いたルールはパケットを変更できても、すでに送られた先を変更することはできない。
マークはそれを所有するアプリのもの
マーク値、テーブル番号、チェーンの優先度はVPNアプリのポリシーの一部であり、永遠の定数ではない。他のプログラムが再生成するテーブルにルールを挿入することに依存するネットワークは、次の更新で壊れる。たいていは都合のよい時ではなく、再接続の最中だ。
accept判定を持つ二本目のベースチェーンを追加しても、後続チェーンのdropを必ず上書きするわけではない。ベースチェーンにはフックと優先度があり、順序で最初の判定が勝つ。一つのチェーンのacceptは、別のチェーンが先に到達するdropを取り消さない。増加した一つのカウンターではなく、ルールセット全体とルーティングポリシーの順序を見ること。カウンターはルールが動いたことを証明するが、その判定が適用されたことは決して証明しない。
統合するか、サブネットを移す
二つの設計は、バイパスを誰が所有するかで異なる。統合設計は一台のマシンと一つのポリシーを保つが、VPNアプリのテーブル寿命と、ドキュメントが変えうるマーク群への依存を代償にする。下流ネットワーク専用のルーターはその依存を完全に取り除く。サブネットは自前の上流回線を持ち、ワークステーションは転送の役割を持たないクライアントのままだ。
二番目を選ぶのは、下流ネットワークがVPNの更新をまたいで動き続ける必要があるとき、または各リリースの後に統合ポリシーを誰も検証できないときだ。一番目を選ぶのは、統合が文書化され、誰かが責任を持つ場合に限られる。
境界は四つの状態で検証する。接続済み、再接続中、意図的に遮断、停止だ。各状態で名前解決と両方のアドレスファミリーを確認すること。DNSが漏れるバイパスは、設計した除外ではない。テストは正確な境界を証明すべきであり、単に一つのページが読み込まれたことを示すだけでは足りない。