VPN-verbinding time-out: DNS, transport, onderhandeling of aanmelding

“De verbinding is verlopen” is de minst specifieke fout die een VPN-client kan afdrukken. Het betekent dat één bewerking zijn deadline heeft gemist, en elke fase van naamresolutie tot het aanmeldingsantwoord heeft een deadline. Clients die alleen het laatste bericht tonen, laten de fasen identiek lijken, dus mensen verhogen de time-out, wijzigen de poort en herinstalleren het profiel, in die volgorde, zonder iets te leren. De fasen vergelijken is sneller: elke fase faalt op een andere plek, en elke fout laat een ander soort bewijs achter.

Vier fasen, vier verschillende fouten

De volgorde ligt vast, ook als de client die verbergt: de naam moet worden opgelost, er moet transport naar het resulterende adres worden opgezet, het protocol moet zijn parameters en sleutels onderhandelen, en het account moet worden geauthenticeerd. De handleiding voor verbindingsproblemen van OpenVPN volgt dezelfde volgorde voor zijn eigen client, en de andere volgen die nauw. Een time-out in fase twee en een in fase vier hebben niets gemeen behalve het woord op het scherm.

Lees in het logboek de laatste regel die voortgang aangeeft, niet de laatste regel vóór de fout. De meeste clients drukken iets af als een opgelost adres, een opgezette socket, een gestarte handshake of een authenticatieverzoek, en de fase ná die regel is degene die is verlopen.

Naamresolutie faalt voordat er iets wordt benaderd

Als het eindpunt nooit wordt opgelost, heeft de client niets om mee te verbinden en is er geen transportwerk gebeurd. Die fout is meestal direct in plaats van een volledige time-out, wat de goedkoopste manier is om hem van de rest te onderscheiden. Test de naam met de systeemresolver en met een tweede resolver, en vergelijk de twee antwoorden voordat je concludeert dat de server plat ligt.

Een oud adres uit een forumbericht is een veelvoorkomende oorzaak van een time-out die op een serverprobleem lijkt, omdat het adres nu bij iets anders of bij niets hoort. Gebruik het huidige profiel van de operator in plaats van een adres te vervangen dat eerder werkte. Een ontbrekend ping-antwoord is in geen enkele richting bewijs: veel eindpunten laten ICMP vallen terwijl ze prima dienen.

Transportopzet wacht op een pakket dat niet komt

Als DNS in orde is en de client toch de hele time-out verbrandt, is de transportlaag de verdachte. Op TCP kun je de poort direct testen; Test-NetConnection op Windows of nc -vz op Linux vertelt je of iets de verbinding accepteert, en dat is nuttiger dan een ping. Op UDP kan dat niet op dezelfde manier, omdat er op die laag geen handshake te voltooien is, en die asymmetrie veroorzaakt veel verkeerde conclusies.

Wat een TCP-test bewijst, is beperkt: een dienst die poort 443 accepteert is niet per se de VPN-listener, en een eindpunt met alleen UDP heeft geen TCP-poort om iets te accepteren. Een profiel van UDP naar TCP herschrijven maakt geen listener aan de andere kant; het verandert alleen waarop je client wacht. Als het netwerk het protocol filtert, levert de wijziging een andere time-out op in dezelfde fase.

Captive portals verdienen in deze fase hun eigen controle. Totdat de portal het apparaat autoriseert, gaat uitgaand verkeer naar de portal en blijft de tunnelpoging gewoon hangen. Rond de portal eerst af in een browser, probeer daarna opnieuw, en wijzig het profiel niet zolang de portal nog openstaat.

Onderhandeling en aanmelding betekenen dat de server heeft geantwoord

Zodra de tunnel de server bereikt, start de client een handshake en verandert de fout van karakter. Een stilstand hier gaat over compatibiliteit, niet over bereikbaarheid: niet-passende protocolversies, een cipher- of datakanaalinstelling die de andere kant niet accepteert, of een profiel dat een functie verwacht die de server niet biedt. OpenVPN heeft zijn standaardwaarden voor onderhandeling tussen hoofdversies vaak genoeg verschoven dat een profiel voor één generatie de server kan bereiken en toch niet omhoog komt.

Authenticatie is de laatste fase en het gemakkelijkst verkeerd te lezen. Een expliciete afwijzing is een antwoord, wat betekent dat het pad werkt en het probleem de identiteit, het certificaat of de accountstatus is. Een browsergebaseerde single sign-on-flow is een derde geval: de client wacht op een handeling die je niet hebt verricht, of op een browser die hij niet kan starten, en er komt niets tot je die stap afrondt.

Vergelijk het bewijs voordat je de nieuwe poging wijzigt

Houd het apparaat en het profiel vast en wijzig één ding tegelijk, te beginnen met het netwerk. Als hetzelfde profiel verbindt via een telefoonhotspot en een time-out krijgt op hotel-Wi-Fi, is het pad de variabele, niet de server. Als het overal faalt, is het profiel of het eindpunt de variabele. Als het alleen op een bepaald tijdstip faalt, leg de tijdstempel vast en vergelijk die met gebeurtenissen aan de serverkant voordat je iets over belasting aanneemt.

Voor een dienst die je beheert, is de beslissende vergelijking of de poging überhaupt aankomt. Een verbinding die de listener bereikt en dan stokt, hoort bij de onderhandelingsfase; een die nooit in het zicht van de listener verschijnt, is een transport- of resolutieprobleem, en geen enkele afstemming van nieuwe pogingen beweegt die. Serverlogs scheiden ook een geweigerde aanmelding van een stille drop, wat het verschil is tussen een identiteitscorrectie en een firewallcorrectie.

Noteer de clientversie, de profielnaam, de pogingstijd met de tijdzone en de eerste bruikbare fout in plaats van de laatste verbroken regel. Verwijder sleutels en materiaal met inloggegevens voordat je het fragment deelt. Maak daarna één betekenisvolle correctie en probeer opnieuw, want een langere deadline helpt alleen de gedocumenteerde langzame bewerking en doet niets voor een verkeerd adres of een geblokkeerde poort.