VPN kobler seg opp hjemme, men får tidsavbrudd på hotellets Wi-Fi

Maskinen kobler seg til Wi-Fi-en hjemme, klienten er oppe på tre sekunder, og den samme profilen feiler på hotellet en time senere. Ingenting er oppdatert i mellomtiden. Å gå gjennom dette med en kunde foran deg handler mest om å vite hvilken feil som hører til hvilken fase, fordi den nyttige informasjonen ligger i koden klienten skriver ut, ikke i at den mislyktes. Gå gjennom de fire trinnene nedenfor i rekkefølge, og du vil vite om det var et navn, en pakke, en port eller en policy som avviste deg.

Les feilkoden som en fase, ikke som en dom

Klienten passerer tre separate milepæler før tunnelen finnes. Den slår opp navnet til serveren, den får svar fra noe på nettverket, og den forhandler frem en sikkerhetsassosiasjon. Hver milepæl har sin egen feilmelding, og spesielt Windows er gavmild med ulike koder når du vet hvilken fase de tilhører.

To av disse kodene betyr at nettverket er uskyldig. En 789 betyr at pakkene fløt og at endene var uenige om kryptoen, som er et konfigurasjonsproblem du kan rette hjemme. En 868 betyr at ingen pakke noen gang trengte å gå ut, så tunnellens utforming er uten betydning til navnet er slått opp. Å plassere koden i riktig fase sparer mer tid enn noen opptak, fordi den forteller deg hvilket av de tre neste trinnene du kan hoppe over.

Vær rimelig forsiktig dersom klienten ikke er Windows. Tredjepartsklienter kollapser det meste av dette til "tilkoblingen mislyktes", og derfor er ikke de to neste trinnene avhengig av meldingen i det hele tatt.

Kontroller navnet før du gir tunnelen skylden

Hotell- og flyplassnettverk fanger hele tiden opp DNS, og en oppslagstjener som svarer med en portaladresse gir en feil som ser akkurat ut som en død server. Sammenlign det den lokale oppslagstjeneren sier med det en offentlig sier:

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

Hvis de to svarene er forskjellige, blir du omdirigert, og resten av diagnostikken er bortkastet til dette er løst. Spesielt en portaladresse tar gjerne imot TCP-tilkoblingen og stopper deretter, og derfor kan det se ut som en brannmurblokkering når du tester med en nettleser.

Bekreft nå at adressen du vil nå, er den som brukes. Noen klienter hurtiglagrer den forrige oppslaget for hele levetiden til profilen, så en ny tilkobling etter DNS-endringen går fortsatt til den gamle adressen. Lukk klienten helt før du tester igjen, i stedet for å trykke koble fra og koble til i samme vindu.

Finn ut hvilken ytre pakke som forsvinner

Tunnelen har en ytre strøm som fullt ut hører til veien mellom deg og serveren, og det er den strømmen mellomledd klassifiserer og slipper. Fang den på klienten, og sammenlign deretter et fungerende nettverk med det som feiler. På Windows holder det innebygde opptaket for et første overblikk:

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

Det du vil se, er om pakkene dine i det hele tatt forlater maskinen, og om noe kommer tilbake. Pakker uten noe tilbake betyr at veien eller den fjerne enden slipper dem; hvis ingenting går ut, kom klienten aldri til sending, noe som peker tilbake på navneoppslag eller på en lokal brannmurpolicy.

Gjenta den samme testen på et hotspot fra telefonen. Det er den eneste mest informative sammenligningen du har, fordi den fjerner hver boks på hotellet fra veien mens maskinen, klienten og påloggingsdetaljene forblir identiske. Kommer tunnelen opp på hotspoten, slutt å se på serveren. Feiler den også der, har du et klient- eller kontoproblem som nettverket aldri forårsaket.

Endre én transport og test på nytt

Når du vet at den ytre strømmen slippes, er det praktiske spørsmålet hvilken strøm nettverket likevel tillater. De fleste begrensede nettverk tillater utgående TCP 443 fordi de ikke kan fungere ellers, så å flytte lyttingen dit er det vanlige svaret. På OpenVPN er det en bryter på klientsiden til serveren endres:

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

IPsec-klienter har en tilsvarende bryter i egne innstillingspaneler, vanligvis beskrevet som IPsec over TCP eller NAT-gjennomgang. Å endre den er også en diagnose: kommer tunnelen opp over TCP og dør over UDP, har du bevist at nettverket filtrerer UDP, og du har også funnet innstillingen du trenger hver gang du besøker det stedet.

Motstå fristelsen til å slå av ruterfunksjoner ved første forsøk. Å slå av tilstandsinspeksjon eller flombeskyttelse på et hotellnettverk er uansett ikke tilgjengelig for deg, og på ditt eget utstyr bytter det en reell beskyttelse mot én maskin. Noter hvilken innstilling som endret resultatet, sett den så tilbake og let etter en transport nettverket allerede tillater.

Bekreft den samme profilen på det andre nettverket

Før du lukker saken, bevis at endringen overlevde å forlate bygningen. Koble til på nytt i det opprinnelige nettverket med de opprinnelige innstillingene, ta opp de første tretti sekundene, og bekreft at klienten når samme tilstand som på hotspoten:

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

Forskjellen den siste kommandoen avdekker, er verdt å beholde: profilen kan rapportere en tilkoblet tunnel mens rutingen inni den er feil, og det gir "VPN-et er oppe, men ingenting virker", som er en annen artikkel. Hvis tunneltypen endret seg etter redigeringen din, er profilen ikke den du testet.

Skriv så funnet der den neste personen vil se. "Firmaprofilen trenger TCP 443 på dette stedet; UDP 500 filtreres av hotellet" er en setning en kollega kan handle på. "VPN er ustabilt på hoteller" er det ikke, og det garanterer at den samme timen blir brukt igjen neste måned.