Trasa VPN przypięta do indeksu interfejsu psuje się przy ponownym połączeniu

Trasa działała tygodniami, po czym zaczęła wysyłać ruch donikąd, choć cel pozostał niezmieniony i nic nie zostało zmienione. Zmienił się numer: trasa utworzona dla konkretnego indeksu interfejsu wskazuje adapter, którego po ponownym połączeniu już nie ma, a prefiks docelowy nadal wskazuje na wymienioną infrastrukturę. Dodanie trwałości do tego polecenia nie pomaga, bo problemem nigdy nie było to, czy trasa przetrwa restart. Rozwiązaniem jest przypisanie intencji do połączenia, które z założenia przetrwa zmiany adapterów.

Sprawdź, na co trasa naprawdę wskazuje

Zacznij od odczytania wpisu trasy i adapterów obok siebie. Trasa z następnym skokiem na interfejsie VPN i indeksem, który nie pasuje do żadnego bieżącego adaptera, jest sygnaturą tej awarii; ten sam prefiks na innym indeksie jest albo pozostałością, albo trasą, której naprawdę chcesz. Przeczytaj obie listy, zanim zmienisz którąkolwiek, bo interesujące jest porównanie między numerem w trasie a numerami, które istnieją teraz. Jeśli indeks trasy pojawia się na liście adapterów, indeks nie jest twoim problemem, a poszukiwania przenoszą się na metryki, zasady lub drugi koniec. Jeśli go nie ma, nie ma czego dalej diagnozować: trasa jest powiązana z infrastrukturą, której już nie ma.

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

Kolumna Store odróżnia wpis, który przetrwa restarty, od wpisu, który znika wraz z adapterem, a ta różnica decyduje o tym, czy awaria wróci jutro. Wpis w magazynie trwałym wskazujący na nieistniejący indeks to najgorszy przypadek, bo przetrwa restarty, a nigdy z niczym nie pasuje.

Przypisz prefiks do profilu, nie do adaptera

Rodzimy VPN Windows może nieść własną listę tras, więc połączenie ponownie używa właściwego adaptera, ilekroć się pojawi. Trasa podąża wtedy za profilem, a nie za numerem, który raz zaobserwowałeś, i żaden skrypt nie musi zgadywać indeksu po każdym połączeniu. Dodanie prefiksu jest też odwracalne przez odpowiednie polecenie usuwające, co utrzymuje zmianę audytowalną. Prefiks jest przechowywany wraz z połączeniem, a nie w skrypcie startowym, więc profil skopiowany innemu użytkownikowi niesie intencję ze sobą.

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

Dokumentacja Add-VpnConnectionRoute opisuje powiązanie z połączeniem, a zakres książki telefonicznej ma znaczenie: profil dla jednego użytkownika i profil dla wszystkich użytkowników to różne obiekty. Ten mechanizm należy do własnego klienta VPN systemu Windows, więc adapter dostawcy zarządzany przez własną usługę może brać swoje trasy z zupełnie innego źródła zasad.

Wyczyść stare trasy, zanim dodasz nową

Dwie trasy z tym samym prefiksem i różnymi właścicielami są gorsze niż jedna błędna trasa, bo zwycięzca zależy od metryk, których nikt nie zapisał. Sprawdź, co już istnieje dla prefiksu, w tym wpisy w magazynie trwałym, i usuń tylko to, co należy do nieudanej próby. Pozostałość po wcześniejszym projekcie jest tu częsta, ponieważ zawodna trasa zwykle zastąpiła coś, co działało. Przed usunięciem czegokolwiek zanotuj, które wpisy należą do którego połączenia, i trzymaj listę w rejestrze zmian.

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

Dopasuj prefiks, następny skok, magazyn i właściciela razem, zamiast kasować wszystko, co wygląda podobnie. Inne połączenie może legalnie zależeć od części tej przestrzeni, a szerokie kasowanie zamienia porządną naprawę w incydent wsparcia.

Połącz ponownie w innej kolejności

Odtwórz warunek, zamiast liczyć na to, że pierwsza próba była reprezentatywna. Rozłącz się, połącz ponownie i potwierdź wybraną ścieżkę do tego samego zasobu zdalnego, gdy tunel jest aktywny; przy kilku VPN-ach podnieś je w innej kolejności i obserwuj, czy wybrana ścieżka się zmienia. Kolejność to zmienna, którą większość pomija, i właśnie ona ujawnia trasę przypiętą do niewłaściwego połączenia.

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

Wynik, którego chcesz, to nie to, że adapter raz zachowa swój numer. To, że trasa pojawia się z każdym numerem, jaki otrzyma połączenie, za każdym razem, i znika, gdy połączenie się zamyka. Dwukrotne ponowne połączenie to najtańszy sposób odróżnienia tych wyników.

Wiedz, czego trasa nie potrafi

Trasa z profilu daje ścieżkę i nic więcej. Nie otwiera zdalnej zapory, nie tworzy trasy powrotnej po drugiej stronie i nie rozwiązuje dwóch lokalizacji używających tego samego zakresu adresów; każde z tych to osobna konfiguracja z osobnym właścicielem. Potwierdzenie ścieżki jest więc początkiem testu odbiorczego, a nie całym testem.

Trzymaj listę prefiksów przy profilu i zanotuj, w jakim zakresie został dodany, aby następna osoba mogła przeczytać zamierzony projekt, zamiast wywnioskowywać go z tabeli tras. Trasy istniejące tylko w czyjejś pamięci to te, które po kolejnym połączeniu są odtwarzane błędnie. Komentarz w jednej linii w notatkach wdrożeniowych kosztuje mniej niż całe popołudnie ponownego odkrywania.