VPN koplar til heime, men går i tidsavbrot på hotell-Wi-Fi

Den berbare koplar til heimenettet, klienten koplar til på tre sekund, og same profil feilar på hotellet ein time seinare. I mellomtida er ingenting oppdatert. Å gå gjennom dette med ein klient framfor deg handlar mest om å vite kva feil som høyrer til kva fase, fordi den nyttige informasjonen ligg i koden klienten skriv ut, ikkje i at han feila. Gå gjennom dei fire trinna nedanfor i rekkjefølgje, og du vil vite om eit namn, ein pakke, ein port eller ein policy avviste deg.

Les feilkoden som ein fase, ikkje som ein dom

Klienten når tre separate milepålar før ein tunnel finst. Han slår opp servernamnet, han får eit svar frå noko på nettverket, og han forhandlar ein tryggingsassosiasjon. Kvar milepåle har si eiga feilmelding, og særleg Windows er raus med ulike kodar når du veit kva fase dei høyrer til.

To av desse kodane tyder at nettverket er uskuldig. Ein 789 tyder at pakkane flaut og at dei to endane var usamde om krypto, noko som er eit konfigurasjonsproblem du kan rette heime. Ein 868 tyder at ingen pakke nokon gong trong å gå ut, så tunnellutforminga er irrelevant til namnet er slått opp. Å sortere koden i rett fase sparer meir tid enn noko opptak, fordi det fortel deg kva av dei neste tre trinna du kan hoppe over.

Ver passeleg forsiktig om klienten ikkje er Windows. Tredjepartsklientar kollapsar det meste av dette til "tilkoplinga mislukkast", og difor er ikkje dei neste to trinna avhengige av meldinga i det heile.

Sjekk namnet før du klandrar tunnelen

Hotell- og flyplassnettverk fangar stadig opp DNS, og ein resolver som svarar med ei portaladresse gir ein feil som ser nøyaktig ut som ein daud server. Samanlikn det den lokale resolveren seier med det ein offentleg resolver seier:

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

Om dei to svara er ulike, blir du styrt, og resten av diagnosen er bortkasta til det er løyst. Særleg ei portaladresse tek gjerne imot TCP-tilkoplinga og stoppar deretter, og difor kan det sjå ut som ein brannmurblokk når du testar med ein nettlesar.

Stadfest no at adressa du vil nå, er den som blir brukt. Nokre klientar cachar det førre oppslaget for heile levetida til profilen, så ein gjenoppkopling etter DNS-endringa går framleis til den gamle adressa. Lat klienten heilt før du testar på nytt, i staden for å trykkje kople frå og kople til i same vindauget.

Finn ut kva ytre pakke som forsvinn

Tunnelen har ein ytre straum som heilt høyrer til vegen mellom deg og serveren, og det er den straumen mellomledd klassifiserer og slepp. Fang han på klienten, og samanlikn deretter eit fungerande nettverk med det som feilar. På Windows er det innebygde opptaket nok for eit 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 sjå, er om pakkane dine i det heile forlèt maskina, og om noko kjem tilbake. Pakkar ut utan noko tilbake tyder at vegen eller den fjerne enden slepp dei; om ingenting går ut, nådde klienten aldri å sende, noko som peikar tilbake på namneoppslag eller på ein lokal brannmurpolicy.

Gjenta den same testen på ein telefon-hotspot. Det er den einaste mest informative samanlikninga du har, fordi ho fjernar kvar boks på hotellet frå vegen medan den berbare, klienten og påloggingsdetaljane blir identiske. Om tunnelen kjem opp på hotspoten, slutt å sjå på serveren. Om han også feilar der, har du eit klient- eller kontoproblem som nettverket aldri forårsaka.

Byt éin transport og test på nytt

Når du veit at den ytre straumen blir sleppt, er det praktiske spørsmålet kva straum nettverket likevel tillèt. Dei fleste avgrensa nettverk tillèt utgåande TCP 443 fordi dei ikkje kan fungere elles, så å flytte lyttaren dit er det vanlege svaret. På OpenVPN er det ein brytar på klientsida til serveren blir endra:

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

IPsec-klientar har ein tilsvarande brytar i eigne innstillingspanel, vanlegvis skildra som IPsec over TCP eller NAT-traversering. Å endre han er også ein diagnose: om tunnelen kjem opp over TCP og døyr over UDP, har du prova at nettverket filtrerer UDP, og du har også funne innstillinga du treng kvar gong du vitjar den staden.

Motstå freistinga om å slå av rutarfunksjonar ved første forsøk. Å slå av stateful inspeksjon eller flaumbeskyttelse på eit hotellnettverk er uansett ikkje tilgjengeleg for deg, og på ditt eige utstyr byter det ein reell beskyttelse mot éin berbar. Noter kva innstilling som endra resultatet, set ho så tilbake og leit etter ein transport nettverket allereie tillèt.

Stadfest same profil i det andre nettverket

Før du lukkar saka, prov at endringa overlevde å forlate bygget. Kople til på nytt i det opphavlege nettverket med dei opphavlege innstillingane, ta opp dei første tretti sekunda, og stadfest at klienten når same tilstand som på hotspoten:

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

Skiljet den siste kommandoen avdekkjer, er verdt å halde på: profilen kan rapportere ein tilkopla tunnel medan rutinga inni han er feil, og det gir "VPN-et er oppe, men ingenting verkar", som er ein annan artikkel. Om tunneltypen endra seg etter redigeringa di, er profilen ikkje den du testa.

Skriv så funnet der den neste personen vil sjå. "Firmaprofilen treng TCP 443 på denne staden; UDP 500 blir filtrert av hotellet" er ei setning ein kollega kan handle på. "VPN er ustabilt på hotell" er det ikkje, og det garanterer at den same timen blir brukt igjen neste månad.