VPN łączy się w domu, ale w Wi-Fi hotelu kończy się czas

Laptop łączy się z Wi-Fi w domu, klient łączy w trzy sekundy, a ten sam profil zawodzi w hotelu godzinę później. Między tym nic nie zostało zaktualizowane. Przechodzenie przez to z klientem przed sobą polega głównie na wiedzy, który błąd należy do którego etapu, bo użyteczna informacja jest w kodzie, który wypisuje klient, a nie w tym, że się nie udało. Wykonaj cztery poniższe kroki po kolei, a dowiesz się, czy odmówiła ci nazwa, pakiet, port czy zasada.

Czytaj kod błędu jako etap, nie jako wyrok

Klient osiąga trzy odrębne kamienie milowe, zanim istnieje tunel. Rozwiązuje nazwę serwera, dostaje odpowiedź od czegoś w sieci i negocjuje asocjację bezpieczeństwa. Każdy kamień milowy ma własny komunikat błędu, a zwłaszcza Windows hojnie sypie różnymi kodami, gdy wiesz, do którego etapu należą.

Dwa z tych kodów oznaczają, że sieć jest niewinna. 789 oznacza, że pakiety płynęły, a oba końce nie zgadzały się co do kryptografii, co jest problemem konfiguracji, który możesz naprawić w domu. 868 oznacza, że żaden pakiet nie musiał wychodzić, więc projekt tunelu jest nieistotny, dopóki nazwa nie zostanie rozwiązana. Zaklasyfikowanie kodu do właściwego etapu oszczędza więcej czasu niż jakiekolwiek przechwycenie, bo mówi, który z trzech kolejnych kroków pominąć.

Bądź odpowiednio ostrożny, jeśli klient nie jest Windows. Klienci firm trzecich sprowadzają większość tego do "połączenie nieudane", dlatego kolejne dwa kroki wcale nie polegają na komunikacie.

Sprawdź nazwę, zanim obwinisz tunel

Sieci hotelowe i lotniskowe stale przechwytują DNS, a resolver odpowiadający adresem portalu daje błąd, który wygląda dokładnie jak martwy serwer. Porównaj, co mówi lokalny resolver, z tym, co mówi publiczny:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Jeśli obie odpowiedzi się różnią, jesteś przekierowywany, a reszta diagnostyki jest zmarnowana, dopóki to się nie rozwiąże. Zwłaszcza adres portalu chętnie przyjmie połączenie TCP, a potem się zawiesi, dlatego przy testach w przeglądarce może to wyglądać jak blokada zapory.

Teraz potwierdź, że adres, do którego chcesz dotrzeć, jest tym używanym. Niektórzy klienci buforują poprzednie rozwiązanie na cały okres życia profilu, więc ponowne połączenie po zmianie DNS nadal idzie na stary adres. Zamknij klienta całkowicie przed ponownym testem, zamiast naciskać rozłącz i połącz w tym samym oknie.

Ustal, który zewnętrzny pakiet znika

Tunel ma zewnętrzny przepływ, który należy w całości do ścieżki między tobą a serwerem, i właśnie ten przepływ urządzenia pośredniczące klasyfikują i odrzucają. Przechwyć go na kliencie, a potem porównaj działającą sieć z zawodzącą. W Windows wbudowane przechwytywanie wystarczy na pierwszy rzut oka:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Chcesz zobaczyć, czy twoje pakiety w ogóle wychodzą i czy coś wraca. Pakiety na zewnątrz bez niczego w odpowiedzi oznaczają, że ścieżka lub daleki koniec je odrzuca; jeśli nic nie wychodzi, klient nigdy nie doszedł do wysyłania, co wskazuje z powrotem na rozwiązywanie nazw lub lokalną zasadę zapory.

Powtórz ten sam test na hotspocie telefonu. To jedyne najbardziej informacyjne porównanie, jakie masz, bo usuwa ze ścieżki każdą skrzynkę w hotelu, zachowując laptop, klienta i dane logowania bez zmian. Jeśli tunel wstaje na hotspocie, przestań patrzeć na serwer. Jeśli tam też zawodzi, masz problem z klientem lub kontem, którego sieć nigdy nie powodowała.

Zmień jeden transport i przetestuj ponownie

Gdy wiesz, że zewnętrzny przepływ jest odrzucany, praktyczne pytanie brzmi, który przepływ sieć jednak dopuszcza. Większość ograniczonych sieci dopuszcza wychodzący TCP 443, bo inaczej nie mogłaby działać, więc przeniesienie nasłuchu tam jest zwykłą odpowiedzią. W OpenVPN to przełącznik po stronie klienta, dopóki serwer nie zostanie zmieniony:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Klienci IPsec mają równoważny przełącznik we własnych panelach ustawień, zwykle opisywany jako IPsec przez TCP lub przechodzenie NAT. Jego zmiana też jest diagnostyką: jeśli tunel wstaje przez TCP i umiera przez UDP, udowodniłeś, że sieć filtruje UDP, i znalazłeś też ustawienie, którego będziesz potrzebować przy każdej wizycie w tym miejscu.

Oprzyj się pokusie wyłączenia funkcji routera przy pierwszej próbie. Wyłączenie inspekcji stanowej lub ochrony przed zalaniem w sieci hotelowej i tak nie jest dla ciebie dostępne, a na własnym sprzęcie wymienia prawdziwą ochronę na jeden laptop. Zanotuj, które ustawienie zmieniło wynik, potem je przywróć i szukaj transportu, który sieć już dopuszcza.

Sprawdź ten sam profil w drugiej sieci

Zanim zamkniesz zgłoszenie, udowodnij, że zmiana przetrwała wyjście z budynku. Połącz się ponownie w oryginalnej sieci z oryginalnymi ustawieniami, przechwyć pierwsze trzydzieści sekund i potwierdź, że klient osiąga ten sam stan co na hotspocie:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Różnicę, którą ujawnia ostatnie polecenie, warto zachować: profil może zgłaszać połączony tunel, podczas gdy routing w nim jest błędny, a to daje "VPN jest włączony, ale nic nie działa", co jest innym artykułem. Jeśli po twojej edycji zmienił się typ tunelu, profil nie jest tym, który testowałeś.

Potem zapisz ustalenie tam, gdzie spojrzy następna osoba. "Profil firmowy wymaga TCP 443 w tym miejscu; UDP 500 jest filtrowany przez hotel" to zdanie, na którym kolega może działać. "VPN jest niestabilny w hotelach" nie jest, i gwarantuje, że ta sama godzina zostanie zmarnowana ponownie w przyszłym miesiącu.