VPN anslutet men inget internet? Gå igenom de fyra lagren

Klienten säger ansluten, webbläsaren snurrar och varje webbplats slutar i tidsgräns. Den kombinationen är vanlig och inte en motsägelse: ansluten betyder att tunneln förhandlade, och inget mer. Namnuppslagning, routning och serverns egen utgång misslyckas var och en på sitt sätt, och var och en har olika ägare. Gå igenom lagren i ordning och stanna vid det första som misslyckas.

Börja med nätet du kom från

Koppla ner tunneln med klientens egen frånkopplingskontroll och prova sedan två oberoende HTTPS-webbplatser om policyn tillåter. Låt känsligt arbete vara stängt under testet. Om vanlig åtkomst också misslyckas är VPN inte den första misstänkta.

Titta på Wi-Fi-länken, routern och varje portalsida som kräver inloggning innan du rör tunneln. En kill switch kan blockera trafik medan du är frånkopplad enligt design, så följ dess dokumenterade testprocedur i stället för att dra slutsatsen att nätet är dött. Ett annat betrott nät är en användbar jämförelse, och en ny VPN-utgång slutför inte en utgången hotellinloggning. Om det öppna nätet fungerar och tunneln inte, är nätet frikänt och nästa lager är ditt.

Avgör om felet är namnuppslagning

Skriv ner feltexten, eftersom uppslagsfel, tidsgräns och certifikatvarning pekar var och en någon annanstans. Mönstret som måste fångas tidigt är ett värdnamn du aldrig besökt som misslyckas medan ett program med öppen session fortsätter. Det mönstret handlar om nya slagningar, inte om tunneln bär paket. En enda slagning visar vad resolvern returnerar, och det tar en sekund. Prova också ett andra namn, så att ett cachelagrat svar eller en trasig post inte avgör diagnosen.

nslookup example.com

En godtycklig IP i HTTPS-adressfältet är inte ett DNS-test, eftersom certifikatet och den virtuella värden oftast beror på namnet. Interna namn kan behöva organisationens resolver i stället för en offentlig ersättning, och en webbläsare med egen säker resolver kan svara annorlunda än operativsystemets slagning. Där de två skiljer sig är webbläsarens resolver den användaren upplever, och den skillnaden hör hemma i ärendet.

Full tunnel eller bara företagets subnät

Vissa profiler finns bara för att nå en handfull företagssubnät; andra är byggda för att bära allt och behöver en fungerande utgång bakom sig. Läs det dokumenterade syftet innan du antar att indikatorn täcker varje program och varje adressfamilj. En privatnätsprofil kan fungera precis som designat medan webbläsaren, som aldrig borde använda den, fortfarande misslyckas. Läs routingtabellen utan att ändra den, och ta med IPv6, eftersom en fungerande IPv4-väg inte säger något om den andra familjen.

En mer specifik rutt kan vinna medan standardrutten finns kvar, därför måste tabellen läsas och inte antas. Konkurrerande virtuella adaptrar kan också äga trafik du väntade dig någon annanstans, särskilt efter att en andra VPN-klient installerats och glömts bort. Ta inte bort standardrutten som experiment; det gör en diagnos till ett andra avbrott.

En enda webbplats som misslyckas bland de som fungerar är ett problem med den webbplatsen, och det bevisar också att tunneln bär trafik. Stopp som bara visas vid stora överföringar pekar på paketstorlek och inte på nåbarhet.

När servern aldrig vidarebefordrar något

Om varje destination misslyckas på två enheter och två åtkomstnät, är tunneln uppe och utgången vidarebefordrar inte. Just den kombinationen skiljer ett fel på serversidan från en enhet som är felkonfigurerad på ett ställe. Skicka frågorna om vidarebefordran, NAT och returväg till operatören, inte en skärmbild av indikatorn.

De tre täcker de flesta orsaker på serversidan, och det är operatörens uppgift att svara. OpenVPN:s felsökningssida för anslutning går igenom samma frågor från serversidan, så skicka den vidare med ärendet. En skärmbild av en grön indikator svarar inte på någon av dem.

Gå igenom klientloggen efter inloggning efter fel vid tillämpning av rutter, DNS-inställningar eller den virtuella adaptern. Fel i det skedet pekar på enheten och inte på servern. Ett fel som aldrig syns i loggen är lika upplysande, eftersom det flyttar misstanken till andra sidan.

Kontrollera ett lager i taget

När du ändrat något, anslut igen och upprepa exakt det program som misslyckades. En enda sida som laddas bevisar mindre än en upprepbar väg till de resurser profilen byggdes för. Två kommandon skiljer uppslagning från nåbarhet, och det andra är värdspecifikt. Kör curl-raden var som helst och sedan det ruttkommando som passar värden framför 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

Om den numeriska begäran fungerar och namnet inte, stanna vid DNS. Om ingen av dem fungerar, jämför routingtabellen med tunnelns förväntade standard och kontrollera familjen du faktiskt testar. Om rutten är rätt och begäran ändå dör vid utgången, tillhör den återstående frågan operatören, och bevisen du sparade är ärendet.