Azure P2S: jeden klient Windows traci trasy po zmianie VNet

Dwa laptopy uwierzytelniają się na tej samej bramie Azure point-to-site, a tylko jeden dociera do nowo podłączonego VNetu. Oba pokazują Connected, więc uwierzytelnianie nie jest różnicą; różnicą są trasy docelowe, które trzymają. Zacznij od klienta, który zawodzi, porównaj jeden cel i dopiero potem zdecyduj, czy lukę posiada pakiet bramy, czy lokalna tablica tras.

Zacznij od klienta, który zawodzi, nie od bramy

Potwierdź topologię, zanim obwinisz laptop. Sprawdź, które VNety są podłączone do VNetu bramy i czy nowa sieć jest peerowana bezpośrednio, czy osiągana przez osobny tunel site-to-site. Jeśli nowy VNet w ogóle nie jest podłączony do VNetu bramy, żaden pakiet klienta nie może tam routować, a działający laptop jest anomalią, którą trzeba wyjaśnić. Zapisz odpowiedź, bo decyduje, czy debugujesz klienta, czy bramę.

Gdy topologia się zgadza, postaw oba laptopy obok siebie. Ta sama brama, ta sama pula adresów, ten sam protokół i ta sama wersja klienta to porównanie, którego chcesz; wszystko inne jest drugą zmienną, którą później wyeliminujesz.

Porównaj jeden cel za pomocą route print

Wybierz dozwolony adres IP zasobu i porównaj oba laptopy dwa razy: rozłączone, a następnie połączone. W Windows route print -4 wyświetla trasy IPv4 z prefiksem celu, interfejsem, następnym przeskokiem i metryką. Zapisz wiersz, który naprawdę wygrałby dla tego celu, zamiast liczyć wpisy zawierające słowo VPN.

Wybór odbywa się najpierw według najdłuższego prefiksu, potem metryki, więc bardziej szczegółowa trasa lokalna może pokonać trasę tunelu, nie wyglądając na błędną. Jeśli zamierzony cel jest w 10.24.0.0/16, zdrowy klient pokazuje pasującą trasę na interfejsie VPN, a zawodzący klient wysyła ten sam adres do swojej bramy domyślnej.

Sprzeczny prefiks lokalny może dać ten sam objaw. Zanim cokolwiek dodasz, zdecyduj, który z dwóch przypadków masz: brak trasy tunelu w ogóle albo trasę tunelu, która przegrywa z bardziej szczegółową.

TTL expired to nie błąd dystrybucji tras

Ping zwracający TTL expired in transit mówi, że pakiet wykorzystał limit przeskoków, co zwykle oznacza pętlę przekazywania, a nie zepsuty sterownik VPN. Ping Windows akceptuje TTL do 255, a podniesienie wartości nie naprawia pętli; tylko opóźnia ten sam błąd. Traktuj komunikat jako objaw ścieżki, nie jako dowód dotyczący dystrybucji tras.

Użyj tracert -4 10.24.1.10, aby zobaczyć, gdzie ścieżka się powtarza. Jeśli te same dwa przeskoki pojawiają się raz za razem, szukaj trasy, która wysyła ruch kierowany do tunelu z powrotem do tunelu lub do lokalnego routera, który go odsyła.

Wygeneruj pakiet ponownie na bramie, która go posiada

Microsoft dokumentuje, że pakiety klienta Windows trzeba ponownie pobrać i zainstalować po istotnych zmianach topologii. Pobierz bieżący pakiet z bramy Azure, która obsługuje ten profil, a następnie zastosuj go obsługiwaną procedurą dla tego klienta. Zastąpienie pliku wykonywalnego niepowiązanej aplikacji VPN to nie ta sama operacja co ponowne wygenerowanie ustawień specyficznych dla bramy. Ponowne pobranie pakietu jest tanie; zgadywanie tras lokalnych nie.

Połącz się ponownie i ponownie odczytaj trasę dla pierwotnego celu. Zachowaj wiersze przed i po wraz z zapisem zmiany, aby wynik był dokładniejszy niż zainstalowałem klienta ponownie.

Scenariusze routingu Azure P2S oddzielają VNety peerowane bezpośrednio od sieci osiąganych przez inne tunele, a nowy pakiet nie może uczynić peeringu tranzytywnym. Niektóre scenariusze Windows site-to-site lub BGP wymagają też ręcznie skonfigurowanych tras zdalnych, więc odświeżenie pakietu nie jest uniwersalnym mechanizmem dystrybucji tras.

Zostaw trasę tymczasową tymczasową

Trasa ręczna może wyizolować brakującą trasę klienta, ale buduj ją z rzeczywistego projektu: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bez flagi trwałości, aby zniknęła po restarcie. Indeks interfejsu i następny przeskok wybierz z podłączonego adaptera VPN, nie ze zgadywania.

Nie zostawiaj trasy eksperymentalnej jako stałego konkurencyjnego właściciela. Przyszłe aktualizacje profilu mogą dodać ten sam prefiks z inną metryką i wtedy ręczny wpis po cichu decyduje, która ścieżka wygrywa. Zapisz krok usunięcia w zmianie.

Gdy poprawna trasa jest aktywna, testuj aplikację docelową, a nie ping. Jeśli pakiety docierają do Azure, ale usługa nadal zawodzi, sprawdź grupę zabezpieczeń sieci i ścieżkę powrotną, ponieważ są one niezależne od tego, czy laptop nauczył się prefiksu.