VPN bliver ved med at afbryde? Gå frem i denne rækkefølge

Før du geninstallerer klienten, skriv tre ting ned: hvor længe tunnelen var oppe, hvad klienten sagde, da den faldt, og om maskinen sov eller skiftede netværk undervejs. Den note er det eneste bevis, du har senere, og en geninstallation sletter den normalt. Et afbrud med et gentageligt interval er en timer eller en udløbet tilstand; et afbrud på et tilfældigt tidspunkt er et problem med vejen. Rækkefølgen nedenfor forhindrer dig i at ændre tre ting på én gang og ikke lære noget.

Trin et: notér intervallet og fejlteksten

Begynd med klientens egen log i stedet for udbyderens dashboard. På en Linux-klient dækker tjenesteloggen plus tunnelens aktuelle tilstand det meste:

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

Notér tidspunkterne for det sidste vellykkede håndtryk og det øjeblik, trafikken stoppede, ikke bare det øjeblik, ikonet skiftede farve. En GUI-klient, der siger afbrudt bagefter, rapporterer måske en tilstand, som kernen nåede sekunder tidligere.

Behold fejlens ordlyd. En timeout, en afvisning af godkendelse og en adapter- eller driverfejl peger på tre forskellige lag, og det meste spildte arbejde i dette problem kommer af at behandle dem som ét. Kopiér linjen ordret ind i din note.

Trin to: ændr én variabel, ikke profilen

Hold enheden og profilen fast og flyt maskinen til et andet adgangsnetværk, for eksempel et telefonhotspot. Dette er den billigste test, der skiller klienten fra vejen. Kør den længe nok til at dække det oprindelige fejlinterval; to stabile minutter beviser intet om et afbrud, der sker i minut tredive.

En bærbar med Ethernet-port giver dig en anden sammenligning, der fjerner Wi-Fi helt fra billedet. Hvis tunnelen holder på begge alternativer, fortjener det oprindelige adgangsnetværk opmærksomhed: roaming mellem accesspunkter, en forbrugerrouter hvis oversættelsestabel udløber, eller et uplink, der nulstiller langvarige flows.

Skriv ned, hvilken variabel du ændrede. En sammenligning tæller kun, når alt andet er uændret, og det omfatter serverens endpoint og tidspunktet på dagen.

Trin tre: knyt intervallet til et lag

Længden af en god session er det mest informative enkeltnummer, du har. Læs det op mod denne liste, før du rører ved timere:

• Afbrud efter søvn eller genoptagelse: overlevede tunnelens tilstand suspenderingen, men grænsefladen gjorde ikke. Undersøg klientens adfærd ved genopkobling efter genoptagelse, og om tjenesten genstarter tunnelen eller venter på trafik.
• Afbrud kun når den er inaktiv: udløb noget i midten flowet. Det er netop det tilfælde, keepalives findes til.
• Afbrud ved en fast sessionsalder: en genautentificerings- eller nøglefornyelseshændelse, ikke en vejfejl. En eksplicit afvisning i loggen præcis i det interval er tegnet.
• Afbrud under store overførsler eller store sider: mistænke MTU og fragmentering, ikke en inaktivitetstimer.

For inaktivitetstilfældet er indstillingerne protokolspecifikke, og begge ender betyder noget. OpenVPNs keepalive 10 60 på serveren sender en ping hvert 10 sekund og genstarter forbindelsen efter 60 sekunder uden en; WireGuard-klienter bag NAT bruger PersistentKeepalive = 25 i peer-blokken. OpenVPN forhandler også datakanalen igen på en timer, reneg-sec, som som standard er 3600 sekunder i 2.x.

Kopiér ikke aggressive værdier fra en anden udbyders guide. En kort timeout på et tabsgivende mobillink frembringer netop de afbrydelser, den skulle forhindre, og værdier sendt fra serveren tilsidesætter det, du sætter i klientprofilen.

Trin fire: sammenlign ét understøttet alternativ

Hvis udbyderen offentliggør både en UDP- og en TCP-profil, kør samme enhed og netværk mod den anden. Brug den faktiske matchende fil i stedet for at redigere transporten i en kopieret profil. En stabil TCP-profil på en vej, hvor UDP nulstilles, indsnævrer problemet til den vej; det beviser ikke, at TCP er den bedre transport overalt.

Samme logik gælder for endpoints. Prøv en anden server, og hold det oprindelige resultat ved siden af. Hvis kun én udgang nulstiller sessioner, er det bevis om det endpoint, ikke en grund til at genopbygge hver adapter på den bærbare.

Efter enhver ændring gentages den oprindelige udløser, og du bekræfter, hvor trafikken faktisk går hen. Genvundet internetadgang er ikke det samme resultat som trafik inde i tunnelen, og en klient, der stille er faldet tilbage til en direkte rute, ser sund ud fra browseren.

Bekræft rettelsen, og behold rollback

En rettelse bekræftes ved at gengive den oprindelige udløser, ikke ved en vellykket forbindelse. Lad tunnelen være inaktiv forbi det gamle fejlinterval, suspendér og genoptag én gang, og kontrollér derefter håndtrykkets alder og udgangsadressen:

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

Behold den tidligere profil og de tidligere timerværdier, indtil den nye adfærd overlever en hel arbejdsdag. Hvis afbrydelserne vender tilbage, gendan sikkerhedskopien, og anvend derefter ændringerne igen én ad gangen, så det andet forsøg starter fra en kendt tilstand.

Hvis loggen forbliver ren, og tunnelen stadig afbrydes med et gentageligt interval, er næste stop serversiden for den session. Tag klientens sessions-id og det præcise afbrydelsestidspunkt med, fordi det par er det, der gør en serverlog søgbar. Protokollens linkindstillinger er dokumenteret i OpenVPN 2.6-manualen når du har brug for den præcise betydning af en værdi.