VPN se doma připojí, ale v hotelovém Wi-Fi vyprší časový limit
Stejný notebook, stejný účet, jiná síť. Čtěte kód chyby jako etapu, zkontrolujte název a poté zachyťte vnější paket, než změníte jakékoli nastavení.
Notebook se připojí k domácímu Wi-Fi, klient se spojí za tři sekundy a stejný profil o hodinu později v hotelu selže. Mezitím se nic neaktualizovalo. Projít to s klientem před sebou znamená hlavně vědět, která chyba patří které etapě, protože užitečná informace je v kódu, který klient vypíše, ne v tom, že selhal. Projděte čtyři kroky níže v pořadí a budete vědět, zda vás odmítlo jméno, paket, port nebo zásada.
Čtěte kód chyby jako etapu, ne jako rozsudek
Klient dosáhne tří samostatných milníků, než tunel existuje. Přeloží jméno serveru, dostane odpověď od něčeho v síti a vyjedná bezpečnostní asociaci. Každý milník má vlastní zprávu o selhání a Windows je obzvlášť štědrý na odlišné kódy, jakmile víte, ke které etapě patří.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
Dva z těch kódů znamenají, že síť je nevinná. 789 znamená, že pakety tekly a obě strany se neshodly na kryptografii, což je konfigurační problém, který můžete opravit doma. 868 znamená, že žádný paket nemusel vůbec odejít, takže návrh tunelu je irelevantní, dokud se jméno nepřeloží. Zařazení kódu do správné etapy ušetří více času než jakýkoli odchyt, protože vám řekne, který z následujících tří kroků přeskočit.
Buďte přiměřeně opatrní, pokud klient není Windows. Klienti třetích stran většinu z toho sloučí do "připojení selhalo", a proto se další dva kroky na zprávu vůbec nespoléhají.
Zkontrolujte název, než obviníte tunel
Hotelové a letištní sítě neustále zachytávají DNS a resolver, který odpovídá adresou portálu, vytváří selhání, které vypadá přesně jako mrtvý server. Porovnejte, co říká místní resolver, s tím, co říká veřejný:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"Pokud se obě odpovědi liší, jste přesměrováváni a zbytek diagnostiky je ztracen, dokud se to nevyřeší. Zejména adresa portálu ochotně přijme TCP spojení a pak se zasekne, a proto to při testu v prohlížeči může vypadat jako blokace firewallem.
Nyní potvrďte, že adresa, kterou chcete dosáhnout, je ta používaná. Někteří klienti ukládají předchozí překlad po celou dobu života profilu, takže opětovné připojení po změně DNS stále jde na starou adresu. Před novým testem klienta úplně zavřete, místo abyste v tomtéž okně mačkali odpojit a připojit.
Zjistěte, který vnější paket mizí
Tunel má vnější tok, který patří zcela cestě mezi vámi a serverem, a právě ten tok mezilehlá zařízení klasifikují a zahazují. Zachyťte ho na klientovi a poté porovnejte funkční síť se selhávající. Ve Windows stačí pro první pohled vestavěný odchyt:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlChcete vidět, zda vaše pakety vůbec odcházejí a zda se něco vrací. Pakety ven bez jakékoli odpovědi znamenají, že je cesta nebo vzdálený konec zahazuje; když neodejde nic, klient se vůbec nedostal k odesílání, což ukazuje zpět na překlad jmen nebo na místní zásadu firewallu.
Zopakujte stejný test na hotspotu z telefonu. To je jediné nejinformativnější srovnání, které máte k dispozici, protože z cesty odstraní každou krabici v hotelu a přitom notebook, klient i přihlašovací údaje zůstanou stejné. Pokud tunel na hotspotu naskočí, přestaňte se dívat na server. Pokud selže i tam, máte problém s klientem nebo účtem, který síť nikdy nezpůsobovala.
Změňte jeden transport a znovu otestujte
Jakmile víte, že se vnější tok zahazuje, praktická otázka je, který tok síť přece jen povoluje. Většina omezených sítí povoluje odchozí TCP 443, protože jinak nemůže fungovat, takže přesunout naslouchač tam je obvyklá odpověď. Na OpenVPN je to přepínač na straně klienta, dokud se nezmění server:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4Klienti IPsec mají ekvivalentní ovládací prvek ve svých panelech nastavení, obvykle popsaný jako IPsec přes TCP nebo průchod NAT. Změnit ho je také diagnostika: pokud tunel naskočí přes TCP a umře přes UDP, dokázali jste, že síť filtruje UDP, a také jste našli nastavení, které budete potřebovat při každé návštěvě toho místa.
Odolejte pokušení vypnout funkce routeru na první pokus. Vypnout stavovou inspekci nebo ochranu proti záplavě v hotelové síti vám stejně není dostupné, a na vlastním vybavení to vymění skutečnou ochranu za jeden notebook. Poznamenejte si, které nastavení změnilo výsledek, potom ho vraťte a hledejte transport, který síť už povoluje.
Ověřte stejný profil v druhé síti
Než tiket zavřete, dokažte, že změna přežila odchod z budovy. Připojte se znovu v původní síti s původním nastavením, zachyťte prvních třicet sekund a potvrďte, že klient dosáhne stejného stavu jako na hotspotu:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressRozdíl, který poslední příkaz odhalí, stojí za to si ponechat: profil může hlásit připojený tunel, i když je směrování uvnitř špatné, a to dává "VPN běží, ale nic nefunguje", což je jiný článek. Pokud se typ tunelu po vaší úpravě změnil, profil není ten, který jste testovali.
Poté zapište zjištění tam, kam se podívá další člověk. "Firemní profil potřebuje na tomto místě TCP 443; UDP 500 hotel filtruje" je věta, na kterou kolega může reagovat. "VPN je v hotelích nestabilní" není, a zaručuje, že stejná hodina se příští měsíc stráví znovu.