VPN kopplar ned hela tiden? Arbeta dig igenom detta i den här ordningen

Innan du installerar om klienten, skriv ned tre saker: hur länge tunneln var uppe, vad klienten sade när den föll och om maskinen sov eller bytte nätverk under tiden. Den anteckningen är det enda bevis du har senare, och en ominstallation raderar den oftast. Ett avbrott med ett upprepande intervall är en timer eller ett utgånget tillstånd; ett avbrott vid ett slumpmässigt tillfälle är ett vägproblem. Ordningen nedan hindrar dig från att ändra tre saker samtidigt och inte lära dig något.

Steg ett: anteckna intervallet och feltexten

Börja med klientens egen logg i stället för leverantörens instrumentpanel. På en Linux-klient täcker tjänsteloggen plus tunnelns aktuella tillstånd det mesta:

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

Anteckna tidsstämplarna för den senaste lyckade handskakningen och ögonblicket då trafiken stannade, inte bara ögonblicket då ikonen bytte färg. En GUI-klient som säger frånkopplad i efterhand rapporterar kanske ett tillstånd som kärnan nådde sekunder tidigare.

Behåll formuleringen av felet. En timeout, en avvisad autentisering och ett adapter- eller drivrutinsfel pekar på tre olika lager, och det mesta av bortkastat arbete i det här problemet kommer av att behandla dem som ett. Kopiera raden ordagrant till din anteckning.

Steg två: ändra en variabel, inte profilen

Håll enheten och profilen fasta och flytta maskinen till ett annat åtkomstnät, till exempel en telefonhotspot. Det här är det billigaste testet som skiljer klienten från vägen. Kör det tillräckligt länge för att täcka det ursprungliga felintervallet; två stabila minuter bevisar ingenting om ett avbrott som sker i trettionde minuten.

En bärbar dator med Ethernet-port ger en andra jämförelse som tar bort Wi-Fi helt från bilden. Om tunneln håller på båda alternativen förtjänar det ursprungliga åtkomstnätet uppmärksamhet: roaming mellan åtkomstpunkter, en hemrouter vars översättningstabell löper ut eller en uppströmslänk som återställer långlivade flöden.

Skriv ned vilken variabel du ändrade. En jämförelse räknas bara när allt annat är oförändrat, och det inkluderar serverns slutpunkt och tiden på dygnet.

Steg tre: koppla intervallet till ett lager

Längden på en bra session är det mest informativa enskilda tal du har. Läs det mot den här listan innan du rör timers:

• Avbrott efter sömn eller återupptagning: överlevde tunnelns tillstånd suspenderingen, men gränssnittet gjorde det inte. Kontrollera klientens återanslutningsbeteende vid återupptagning och om tjänsten startar om tunneln eller väntar på trafik.
• Avbrott endast vid inaktivitet: löpte något i mitten ut och avslutade flödet. Det är just det fallet keepalives finns för.
• Avbrott vid fast sessionsålder: en händelse för omautentisering eller nyckelförnyelse, inte ett vägfel. En tydlig avvisning i loggen exakt i det intervallet är tecknet.
• Avbrott under stora överföringar eller stora sidor: misstänk MTU och fragmentering, inte en inaktivitetstimer.

För inaktivitetsfallet är inställningarna protokollspecifika och båda ändarna spelar roll. OpenVPN:s keepalive 10 60 på servern skickar en ping var 10 sekund och startar om anslutningen efter 60 sekunder utan en; WireGuard-klienter bakom NAT använder PersistentKeepalive = 25 i peer-blocket. OpenVPN förhandlar också om datakanalen på en timer, reneg-sec, som som standard är 3600 sekunder i 2.x.

Kopiera inte aggressiva värden från en annan leverantörs guide. En kort timeout på en mobil länk med förluster producerar just de avbrott den skulle förhindra, och värden som skickas från servern åsidosätter det du ställer in i klientprofilen.

Steg fyra: jämför ett stött alternativ

Om operatören publicerar både en UDP- och en TCP-profil, kör samma enhet och nätverk mot den andra. Använd den faktiska matchande filen i stället för att redigera transporten i en kopierad profil. En stabil TCP-profil på en väg där UDP återställs begränsar problemet till den vägen; det bevisar inte att TCP är det bättre transportmedlet överallt.

Samma logik gäller för slutpunkter. Prova en annan server och håll det ursprungliga resultatet bredvid. Om bara en utgång återställer sessioner är det bevis om den slutpunkten, inte en anledning att bygga om varje adapter på den bärbara datorn.

Efter varje ändring upprepar du den ursprungliga utlösaren och bekräftar vart trafiken faktiskt tar vägen. Återvunnen internetåtkomst är inte samma resultat som trafik inne i tunneln, och en klient som tyst har fallit tillbaka på en direkt väg ser frisk ut från webbläsaren.

Verifiera åtgärden och behåll återställningen

En åtgärd verifieras genom att återskapa den ursprungliga utlösaren, inte genom en lyckad anslutning. Låt tunneln vara inaktiv förbi det gamla felintervallet, pausa och återuppta en gång, och kontrollera sedan handskakningens ålder och utgångsadressen:

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

Behåll den tidigare profilen och de tidigare timervärdena tills det nya beteendet överlever en hel arbetsdag. Om avbrotten återkommer, återställ säkerhetskopian och tillämpa sedan ändringarna igen en i taget så att det andra försöket börjar från ett känt tillstånd.

Om loggen förblir ren och tunneln fortfarande kopplar ned med ett upprepande intervall är nästa stopp serversidan för den sessionen. Ta med klientens sessionsidentifierare och den exakta tidpunkten för avbrottet, eftersom det paret är det som gör en serverlogg sökbar. Protokollets länkalternativ finns dokumenterade i OpenVPN 2.6-handboken när du behöver den exakta betydelsen av ett värde.