LAN と重なる VPN プールはルートでは直らない

アプリはトンネルが正常だと主張しますが、必要な宛先の半分は決して応答しません。反射的にルートを足したりメトリックを下げたりしますが、まず殺すべき神話はまさにその反射です。クライアント自身の LAN とトンネルのプールが同じプレフィックスを主張すると、ルーティングテーブルは相容れない二つの事実を抱え、デフォルトルートもメトリックもそれを解決しません。修復はアドレス設計の判断であり、ルートの編集では代わりになりません。

追加のルートが一つのプレフィックスを分割できない理由

ルートは一つのプレフィックスへの二つの主張を分離できず、だから賢明なのは正しいルート行を探すのをやめることです。スタックは同一のプレフィックスを接続ルートより前に置かず、より具体的なエントリはアドレスを捕まえますが、それを持つローカルホストを到達不能にします。ルーティングの問題に見えるものはアドレスの衝突であり、どちらの修復もルートではなくアドレスを変えます。 受け入れる前に自分のマシンでこの主張を検証してください。

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

システムに一つのアドレスを問い合わせ、どのインターフェースを挙げるか確認します。Linux、macOS、Windows はいずれも読み取り専用の検索で答え、何も送信せずに選択されたインターフェースと次のホップを報告します。トンネルが上がっているのに答えが物理アダプターを指す場合、カーネルはそのアドレスをトンネルが運べるものではなく、リンク上のものとして扱っています。

プロバイダーが割り当てたプレフィックスを、自宅ルーターが提供するプレフィックスの隣に置き、文字列として比較します。完全一致は明快なケースで、自宅のサブネットを含むより広いプロバイダーのプールも同じように失敗しますが、見落としやすいだけです。似て見えるだけの二つのプレフィックスは衝突ではないので、何かを変える前に両方を書き留めます。

クライアントが実際に受け取ったプールを読む

プロバイダーの宣伝ページではなく、クライアントが受け取ったものを読みます。OpenVPN クライアントのログの詳細度を上げるとサーバーが押し付けたルートがそこに現れてトンネルのプレフィックスが分かる一方、他の場所では接続の詳細やアダプター自体にプールが現れます。プロバイダーが使うプライベート範囲の完全な一覧を求めてください、今日の /24 が明日には二つになるかもしれませんから。よくある RFC 1918 のブロックを避けることは、実際に与えられた割り当てを避けることとは違います。

プールは縮小したり地域間を移動したりするので、一覧には日付と担当者が必要です。最後の計画変更より古いプロバイダーの回答は、事実ではなく推測として扱います。範囲に決める前に再度尋ね、回答はネットワークのメモと一緒に保管して次の人が証拠を引き継げるようにします。

自分でできる修復は番号の付け替えです

VPN サーバーが自分で変更できないものであれば、 自宅 LAN を移すことが唯一の修復手段です、商用プロバイダーではこれが普通の状況です。プロバイダーのプールの外側で、後で必要になりそうな範囲の外側の範囲を選び、トンネル経由で到達する他のすべての拠点と照合します。短い停止と、忘れられた機器という長い尻尾を想定してください：古いアドレスを持ったままの機器は、ゲートウェイが必要になるまで動いているように見えます。

1. まず棚卸しとして、ルーター自身のアドレス、DHCP の範囲、予約、ポート転送、そして手入力でアドレスを設定した機器すべてを確認します。
2. 次に、メンテナンス時間内にルーターの LAN プレフィックスと DHCP の範囲を同時に変え、有線のリースを無線より先に更新します。
3. そのうえで、プリンターやネットワークストレージ、ゲートウェイを直接書き込んだものなど、固定アドレスを直します。
4. 最後に VPN クライアントを再接続し、トンネルのアドレスが LAN と衝突しなくなったことを確認します。

アドレスは一度にではなくその順序で進め、古い範囲はしばらく文書に残して、古い機器が謎ではなく見分けられるようにします。まったく更新しない機器は、ゲートウェイに届かないことで自らを知らせますが、これはサポートへの電話よりはるかに良い手がかりです。ルーターが一日より長いリースを配るなら、作業時間の間だけ短くします。

エイリアスにできることとできないこと

サーバーが自分のものであれば、クライアント側でアドレスを変換して、遠隔のプレフィックスを空いたローカル範囲の中に見せられ、同じホストが二つ目のアドレスで応答します。コミュニティ版の OpenVPN はこれを client-natで行いますが、このディレクティブはそのクライアント固有のもので、よく比較される商用やモバイルのクライアントにはありません。この構成には、変換に対応するルート、エイリアス用の空き範囲、クライアントの未変換アドレスに応答するサーバーが必要です。管理されたプロバイダーのクライアントで設定できない場合は、どれも役に立ちません。

変更が反映されたら、まずアドレスで、次に名前でローカルホストと遠隔ホストに到達し、システムが毎回選ぶルートを記録します。名前がまだ古い範囲に解決されることがあるので、アドレスと名前は別々に確認する価値があります。変更の間ずっと起動したままだったものがあれば、クライアントとサーバー側の機器を一つずつ再起動します、キャッシュされた近隣エントリは編集より長く生き残るからです。

決めたプレフィックスは、人が実際に見る場所、つまりネットワークのメモやルーター自身のコメント欄、案内ページに書きます。誰かがまた 192.168.1.0/24 を選び、衝突はその人とともに戻ってきます。