VPN forbinder derhjemme, men timer ud på hotellets Wi-Fi

Den bærbare kobler på hjemmets Wi-Fi, klienten forbinder på tre sekunder, og samme profil svigter på hotellet en time senere. Der er ikke blevet opdateret noget i mellemtiden. At gennemgå dette med en klient foran sig handler mest om at vide, hvilken fejl der hører til hvilken fase, fordi den nyttige information ligger i den kode, klienten udskriver, ikke i at den svigtede. Gå de fire trin nedenfor igennem i rækkefølge, og du vil vide, om et navn, en pakke, en port eller en politik afviste dig.

Læs fejlkoden som en fase, ikke som en dom

Klienten når tre separate milepæle, før der findes en tunnel. Den slår servernavnet op, den får et svar fra noget på netværket, og den forhandler en sikkerhedsassociation. Hver milepæl har sin egen fejlmeddelelse, og især Windows er gavmild med forskellige koder, når man ved, hvilken fase de hører til.

To af de koder betyder, at netværket er uskyldigt. En 789 betyder, at pakkerne flød, og at de to ender var uenige om krypto, hvilket er et konfigurationsproblem, du kan rette derhjemme. En 868 betyder, at ingen pakke nogensinde behøvede at forlade maskinen, så tunnellens design er irrelevant, indtil navnet slås op. At sortere koden i den rigtige fase sparer mere tid end nogen optagelse, fordi den fortæller dig, hvilket af de næste tre trin du kan springe over.

Vær passende forsigtig, hvis klienten ikke er Windows. Tredjepartsklienter kollapser det meste af dette til "forbindelsen mislykkedes", og derfor er de næste to trin slet ikke afhængige af meddelelsen.

Tjek navnet, før du bebrejder tunnelen

Hotel- og lufthavnsnetværk opfanger konstant DNS, og en resolver, der svarer med en portaladresse, giver en fejl, der ser præcis ud som en død server. Sammenlign, hvad den lokale resolver siger, med hvad en offentlig resolver siger:

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

Hvis de to svar er forskellige, bliver du styret, og resten af diagnosen er spildt, indtil det er løst. Især en portaladresse accepterer gerne TCP-forbindelsen og går derefter i stå, og derfor kan det se ud som en firewall-blokering, når du tester med en browser.

Bekræft nu, at den adresse, du vil nå, er den, der bruges. Nogle klienter cacher den forrige opslag i profilens levetid, så en genforbindelse efter DNS-ændringen stadig går til den gamle adresse. Luk klienten helt, før du tester igen, i stedet for at trykke afbryd og forbind i samme vindue.

Find ud af, hvilken ydre pakke der forsvinder

Tunnelen har en ydre strøm, der udelukkende hører til vejen mellem dig og serveren, og det er den strøm, mellemkasser klassificerer og dropper. Optag den på klienten, og sammenlign derefter et fungerende netværk med det svigtende. På Windows er den indbyggede optagelse nok til et første kig:

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 dine pakker overhovedet forlader maskinen, og om der kommer noget tilbage. Pakker ud uden noget tilbage betyder, at vejen eller den fjerne ende dropper dem; ingen pakker ud overhovedet betyder, at klienten aldrig nåede at sende, hvilket peger tilbage på navneopslag eller på en lokal firewall-politik.

Gentag den samme test på et telefon-hotspot. Det er den enkelt mest informative sammenligning, du har, fordi den fjerner hver boks på hotellet fra vejen, mens den bærbare, klienten og legitimationsoplysningerne forbliver identiske. Hvis tunnelen kommer op på hotspot'et, så hold op med at kigge på serveren. Hvis den også svigter der, har du et klient- eller kontoproblem, som netværket aldrig forårsagede.

Skift én transport og test igen

Når du ved, at den ydre strøm droppes, er det praktiske spørgsmål, hvilken strøm netværket overhovedet tillader. De fleste begrænsede netværk tillader udgående TCP 443, fordi de ikke kan fungere ellers, så at flytte lytteren derhen er det sædvanlige svar. På OpenVPN er det en kontakt på klientsiden, indtil serveren ændres:

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

IPsec-klienter har en tilsvarende kontakt i deres egne indstillingspaneler, normalt beskrevet som IPsec over TCP eller NAT-traversal. At ændre den er også en diagnose: hvis tunnelen kommer op over TCP og dør over UDP, har du bevist, at netværket filtrerer UDP, og du har også fundet den indstilling, du får brug for hver gang, du besøger det sted.

Modstå fristelsen til at slå routerfunktioner fra i første forsøg. At slå stateful inspektion eller flood-beskyttelse fra på et hotelnetværk er ikke tilgængeligt for dig alligevel, og på dit eget udstyr bytter det en reel beskyttelse for én bærbar. Notér, hvilken indstilling der ændrede resultatet, sæt den så tilbage, og led efter en transport, som netværket allerede tillader.

Bekræft samme profil på det andet netværk

Før du lukker sagen, skal du bevise, at ændringen overlevede at forlade bygningen. Forbind igen på det oprindelige netværk med de oprindelige indstillinger, optag de første tredive sekunder, og bekræft, at klienten når samme tilstand som på hotspot'et:

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

Den forskel, den sidste kommando afslører, er værd at beholde: profilen kan rapportere en forbundet tunnel, mens routing inde i den er forkert, og det giver "VPN'et er oppe, men intet virker", hvilket er en anden artikel. Hvis tunneltypen ændrede sig efter din redigering, er profilen ikke den, du testede.

Skriv derefter fundet, hvor den næste person vil kigge. "Firmaprofilen kræver TCP 443 på dette sted; UDP 500 filtreres af hotellet" er en sætning, en kollega kan handle på. "VPN er ustabilt på hoteller" er det ikke, og det garanterer, at den samme time bliver brugt igen næste måned.