インターフェースインデックスに固定したVPNルートは再接続で壊れる

アダプター番号に紐づけたルートは、その番号が変わると死ぬ。ストアを確認し、プレフィックスをプロファイルに結びつけ、新しい順序で再接続しよう。

ルートは何週間も機能していたのに、宛先は変わらず何も編集していないのに、突然どこにもトラフィックを送らなくなった。変わったのは番号であり、特定のインターフェースインデックスに対して作られたルートは、再接続後に存在しなくなったアダプターを指したままで、宛先プレフィックスは交換された配管を指し続ける。そのコマンドに永続性を足しても効かないのは、問題がルートの再起動生存ではなかったからだ。解決策は意図を接続に結びつけることであり、接続は設計上アダプターの入れ替えを生き延びる。

ルートが実際に何を指しているかを確認する

まずルートの項目とアダプターを並べて読む。VPNインターフェース上のネクストホップを持ち、現在のどのアダプターにも一致しないインデックスを持つルートがこの障害の特徴であり、別のインデックスにある同じプレフィックスは残骸か本当に欲しいルートのどちらかだ。どちらかを変更する前に両方の一覧を読み、意味のある比較はルート内の番号と現在存在する番号の間にあると心得る。ルートのインデックスがアダプター一覧にあれば、インデックスは問題ではなく、調査はメトリック、ポリシー、あるいは遠端へ移る。なければ、ルートはもう存在しない配管に結びついているので、これ以上診断することはない。

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

Store列は再起動をまたいで残る項目とアダプターとともに消える項目を区別する。その違いが明日また障害が現れるかを決め、消えたインデックスを指す永続ストアの項目は、再起動を生き延びるのに決して何とも一致しないため最悪のケースだ。

プレフィックスはアダプターではなくプロファイルに結びつける

Windows標準のVPNは独自のルート一覧を持てるので、接続は上がるたびに正しいアダプターを再利用する。そうすればルートは一度観察した番号ではなくプロファイルに従い、ダイヤルごとにスクリプトがインデックスを推測する必要もない。プレフィックスの追加は対応する削除コマンドで元に戻せるので、変更は監査可能なままになる。プレフィックスは起動スクリプトではなく接続と一緒に保存されるため、別のユーザーにコピーしたプロファイルは意図も一緒に運ぶ。

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Add-VpnConnectionRouteのリファレンスは接続との関連を記述しており、ユーザーごとのプロファイルと全ユーザーのプロファイルという電話帳のスコープが重要だ。この仕組みはWindows自身のVPNクライアントに属するので、独自のサービスが管理するベンダーのアダプターはまったく別のポリシー源からルートを取ることがある。

新しいルートを追加する前に古いルートを片づける

同じプレフィックスで所有者の違うルートが二つあるのは、どちらが勝つかが誰も記録していないメトリック次第なので、間違ったルート一つより悪い。プレフィックスに対して既に何があるかを永続ストアの項目も含めて調べ、失敗した試みに属するものだけを削除する。以前の設計の残骸はこの領域ではよくあるが、失敗しているルートはたいてい機能していた何かを置き換えているからだ。何かを削除する前にどの項目がどの接続に属するかを記録し、一覧を変更記録に残す。

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

プレフィックス、ネクストホップ、ストア、所有者をまとめて突き合わせ、似て見えるものを片っ端から消してはいけない。別の接続がその空間の一部に正当に依存していることがあり、一括削除は整った修理をサポート案件に変えてしまう。

別の順序で再接続する

最初の試行が代表的だったと願うのではなく、条件を再現する。切断し、再接続し、トンネルが上がっている間に同じ遠隔リソースへの選択経路を確認し、複数のVPNが関わるなら別の順序で起動して選ばれる経路が変わるかを見る。順序は多くの人が飛ばす変数であり、間違った接続に結びついたルートを露わにするのはまさにこれだ。

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

欲しい結果は、アダプターが一度だけ番号を保つことではない。接続が受け取るどの番号でも、毎回ルートが現れ、接続が閉じると消えることだ。二度再接続するのが、その結果を見分ける最も安い方法である。

ルートにできないことを知る

プロファイルのルートが与えるのは経路だけで、遠隔のファイアウォールを開けず、遠端に戻りのルートを作らず、同じアドレス範囲を使う二つの拠点を解決しない。どれも別の所有者を持つ別の設定だ。したがって経路の確認は受け入れ試験の始まりであり、試験の全体ではない。

プレフィックスの一覧はプロファイルと一緒に保ち、どのスコープで追加したかを記録する。そうすれば次の人がルート表から推測するのではなく意図した設計を読め、誰かの記憶にしかないルートこそ次の再接続の後に間違って作り直される。展開メモの一行のコメントは、半日分の再発見より安い。

関連記事