VPN verbonden maar geen internet? Werk de vier lagen af

De client zegt verbonden, de browser draait en elke site eindigt in een time-out. Die combinatie is gebruikelijk en geen tegenspraak: verbonden betekent dat de tunnel onderhandelde, en niets meer. Naamresolutie, routing en de eigen uitgang van de server falen elk op hun eigen manier, en elk heeft een andere eigenaar. Werk de lagen op volgorde af en stop bij de eerste die faalt.

Begin bij het netwerk waar je vandaan kwam

Haal de tunnel weg met de eigen verbreekknop van de client en probeer daarna twee losstaande HTTPS-sites als het beleid dat toestaat. Laat gevoelig werk dicht tijdens die test. Als gewone toegang ook faalt, is de VPN niet de eerste verdachte.

Kijk naar de Wi-Fi-verbinding, de router en elke portalpagina die om inloggen vraagt voordat je de tunnel aanraakt. Een kill switch kan verkeer blokkeren terwijl je losgekoppeld bent volgens het ontwerp, dus volg de gedocumenteerde testprocedure in plaats van te concluderen dat het netwerk dood is. Een ander vertrouwd netwerk is een nuttige vergelijking, en een nieuwe VPN-uitgang maakt een verlopen hotel-login niet af. Als het open netwerk werkt en de tunnel niet, is het netwerk vrijgepleit en is de volgende laag aan jou.

Bepaal of de storing naamresolutie is

Schrijf de fouttekst op, want een resolutiestoring, een time-out en een certificaatwaarschuwing wijzen elk ergens anders heen. Het patroon dat je vroeg moet vangen, is een hostnaam die je nooit bezocht hebt die faalt terwijl een toepassing met een open sessie doorgaat. Dat patroon gaat over nieuwe opzoekingen, niet over of de tunnel pakketten draagt. Een enkele opzoeking laat zien wat de resolver teruggeeft, en kost een seconde. Probeer ook een tweede naam, zodat één gecachet antwoord of één kapot record de diagnose niet beslist.

nslookup example.com

Een willekeurig IP in de HTTPS-adresbalk is geen DNS-test, omdat het certificaat en de virtuele host meestal van de naam afhangen. Interne namen kunnen de resolver van de organisatie nodig hebben in plaats van een openbare vervanger, en een browser met een eigen veilige resolver kan anders antwoorden dan de opzoeking van het besturingssysteem. Waar die twee verschillen, is de resolver van de browser degene die de gebruiker ervaart, en dat onderscheid hoort in het ticket.

Volledige tunnel of alleen bedrijfs-subnetten

Sommige profielen bestaan alleen om een handvol bedrijfs-subnetten te bereiken; andere zijn gebouwd om alles te dragen en hebben een werkende uitgang achter zich nodig. Lees het gedocumenteerde doel voordat je aanneemt dat het lampje elke toepassing en elke adresfamilie dekt. Een profiel voor een particulier netwerk kan precies werken zoals ontworpen, terwijl de browser, die het nooit had moeten gebruiken, nog steeds faalt. Lees de routetabel zonder die te wijzigen, en neem IPv6 mee, want een werkende IPv4-route zegt niets over de andere familie.

Een specifiekere route kan winnen terwijl de standaardroute nog bestaat, daarom moet de tabel gelezen worden en niet aangenomen. Concurrerende virtuele adapters kunnen ook verkeer bezitten dat je elders verwachtte, vooral nadat een tweede VPN-client is geïnstalleerd en vergeten. Verwijder de standaardroute niet als experiment; dat maakt van een diagnose een tweede storing.

Eén falende site tussen werkende is een probleem van die site, en het bewijst ook dat de tunnel verkeer draagt. Storingen die alleen bij grote overdrachten optreden, wijzen op pakketgrootte en niet op bereikbaarheid.

Wanneer de server nooit iets doorstuurt

Als elke bestemming faalt op twee apparaten en twee toegangsnetwerken, is de tunnel omhoog en stuurt de uitgang niet door. Die combinatie scheidt een storing aan de serverkant van één apparaat dat op één plek verkeerd is ingesteld. Stuur de operator de vragen over doorsturen, NAT en terugweg, niet een schermafbeelding van het lampje.

Die drie dekken de meeste oorzaken aan de serverkant, en het is aan de operator om ze te beantwoorden. De OpenVPN-pagina over verbindingsproblemen loopt dezelfde vragen vanaf de serverkant door, dus geef die mee met het ticket. Een schermafbeelding van een groen lampje beantwoordt er geen van.

Neem de clientlog na het inloggen door op fouten bij het toepassen van routes, DNS-instellingen of de virtuele adapter. Fouten in die fase wijzen op het apparaat en niet op de server. Een fout die nooit in de log verschijnt, is even leerzaam, want die verplaatst de verdenking naar de andere kant.

Controleer één laag tegelijk

Zodra je iets verandert, verbind opnieuw en herhaal precies de toepassing die faalde. Eén pagina die laadt bewijst minder dan een herhaalbare weg naar de bronnen waarvoor het profiel is gebouwd. Twee opdrachten scheiden resolutie van bereikbaarheid, en de tweede is hostspecifiek. Voer de curl-regel overal uit en daarna de routeopdracht die bij de host voor je past.

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

Als het numerieke verzoek werkt en de naam niet, blijf bij DNS. Als geen van beide werkt, vergelijk de routetabel met de verwachte standaard van de tunnel, en controleer de familie die je werkelijk test. Als de route klopt en het verzoek sterft nog steeds bij de uitgang, hoort de resterende vraag bij de operator, en het bewijs dat je bewaarde is het ticket.