VPN forbundet, men intet internet? Gå de fire lag igennem

Klienten siger forbundet, browseren snurrer, og hver side ender i en timeout. Den kombination er almindelig og ikke en modsætning: forbundet betyder, at tunnelen forhandlede, og ikke mere. Navneopløsning, routing og serverens egen udgang fejler hver på sin måde, og hver har en anden ejer. Gå lagene igennem i rækkefølge, og stop ved det første, der fejler.

Start med netværket, du kom fra

Tag tunnelen ned med klientens egen afbrydelseskontrol, og prøv derefter to uafhængige HTTPS-sider, hvis politikken tillader det. Lad følsomt arbejde være lukket i testens varighed. Hvis almindelig adgang også fejler, er VPN ikke den første mistænkte.

Se på Wi-Fi-forbindelsen, routeren og enhver portalsside, der kræver login, før du rører tunnelen. En kill switch kan blokere trafik, mens du er afbrudt, efter design, så følg dens dokumenterede testprocedure i stedet for at konkludere, at netværket er dødt. Et andet betroet netværk er en nyttig sammenligning, og en ny VPN-udgang fuldfører ikke et udløbet hotel-login. Hvis det åbne netværk virker, og tunnelen ikke gør, er netværket frikendt, og næste lag er dit.

Afgør, om fejlen er navneopløsning

Skriv fejlteksten ned, fordi en opløsningsfejl, en timeout og en certifikatadvarsel peger hver et andet sted hen. Mønstret, der skal fanges tidligt, er et værtsnavn, du aldrig har besøgt, der fejler, mens et program med en åben session fortsætter. Det mønster handler om nye opslag, ikke om hvorvidt tunnelen bærer pakker. Et enkelt opslag viser, hvad resolveren returnerer, og det tager et sekund. Prøv også et andet navn, så et cachet svar eller en ødelagt post ikke afgør diagnosen.

nslookup example.com

En vilkårlig IP i en HTTPS-adresselinje er ikke en DNS-test, fordi certifikatet og det virtuelle værtsnavn normalt afhænger af navnet. Interne navne kan kræve organisationens resolver i stedet for en offentlig erstatning, og en browser med sin egen sikre resolver kan svare anderledes end operativsystemets opslag. Når de to er uenige, er browserens resolver den, brugeren oplever, og den forskel hører i billetten.

Fuld tunnel eller kun virksomhedsundernet

Nogle profiler findes kun for at nå en håndfuld virksomhedsundernet; andre er bygget til at bære alt og kræver en fungerende udgang bag sig. Læs det dokumenterede formål, før du antager, at indikatoren dækker hvert program og hver adressefamilie. En privatnetværksprofil kan virke præcis som designet, mens browseren, der aldrig var ment til at bruge den, stadig fejler. Læs rutetabellen uden at ændre den, og medtag IPv6, fordi en fungerende IPv4-rute intet siger om den anden familie.

En mere specifik rute kan vinde, mens standardruten stadig findes, og derfor skal tabellen læses, ikke antages. Konkurrerende virtuelle adaptere kan også eje trafik, du forventede andre steder, især efter en anden VPN-klient er installeret og glemt. Slet ikke standardruten som et eksperiment; det gør en diagnose til et andet nedbrud.

Et enkelt fejlende websted blandt fungerende er et problem med det websted, og det beviser også, at tunnelen bærer trafik. Stop, der kun vises ved store overførsler, peger på pakkestørrelse frem for på rækkevidde.

Når serveren aldrig videresender noget

Hvis hver destination fejler på to enheder og to adgangsnetværk, er tunnelen oppe, og udgangen videresender ikke. Den kombination skiller en fejl på serversiden fra én enhed, der er konfigureret forkert ét sted. Send operatøren spørgsmålene om videresendelse, NAT og returvej, ikke et skærmbillede af indikatoren.

De tre dækker de fleste årsager på serversiden, og det er operatørens at svare på. OpenVPN-siden om fejlfinding af forbindelse går de samme spørgsmål igennem fra serversiden, så giv den videre med billetten. Et skærmbillede af en grøn indikator besvarer ingen af dem.

Gennemgå klientloggen efter login for fejl ved anvendelse af ruter, DNS-indstillinger eller den virtuelle adapter. Fejl på det trin peger på enheden frem for på serveren. En fejl, der aldrig vises i loggen, er lige så oplysende, fordi den flytter mistanken til den anden side.

Tjek ét lag ad gangen

Når du har ændret noget, skal du genoprette forbindelsen og gentage præcis det program, der fejlede. En enkelt side, der indlæses, beviser mindre end en gentagelig vej til de ressourcer, profilen blev bygget til. To kommandoer skiller opløsning fra rækkevidde, og den anden er værtspecifik. Kør curl-linjen overalt, og kør derefter den rutekommando, der passer til værten foran dig.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Hvis den numeriske anmodning virker, og navnet ikke gør, så bliv ved DNS. Hvis ingen af dem virker, sammenlign rutetabellen med tunnelens forventede standard, og tjek den familie, du faktisk tester. Hvis ruten er rigtig, og anmodningen stadig dør ved udgangen, tilhører det resterende spørgsmål operatøren, og de beviser, du gemte, er billetten.