VPN valt steeds weg? Werk dit in deze volgorde af

Voordat u de client opnieuw installeert, schrijft u drie dingen op: hoe lang de tunnel overeind bleef, wat de client zei toen hij wegviel, en of de machine tussendoor sliep of van netwerk wisselde. Die notitie is het enige bewijs dat u later hebt, en een herinstallatie wist die meestal uit. Een onderbreking met een herhaalbaar interval is een timer of een verlopen status; een onderbreking op een willekeurig moment is een probleem met het pad. De volgorde hieronder voorkomt dat u drie dingen tegelijk wijzigt en niets leert.

Stap één: leg het interval en de fouttekst vast

Begin met het eigen log van de client in plaats van het dashboard van de leverancier. Op een Linux-client dekken het servicelog plus de live status van de tunnel het meeste:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Noteer de tijdstippen van de laatste geslaagde handshake en het moment waarop het verkeer stopte, niet alleen het moment waarop het pictogram van kleur veranderde. Een GUI-client die achteraf zegt dat de verbinding weg is, meldt misschien een status die de kernel seconden eerder bereikte.

Bewaar de formulering van de fout. Een time-out, een weigering van authenticatie en een adapter- of stuurprogrammafout wijzen op drie verschillende lagen, en het meeste verloren werk in dit probleem komt doordat ze als één worden behandeld. Kopieer de regel woordelijk in uw notitie.

Stap twee: wijzig één variabele, niet het profiel

Houd het apparaat en het profiel vast en verplaats de machine naar een ander toegangsnetwerk, bijvoorbeeld een hotspot van een telefoon. Dit is de goedkoopste test die de client van het pad scheidt. Laat hem lang genoeg lopen om het oorspronkelijke foutinterval te dekken; twee stabiele minuten bewijzen niets over een onderbreking die in de dertigste minuut optreedt.

Een laptop met een Ethernet-poort geeft een tweede vergelijking die Wi-Fi volledig uit het beeld haalt. Als de tunnel op beide alternatieven standhoudt, verdient het oorspronkelijke toegangsnetwerk aandacht: roaming tussen accesspoints, een thuisrouter waarvan de vertaaltabel verloopt, of een upstream-verbinding die langdurige stromen reset.

Schrijf op welke variabele u hebt gewijzigd. Een vergelijking telt alleen als al het andere gelijk bleef, en dat omvat het eindpunt van de server en het tijdstip van de dag.

Stap drie: koppel het interval aan een laag

De duur van een goede sessie is het meest informatieve enkele getal dat u hebt. Lees het tegen deze lijst voordat u timers aanraakt:

• Onderbreking na slaap of hervatten: de tunnelstatus overleefde de onderbreking, maar de interface niet. Controleer het herverbindingsgedrag van de client bij hervatten en of de dienst de tunnel opnieuw start of op verkeer wacht.
• Onderbreking alleen bij inactiviteit: iets in het midden liet de stroom verlopen. Daar bestaan keepalives juist voor.
• Onderbreking bij een vaste sessieleeftijd: een gebeurtenis van herauthenticatie of sleutelvernieuwing, geen padfout. Een expliciete weigering in het log precies op dat interval is het teken.
• Onderbreking tijdens grote overdrachten of grote pagina's: verdenk MTU en fragmentatie, niet een inactiviteitstimer.

Voor het inactiviteitsgeval zijn de instellingen protocolspecifiek en beide uiteinden tellen. OpenVPN's keepalive 10 60 op de server stuurt elke 10 seconden een ping en herstart de verbinding na 60 seconden zonder; WireGuard-clients achter NAT gebruiken PersistentKeepalive = 25 in het peer-blok. OpenVPN onderhandelt ook het datakanaal opnieuw op een timer, reneg-sec, die standaard 3600 seconden is in 2.x.

Kopieer geen agressieve waarden uit de gids van een andere provider. Een korte time-out op een mobiele verbinding met verlies veroorzaakt juist de onderbrekingen die hij moest voorkomen, en waarden die de server pusht overschrijven wat u in het clientprofiel instelt.

Stap vier: vergelijk één ondersteund alternatief

Als de operator zowel een UDP- als een TCP-profiel publiceert, voer dan hetzelfde apparaat en netwerk uit tegen het andere. Gebruik het werkelijke bijpassende bestand in plaats van het transport in een gekopieerd profiel te bewerken. Een stabiel TCP-profiel op een pad waar UDP wordt gereset, beperkt het probleem tot dat pad; het bewijst niet dat TCP overal het betere transport is.

Dezelfde logica geldt voor eindpunten. Probeer een andere server en houd het oorspronkelijke resultaat ernaast. Als slechts één uitgang sessies reset, is dat bewijs over dat eindpunt, geen reden om elke adapter op de laptop opnieuw op te bouwen.

Herhaal na elke wijziging de oorspronkelijke trigger en bevestig waar het verkeer werkelijk heen gaat. Herwonnen internettoegang is niet hetzelfde resultaat als verkeer binnen de tunnel, en een client die stil terugviel op een directe route ziet er gezond uit vanuit de browser.

Verifieer de oplossing en houd de terugweg

Een oplossing wordt geverifieerd door de oorspronkelijke trigger te reproduceren, niet door een geslaagde verbinding. Laat de tunnel inactief voorbij het oude foutinterval, schort hem één keer op en hervat, en controleer daarna de leeftijd van de handshake en het uitgangsadres:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Houd het vorige profiel en de vorige timerwaarden tot het nieuwe gedrag een volledige werkdag overleeft. Als de onderbrekingen terugkomen, herstel de back-up en pas daarna de wijzigingen één voor één opnieuw toe, zodat de tweede poging vanuit een bekende toestand begint.

Als het log schoon blijft en de tunnel nog steeds met een herhaalbaar interval wegvalt, is de volgende stop de serverkant voor die sessie. Neem de sessie-identificatie van de client en het exacte tijdstip van de onderbreking mee, want dat paar maakt een serverlog doorzoekbaar. De linkopties van het protocol staan in de OpenVPN 2.6-handleiding wanneer u de exacte betekenis van een waarde nodig hebt.