フルトンネルVPNがルーティング済みのローカルVLANを隠す理由

VPNクライアントの「allow local network」スイッチは、建物内のすべてをカバーするように聞こえます。実際には、通常いくつかのプライベートアドレスの例外をトンネルのデフォルトルートに追加するだけで、そこで止まります。ストレージVLANが到達可能なままでいるのは、その特定のプレフィックスに対するルートがトンネルの到着を生き延びた場合だけであり、多くのクライアントではそうなりません。

これはVPNの設定ではなくルーティングの問題であり、具体的な答えがあるという点で良い知らせです。

allow-local-network が実際にカバーする範囲

クライアントによる実装はさまざまです。マシンが接続されているサブネットのルートを追加するもの、RFC 1918 の範囲を追加するもの、デフォルトゲートウェイだけを除外するものもあります。どれも、オフィスのルーターがストレージVLAN、ラボセグメント、プリンターサブネットも提供していることは、それらのプレフィックスがクライアントに見える回線上にないため知りません。ラベルが自分のトポロジーを表していると決めつけず、正確な動作についてはクライアント自身のドキュメントを読んでください。

この違いが最も重要になるのは、クライアントがすべてのトラフィックをVPN経由にするためにデフォルトルートを意図的に置き換えるフルトンネル設計です。それが設計の狙いそのものであり、同時にローカルのルーティング済みネットワークを消してしまう原因でもあります。それらは独自のルートでカバーされていたのではなく、たった今置き換えられたデフォルトルートに乗っていただけでした。クライアントは存在を知らないものをルーティングできず、自分のインターフェースに接続されたプレフィックスしか学習しません。それ以外は、トポロジーを知っている誰かが記述する必要があります。

接続済みルートは最初のルーターで止まる

192.168.10.20/24 にあり、ゲートウェイが 192.168.10.1 のワークステーションは、192.168.10.0/24 への接続済みルートを自動的に取得します。192.168.20.0/24 のストレージVLANは別のプレフィックスで、そのゲートウェイ経由でしか到達できず、ワークステーションにはデフォルト以外のルートがありません。トンネルが上がる前は、通常のデフォルトルートが偶然ストレージのトラフィックを 192.168.10.1 に送るため、すべてが機能します。

VPNがフルトンネルのデフォルトルートをインストールすると、192.168.20.1 宛てのパケットは新しいデフォルトに従ってトンネルに入ります。リモートゲートウェイはそのプレフィックスがどこにあるか知らないため、パケットを破棄するか、役に立たない場所へ転送します。ストレージVLAN側に設定ミスはなく、その経路は借り物であり、返却を求められたのです。

誘惑されるのは、/1 ルートのペアや二つ目のデフォルトといった広い例外に手を伸ばすことです。こらえてください。例外が狭いほど、ネットワークが変わったときに説明し、監査し、削除するのが容易になります。

例外は勝つ側のテーブルに入れる

一つのルーティングテーブルの中では、/24 は最長プレフィックス一致により /0 や /1 に勝つので、ローカルゲートウェイ経由でストレージVLANへの具体的なルートがあれば、そのテーブルが参照されることを前提に十分です。Linuxでは通常の形は短く次のとおりです。

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

ポリシールーティングはその保証を複雑にします。以前のルールが、自身のデフォルトルートがトンネルを指すテーブルへトラフィックを送ることがあり、その場合あなたの /24 を持つメインテーブルには決して到達しません。間違ったテーブルにある正しく見えるエントリは壊れたルートのように見える障害を説明するため、ルートが権威的だと決めつける前にルールを確認してください。

次に、クライアントがサポートする仕組み、またはインターフェースを所有するネットワークマネージャーを使って、エントリを永続化します。プロンプトで入力したルートは次の再接続で消え、一つのWi-Fiゲートウェイに結び付いたルートは、ノートPCが次に訪れるネットワークへ持ち運べません。

名前とポリシーはルートに従わない

ルートを直しても復活するのはパケットであり、名前ではありません。ローカルデバイスが、それらを何も知らない押し付けのリゾルバーで解決される場合、アドレスに到達できてもマウントは失敗し続けます。ローカル名にはローカルまたはスプリットDNSの取り決めが必要で、それはルートの例外とは別の判断です。

ポリシーもまた別です。VPNクライアントのローカルアクセスフィルターは、プライベート範囲へのトラフィックを意図的に禁止することがあり、ルートはそのルールを覆しません。信頼できないネットワークでは、プライベートアドレスは宛先があなたのストレージサーバーである証拠にもならないため、例外はルートそのものと同じくらい具体的であるべきです。

引き渡せる契約

完成した設計は、一般的なインターネットトラフィックはトンネルを通り、これらの名前付きローカルプレフィックスはローカルルーター経由の経路を保つ、という短いリストとして読めるべきです。プレフィックス、次のホップ、それに付随するDNSサフィックスを書き留め、ルーティングテーブルを読まなくても誰かが検証できる程度にリストを短く保ってください。

ローカル範囲とリモート範囲の重なりに注意してください。VPNの向こう側とプレフィックスを共有するストレージVLANは、より具体的なルートに解決され、その結果の挙動は断続的に見える形で混乱を招きます。片側を再番号付けするほうが、曖昧さを永遠にデバッグするより通常は安く済みます。

契約は、トンネルが上がっているときと下がっているときの二回テストしてください。ローカル経路がどちらか一方の状態でしか機能しないなら、その例外はまだ契約ではありません。