広いVPNルートが一部の公開サイトを壊す理由
広いプレフィックスがアドレスを捕まえるため、一部のサイトだけが失敗し、残りは読み込まれます。ルートを解決済みアドレスと照合し、誰がそれを導入したかを突き止めます。
ほとんどのページは読み込まれ、二つか三つがタイムアウトし、ブラウザーは接続のせいにします。失敗するサイトには、正常なサイトにない共通点があります。解決済みアドレスが、VPNが導入したプレフィックスの内側に入っているのです。公開範囲を覆うほど広いルートは、トンネルが運ぶはずのなかった通信を捕まえ、症状はルーティングの判断ではなくウェブサイトの問題のように見えます。
失敗する名前を解決し、ブラウザーではなくルーティングテーブルを見ます。
サイト名ではなくアドレスを比較する
クライアントが実際に試したアドレスを調べ、どのルートがそれに一致するかを確認します。45.61.20.10 の内側の宛先は、そのプレフィックスがあれば 45.0.0.0/8 の下に入ります。サイト自体がトンネルと無関係であっても同じです。失敗するアドレスを導入済みプレフィックスと比べるのは引き算であり、当て推量ではありません。
Windowsは両方の半分に直接答えられ、検索はどのインターフェースと次のホップが選択に勝ったかを示します。サイトが複数のアドレスを返すなら、名前を二度解決します。それぞれを一致したルートとともに記録します。アドレスが違えば答えも変わり、失敗するのはそのうちの一つだけかもしれません。
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
最も具体的に一致するプレフィックスを読み、見覚えのある最初の行で止めません。テーブルにあるルートは検索に勝った証明にはならず、最長一致がそれを決めます。二つのプレフィックスが一つのアドレスに一致することがあり、パケットを受け取るのは一つだけです。負けた側もテーブルに残り、一覧では同じくらい本物に見えます。
プレフィックス、そのインターフェース、解決済みアドレスを書き留めます。この三つの値が診断のすべてです。
ルートを導入したのは誰かを見つける
ルートは四つの場所から来ます。ネイティブのVPNプロファイル、管理ポリシー、接続スクリプト、あるいはまったく別のクライアントです。有効なエントリを削除すれば関連を確認できますが、次の接続が保存済み構成からそれを再作成します。変えるべきは発生源です。
まずプロファイルのルート一覧、次に管理ポリシー、最後に接続時に走るスクリプトを確認します。この順序は、どれが担当していると判明する頻度に合っています。変更も三層ではなく一層に収まります。
ネイティブのクラスベース動作を注意して読む
ネイティブのWindowsプロファイルには文書化された設定 NativeProfile/DisableClassBasedDefaultRoute があり、インターフェースアドレスから推測される自動ルートを制御します。45で始まるプロファイルアドレスは、この動作のもとで 45.0.0.0/8 のエントリを生み出すことがあり、こうして一つの公開アドレスがクラスAの範囲全体を捕まえます。
プロパティ名は誤読を招きます。true にすると推測が無効になり、false で有効になります。既定ルートと同じ対象でもなく、独自のプレフィックスを導入する第三者クライアントを制御するものでもありません。
推測が実証された原因なら、管理上の所有者を通じてプロファイルを修正し、意図したプライベートプレフィックスを明示的に指定します。スクリプトがエントリを追加したのなら、スクリプトを直します。説明のつかない広いルートを別のものに置き換えても、症状が変わるだけで問いには答えていません。
発生源を直し、それから両方の経路を再確認する
変更後に再接続し、失敗する公開サイトと、トンネルを使うべきリソースの両方で検索を繰り返します。前者は物理インターフェースに解決し、後者は依然としてVPNを選ぶはずです。最初の成功で止めないでください。プライベートアクセスも壊す修正は、一つの不具合を別の不具合に交換しただけです。
同時にサーバーのアドレス計画も見直します。公開空間と重なるプールは、この種の問題を繰り返し起こします。運用者が意図して選んだ範囲は、自動的な再採番ではなく別の対話に値します。
MTUを上げたりDNSを消したりしても、そのアドレスを依然としてトンネルへ導くプレフィックスは直りません。まず選択を試し、それから経路を試します。