VPN kobler stadig fra? Gå gjennom dette i denne rekkefølgen

Før du installerer klienten på nytt, skriv ned tre ting: hvor lenge tunnelen var oppe, hva klienten sa da den falt, og om maskinen sov eller byttet nettverk i mellomtiden. Den notaten er det eneste beviset du har senere, og en nyinstallering sletter den vanligvis. En frakobling med gjentakende intervall er en timer eller en utløpt tilstand; en frakobling på et tilfeldig tidspunkt er et veilproblem. Rekkefølgen nedenfor hindrer deg i å endre tre ting samtidig og ikke lære noe.

Trinn én: noter intervallet og feilteksten

Begynn med klientens egen logg i stedet for leverandørens dashbord. På en Linux-klient dekker tjenesteloggen pluss tunnelens levende 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

Noter tidspunktene for den siste vellykkede håndtrykket og øyeblikket da trafikken stoppet, ikke bare øyeblikket da ikonet skiftet farge. En GUI-klient som sier frakoblet i ettertid, rapporterer kanskje en tilstand kjernen nådde sekunder tidligere.

Behold ordlyden i feilen. En tidsavbrudd, en avvist autentisering og en adapter- eller driverfeil peker på tre forskjellige lag, og det meste av bortkastet arbeid i dette problemet kommer av å behandle dem som én. Kopier linjen ordrett inn i notatet ditt.

Trinn to: endre én variabel, ikke profilen

Hold enheten og profilen fast og flytt maskinen til et annet aksessnett, for eksempel et telefonhotspot. Dette er den billigste testen som skiller klienten fra veien. Kjør den lenge nok til å dekke det opprinnelige feilintervallet; to stabile minutter beviser ingenting om en frakobling som skjer i trettiende minutt.

En bærbar PC med Ethernet-port gir en andre sammenligning som fjerner Wi-Fi helt fra bildet. Hvis tunnelen holder på begge alternativene, fortjener det opprinnelige aksessnettet oppmerksomhet: roaming mellom aksesspunkter, en hjemmeruter med utløpende oversettelsestabell, eller en oppstrømslenke som nullstiller langvarige strømmer.

Skriv ned hvilken variabel du endret. En sammenligning teller bare når alt annet er uendret, og det inkluderer serverens endepunkt og tiden på dagen.

Trinn tre: knytt intervallet til et lag

Lengden på en god økt er det mest informative enkelttallet du har. Les det mot denne listen før du rører timere:

• Frakobling etter søvn eller gjenopptakelse: overlevde tunnelens tilstand suspensjonen, men grensesnittet gjorde det ikke. Sjekk klientens gjenoppkoblingsatferd ved gjenopptakelse og om tjenesten starter tunnelen på nytt eller venter på trafikk.
• Frakobling bare når den er inaktiv: utløp noe i midten strømmen. Det er nettopp det tilfellet keepalives finnes for.
• Frakobling ved fast øktsalder: en hendelse for reautentisering eller nøkkelnying, ikke en veilfeil. En tydelig avvisning i loggen nøyaktig i det intervallet er tegnet.
• Frakobling under store overføringer eller store sider: mistenke MTU og fragmentering, ikke en inaktivitetstimer.

For inaktivitets tilfellet er innstillingene protokollspesifikke, og begge ender betyr noe. OpenVPNs keepalive 10 60 på serveren sender en ping hvert 10 sekund og starter forbindelsen på nytt etter 60 sekunder uten en; WireGuard-klienter bak NAT bruker PersistentKeepalive = 25 i peer-blokken. OpenVPN forhandler også datakanalen på nytt etter en timer, reneg-sec, som som standard er 3600 sekunder i 2.x.

Ikke kopier aggressive verdier fra en annen leverandørs veiledning. En kort tidsavbrudd på en tapende mobillenke produserer nettopp de frakoblingene den skulle forhindre, og verdier som skyves fra serveren overstyrer det du setter i klientprofilen.

Trinn fire: sammenlign ett støttet alternativ

Hvis operatøren publiserer både en UDP- og en TCP-profil, kjør samme enhet og nettverk mot den andre. Bruk den faktiske samsvarende filen i stedet for å redigere transporten i en kopiert profil. En stabil TCP-profil på en vei der UDP nullstilles, snevrer problemet inn til den veien; det beviser ikke at TCP er den bedre transporten overalt.

Samme logikk gjelder for endepunkter. Prøv en annen server og hold det opprinnelige resultatet ved siden av. Hvis bare én utgang nullstiller økter, er det bevis om det endepunktet, ikke grunn til å bygge hver adapter på nytt på den bærbare.

Etter enhver endring gjentar du den opprinnelige utløseren og bekrefter hvor trafikken faktisk går. Gjenvunnet internettilgang er ikke samme resultat som trafikk inne i tunnelen, og en klient som stille har falt tilbake til en direkte rute, ser sunn ut fra nettleseren.

Verifiser rettelsen, og behold rollback

En rettelse verifiseres ved å gjenskape den opprinnelige utløseren, ikke ved en vellykket tilkobling. La tunnelen være inaktiv forbi det gamle feilintervallet, suspender og gjenoppta én gang, og sjekk deretter håndtrykkets alder og utgangsadressen:

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

Behold forrige profil og forrige timerverdier til den nye atferden overlever en hel arbeidsdag. Hvis frakoblingene kommer tilbake, gjenopprett sikkerhetskopien, og bruk deretter endringene på nytt én om gangen slik at det andre forsøket starter fra en kjent tilstand.

Hvis loggen forblir ren og tunnelen fortsatt kobler fra med et gjentakende intervall, er neste stopp serversiden for den økten. Ta med klientens øktidentifikator og det nøyaktige frakoblingstidspunktet, fordi det paret er det som gjør en serverlogg søkbar. Protokollens lenkevalg er dokumentert i OpenVPN 2.6-håndboken når du trenger den nøyaktige betydningen av en verdi.