VPN kobler til hjemme, men timer ut på hotellets Wi-Fi

Den bærbare kobler til hjemmets Wi-Fi, klienten kobler til på tre sekunder, og samme profil feiler på hotellet en time senere. I mellomtiden er ingenting oppdatert. Å gå gjennom dette med en klient 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 feilet. Gå gjennom de fire trinnene nedenfor i rekkefølge, og du vil vite om et navn, en pakke, en port eller en policy avviste deg.

Les feilkoden som en fase, ikke som en dom

Klienten når tre separate milepæler før en tunnel finnes. Den slår opp servernavnet, den får et svar fra noe på nettverket, og den forhandler en sikkerhetsassosiasjon. Hver milepæl har sin egen feilmelding, og særlig Windows er raus med ulike koder når du vet hvilken fase de hører til.

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

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

Sjekk navnet før du klandrer tunnelen

Hotell- og flyplassnettverk fanger stadig opp DNS, og en resolver som svarer med en portaladresse gir en feil som ser nøyaktig ut som en død server. Sammenlign det den lokale resolveren sier med det en offentlig resolver 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 ulike, blir du styrt, og resten av diagnosen er bortkastet til det er løst. Særlig 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 cacher den forrige oppslaget for hele profilens levetid, så en gjentilkobling etter DNS-endringen går fortsatt til den gamle adressen. Lukk klienten helt før du tester på nytt, 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 helt tilhører 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 er det innebygde opptaket nok for et første blikk:

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 ut uten noe tilbake betyr at veien eller den fjerne enden slipper dem; hvis ingenting går ut, nådde klienten aldri å sende, noe som peker tilbake på navneoppslag eller på en lokal brannmurpolicy.

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

Bytt é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 lytteren 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-traversering. Å endre den er også en diagnose: hvis tunnelen kommer 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 stateful inspeksjon eller flombeskyttelse på et hotellnettverk er ikke tilgjengelig for deg uansett, og på ditt eget utstyr bytter det en reell beskyttelse mot én bærbar. Noter hvilken innstilling som endret resultatet, sett den så tilbake og let etter en transport nettverket allerede tillater.

Bekreft samme profil i 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

Skillet 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.