ルーターのVPNルール：送信元と宛先を突き合わせる

ルーターの販売ページはVPNルーティングを一つのチェックボックスとして示しますが、その言葉には三つの異なる問いが隠れています。ルールはトラフィックを送る端末に一致するのか、それを受け取るサーバーに一致するのか、両方なのか。どちらにも一致しないトラフィックはどうなるのか。そして二つのルールが重なったとき、どちらが勝つのか。答えを送信元と宛先の組として書き出せば、曖昧な機能一覧が検証可能な設計に変わります。

機能名は二つの端点を隠している

トンネルを使うべきメディアプレーヤーは送信元の一致です。トンネル経由で到達できるべき社内オフィスのプレフィックスは宛先の一致です。一つのサービスだけにトンネルを使うべきワークステーションは両方であり、その共通部分が 多くの消費者向けファームウェアが苦手とするケース です。

製品を比較する前に、要件を組として書き出します。その組こそ後で検証するものです。

端末リストやグローバルな宛先リストを提供する製品は、「この端末だけ、これらの宛先だけ」を表現できないかもしれません。この差は見た目ではなく、グローバルな宛先ルールは、そのサイトへの全端末のトラフィックをトンネルに通し、端末ルールはその端末の全トラフィックを送ります。どちらも要件ではありません。画面を信じる前に、二台の端末でそのケースを試してください。

ルールを共通部分として組み立てる

表にすれば設計は正直になります。シナリオを左に置き、送信側の一致と宛先側の一致を別々に名付けます：

三行目が面白いのは、両方の半分を同時に必要とするからです。ファームウェアが一つの軸しか表現できないなら、要件を二つのルールに分けるか、それができる端末へ移す必要があります。

送信元の同一性は安定させてください。DHCP予約、専用セグメント、端末の識別機構はいずれも機能しますが、リースの期限切れ後に変わるアドレスは機能しません。一つのIPv4アドレスでは端末の全トラフィックを識別できないので、IPv6も含めてください。

重なりは優先順位が決める

ルールの重なりは普通のことです。広い端末ルールと狭い宛先ルールが同じフローを記述することがあり、文書化された優先順位がどちらが勝つかを決めます。魅力的な設定画面はその順序を教えてくれません。

順序と一致しない場合についてはマニュアルを読み、観察できるトラフィックで両方を試してください：

ip rule show
ip route get 203.0.113.10

文書に順序の記載がなければ、狭いルールが勝たない可能性を前提に設計してください。衝突し得ない二つのルールは、優先順位が未文書化の一つの賢いルールより支えやすいものです。

名前には更新ポリシーが必要

ドメインとして書かれた宛先は保守の問題を増やします。ルーターはそれを解決し、マッピングを更新し、複数のアドレスとサブドメインを扱い、想定したリゾルバーを迂回するアプリケーションDNSにも対処しなければなりません。

一度の検索結果をIPルールにコピーするのはスナップショットであり、ドメインポリシーではありません。

ルールが誤りになる前に答えがどれだけ古くてよいか、解決に失敗したときルーターがどうするかを決めてください。最後に判明したアドレスを保持するルールはサービス移行を生き延びられますが、エントリを捨てるルールは静かにトンネリングを止めることがあります。どちらの挙動も、ルールのそばに書き記されていれば許容されます。

利用不可の状態を定義する

ルートの優先設定はVPN限定のトラフィックを強制しません。トンネルが落ちているとき、ルーターはフローを遮断し、直接送り、または別のトンネルを使え、どの選択にも異なる障害の痕跡があります。

要件がどれを必要とするかを決め、トンネルを止めてフローを観察して確認してください：

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

ルーター自身から発生するトラフィックは別の範囲です。DNS転送、更新確認、監視は、端末の送信元一致を引き継ぐのではなく、ルーター自身から新しいフローを開始できます。それらのフローを明示的に考慮しないと、ログに説明のつかない漏えいとして現れます。