Windows VPN: zapisany profil a stan aktywnego interfejsu

Windows VPN pojawia się w dwóch miejscach, które odpowiadają na różne pytania, a ich pomylenie daje pewną siebie, ale błędną diagnozę. Zapisany profil mówi, co ktoś skonfigurował; aktywny interfejs mówi, co stos właśnie zastosował. Gdy połączenie zostanie nawiązane, a ruch nadal idzie złą drogą, trzeba odczytać oba widoki, właśnie w tej kolejności. Żaden z nich sam nie mówi, czy pakiet aplikacji opuścił tunel.

Dwa widoki tego samego tunelu

Widok profilu to konfiguracja: adres serwera, typ tunelu, metoda uwierzytelniania, ustawienia tunelu dzielonego. Może być poprawny, podczas gdy połączenie go ignoruje, i może być nieaktualny, podczas gdy połączenie działa bez zarzutu, bo klient, który łączy się ponownie, może nie odczytać ponownie tego, co edytowano. Widok interfejsu to stan zastosowany: jakie adaptery istnieją, jakie rodziny adresów przenoszą, ich metryki i stan połączenia. Zmienia się, gdy tunele pojawiają się i znikają, co czyni go właściwym miejscem dla pytania o routing na żywo i niewłaściwym dla pytania o konfigurację.

Czytanie ich razem to cała metoda, a czytanie tylko jednego to droga, na której ludzie usuwają zdrowy adapter. Poniższe polecenia dają oba widoki bez zmieniania czegokolwiek.

Odczytaj oba widoki bez zmieniania czegokolwiek

Zacznij od zapisanych profili, bo to najtańszy fakt do potwierdzenia. Zwróć uwagę na typ tunelu i wartość tunelu dzielonego, ponieważ oba decydują, które cele mają w ogóle wejść do tunelu. Jeśli profil jest błędny, popraw go przez jego obsługiwaną powierzchnię konfiguracji, bo nic na liście interfejsów nie naprawia profilu wskazującego złą bramę.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

Widok interfejsu ma inny kształt: jeden tunel może zajmować dwa wiersze, gdy przenosi obie rodziny adresów. Czytaj indeks jako tożsamość, a alias jako etykietę wybraną przez kogoś, i oczekuj, że alias zmieni się między wersjami klienta.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

Obecność nie jest dowodem użycia, bo interfejs może istnieć, być połączony i nadal nie być tym, który wybiera trasa do twojego celu. Miej to na uwadze, zanim uznasz nieznany adapter za winnego. Te dwa błędy wyglądają z zewnątrz identycznie: poprawny profil z trasą, która nigdy go nie używa, i błędny profil z trasą, która go używa. Mają zupełnie inne poprawki, i dlatego istnieje następna sekcja.

Śledź trasę do celu

Zapytaj stos, którą drogę wybrałby dla adresu, z którym aplikacja faktycznie się łączy. To pytanie, na które lista interfejsów nie potrafi sama odpowiedzieć.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

Pierwsze polecenie zgłasza dwa warte przeczytania pola: alias interfejsu wybranego źródła i następny skok dla tego celu. Indeks 37 w drugim poleceniu to to, co wydrukowało pierwsze wyjście, a nie stała do skopiowania, a adres 10.60.20.10 jest przykładowy. Jeśli wybrane źródło należy do adaptera fizycznego, a cel powinien być wewnątrz tunelu, znalazłeś problem wyboru, bo interfejs VPN może być całkowicie zdrowy i po prostu niepreferowany. Metryka to tylko część tej decyzji, ponieważ specyficzność trasy, polityka i stan interfejsu wszystkie w niej uczestniczą.

Porównaj trzy stany w tych samych warunkach

Zapisz listę interfejsów i wybraną trasę przed połączeniem, podczas połączenia i po rozłączeniu, za każdym razem z tym samym celem i tymi samymi poleceniami. To porównanie oddziela bieżący interfejs tunelu od starego ukrytego adaptera pozostawionego przez odinstalowanie i od drugiego klienta, który też działa. Mówi też, czy interfejs tunelu znika czysto, bo adapter, który pozostaje po rozłączeniu, to inny problem niż taki, który nigdy się nie pojawił. Bez trzech migawek każdy nieznany alias wygląda jak winowajca.

Zachowaj trzy wyjścia razem ze zgłoszeniem, bo dwa wyjścia poleceń biją akapit opisu. Kolega może je porównać, nie powtarzając twojej sesji.

Nie usuwaj tego, czego nie zidentyfikowałeś

Nieznane adaptery zwykle do czegoś należą: do zarządzanego klienta, przełącznika wirtualnego, sieci kontenerów lub agenta bezpieczeństwa. Usunięcie jednego może zabrać działający komponent i zostawić pierwotny objaw dokładnie tam, gdzie był. Jeśli trasa jest nieaktualna, znajdź właściciela trasy i popraw ją tam; jeśli profil jest błędny, edytuj profil. Dokumentacja Get-NetIPInterface wymienia użyte powyżej pola, w tym kolumny metryki i stanu, które czynią porównanie sensownym.

Nazwij obiekt, znajdź jego właściciela, a potem działaj na tym właścicielu. Wszystko inne to zmiana nazwy problemu zamiast jego odczytania.