VPN ansluter hemma men får tidsgränsen att gå ut på hotellets Wi-Fi

Laptopen ansluter till hemmets Wi-Fi, klienten ansluter på tre sekunder, och samma profil misslyckas på hotellet en timme senare. Däremellan har ingenting uppdaterats. Att gå igenom detta med en kund framför sig handlar mest om att veta vilket fel som hör till vilken fas, eftersom den användbara informationen finns i koden klienten skriver ut, inte i att den misslyckades. Gå igenom de fyra stegen nedan i ordning så vet du om ett namn, ett paket, en port eller en policy nekade dig.

Läs felkoden som en fas, inte som en dom

Klienten når tre separata milstolpar innan en tunnel finns. Den löser servernamnet, den får ett svar från något på nätverket, och den förhandlar en säkerhetsassociation. Varje milstolpe har sitt eget felmeddelande, och särskilt Windows är generöst med olika koder när man vet vilken fas de hör till.

Två av dessa koder betyder att nätverket är oskyldigt. En 789 betyder att paketen flödade och att de två ändarna var oense om kryptot, vilket är ett konfigurationsproblem du kan åtgärda hemma. En 868 betyder att inget paket någonsin behövde gå ut, så tunnelns utformning är irrelevant tills namnet är löst. Att sortera koden i rätt fas sparar mer tid än någon inspelning, eftersom den talar om vilket av de nästa tre stegen du kan hoppa över.

Var lagom försiktig om klienten inte är Windows. Tredjepartsklienter pressar ihop det mesta av detta till "anslutningen misslyckades", och därför lutar sig de två nästa stegen inte alls mot meddelandet.

Kontrollera namnet innan du skyller på tunneln

Hotell- och flygplatsnätverk fångar ständigt upp DNS, och en resolver som svarar med en portadress ger ett fel som ser ut precis som en död server. Jämför vad den lokala resolvern säger med vad en offentlig resolver säger:

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

Om de två svaren skiljer sig blir du styrd och resten av diagnostiken är bortkastad tills det är löst. Särskilt en portadress tar gärna emot TCP-anslutningen och stannar sedan, och därför kan det se ut som en brandväggsblockering när du testar med en webbläsare.

Bekräfta nu att adressen du vill nå är den som används. Vissa klienter cachar den tidigare upplösningen under profilens hela livstid, så en återanslutning efter DNS-ändringen går fortfarande till den gamla adressen. Stäng klienten helt innan du testar igen, i stället för att trycka koppla från och anslut i samma fönster.

Ta reda på vilket yttre paket som försvinner

Tunneln har ett yttre flöde som helt tillhör vägen mellan dig och servern, och det är det flödet som mellanliggande boxar klassificerar och släpper. Fånga det på klienten och jämför sedan ett fungerande nätverk med det som misslyckas. På Windows räcker den inbyggda inspelningen för en första titt:

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

Det du vill se är om dina paket över huvud taget lämnar datorn, och om något kommer tillbaka. Paket ut utan något tillbaka betyder att vägen eller den bortre änden släpper dem; om ingenting går ut nådde klienten aldrig fram till att skicka, vilket pekar tillbaka på namnlösning eller på en lokal brandväggspolicy.

Upprepa samma test på en telefonhotspot. Det är den enda mest informativa jämförelsen du har, eftersom den tar bort varje box på hotellet från vägen medan laptopen, klienten och inloggningsuppgifterna förblir identiska. Om tunneln kommer upp på hotspoten ska du sluta titta på servern. Om den också misslyckas där har du ett klient- eller kontoproblem som nätverket aldrig orsakade.

Byt en transport och testa igen

När du vet att det yttre flödet släpps är den praktiska frågan vilket flöde nätverket ändå tillåter. De flesta begränsade nätverk tillåter utgående TCP 443 eftersom de inte kan fungera annars, så att flytta lyssnaren dit är det vanliga svaret. På OpenVPN är det en växel på klientsidan tills servern ändras:

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

IPsec-klienter har en motsvarande växel i sina egna inställningspaneler, vanligtvis beskriven som IPsec över TCP eller NAT-traversering. Att ändra den är också en diagnostik: om tunneln kommer upp över TCP och dör över UDP har du bevisat att nätverket filtrerar UDP, och du har också hittat inställningen du behöver varje gång du besöker den platsen.

Motstå frestelsen att stänga av routerfunktioner vid första försöket. Att stänga av tillståndskontroll eller översvämningsskydd på ett hotellnätverk är ändå inte tillgängligt för dig, och på din egen utrustning byter det en verklig skydd mot en enda laptop. Notera vilken inställning som ändrade resultatet, ställ sedan tillbaka den och leta efter en transport som nätverket redan tillåter.

Verifiera samma profil i det andra nätverket

Innan du stänger ärendet ska du bevisa att ändringen överlevde att lämna byggnaden. Anslut igen i det ursprungliga nätverket med de ursprungliga inställningarna, spela in de första trettio sekunderna och bekräfta att klienten når samma tillstånd som på hotspoten:

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

Skillnaden som det sista kommandot avslöjar är värd att behålla: profilen kan rapportera en ansluten tunnel medan routningen inuti den är fel, och det ger "VPN:et är uppe men ingenting fungerar", vilket är en annan artikel. Om tunneltypen ändrades efter din redigering är profilen inte den du testade.

Skriv sedan fyndet där nästa person kommer att titta. "Företagsprofilen behöver TCP 443 på den här platsen; UDP 500 filtreras av hotellet" är en mening en kollega kan agera på. "VPN är instabilt på hotell" är det inte, och det garanterar att samma timme spenderas igen nästa månad.