VPN bryt stadig? Gå gjennom dette i denne rekkjefølgja

Før du installerer klienten på nytt, skriv ned tre ting: kor lenge tunnelen var oppe, kva klienten sa då han fall, og om maskinen sov eller bytte nettverk i mellomtida. Den notata er det einaste beviset du har seinare, og ein nyinstallasjon slettar henne vanlegvis. Eit brot med gjentakande intervall er ein timer eller ein utlopen tilstand; eit brot på eit tilfeldig tidspunkt er eit vegproblem. Rekkjefølgja nedanfor hindrar deg i å endre tre ting samstundes og ikkje lære noko.

Steg éin: noter intervallet og feilteksten

Byrja med klienten sin eigen logg i staden for dashbordet til leverandøren. På ein Linux-klient dekkjer tenesteloggen pluss den levande tilstanden til tunnelen 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 tidspunkta for den siste vellukka handtrykket og augneblinken då trafikken stoppa, ikkje berre augneblinken då ikonet skifta farge. Ein GUI-klient som seier fråkopla i ettertid, rapporterer kanskje ein tilstand kjernen nådde sekund tidlegare.

Hald på ordlyden i feilen. Eit tidsavbrot, ei avvising av autentisering og ein adapter- eller drivarfeil peikar på tre ulike lag, og det meste av bortkasta arbeid i dette problemet kjem av å handsame dei som éin. Kopier linja ordrett inn i notata di.

Steg to: endre éin variabel, ikkje profilen

Hald eininga og profilen fast og flytt maskinen til eit anna aksessnett, til dømes eit telefonhotspot. Dette er den billegaste testen som skil klienten frå vegen. Køyr han lenge nok til å dekkje det opphavlege feilintervallet; to stabile minutt beviser ingenting om eit brot som skjer i trettiande minutt.

Ein berbar PC med Ethernet-port gjev ei andre samanlikning som tek Wi-Fi heilt ut av biletet. Viss tunnelen held på begge alternativa, fortener det opphavlege aksessnettet merksemd: roaming mellom aksesspunkt, ein heimeruter med utløpande omsetjingstabell, eller ei oppstraumslenkje som nullstiller langvarige straumar.

Skriv ned kva variabel du endra. Ei samanlikning tel berre når alt anna er uendra, og det omfattar endepunktet til serveren og tida på dagen.

Steg tre: knytt intervallet til eit lag

Lengda på ei god økt er det mest informative enkeltalet du har. Les det mot denne lista før du rører timar:

• Brot etter søvn eller attopptaking: overlevde tilstanden til tunnelen suspensjonen, men grensesnittet gjorde det ikkje. Sjekk attoppkoplingsåtferda til klienten ved attopptaking og om tenesta startar tunnelen på nytt eller ventar på trafikk.
• Brot berre når han er inaktiv: gjekk noko i midten ut og avslutta straumen. Det er nettopp det tilfellet keepalives finst for.
• Brot ved fast øktsalder: ei hending for reautentisering eller nøkkelnying, ikkje ein vegfeil. Ei tydeleg avvising i loggen nøyaktig i det intervallet er teiknet.
• Brot under store overføringar eller store sider: mistenk MTU og fragmentering, ikkje ein inaktivitetstimer.

For inaktivitets tilfellet er innstillingane protokollspesifikke, og begge endar tel. OpenVPN sin keepalive 10 60 på serveren sender ein ping kvart 10 sekund og startar sambandet på nytt etter 60 sekund utan ein; WireGuard-klientar bak NAT brukar PersistentKeepalive = 25 i peer-blokka. OpenVPN forhandlar òg datakanalen på nytt etter ein timer, reneg-sec, som som standard er 3600 sekund i 2.x.

Ikkje kopier aggressive verdiar frå rettleiinga til ein annan leverandør. Eit kort tidsavbrot på ei tapande mobillenkje lagar nettopp dei brotta det skulle hindre, og verdiar som blir skyvne frå serveren overstyrer det du set i klientprofilen.

Steg fire: samanlikn eit støtta alternativ

Viss operatøren publiserer både ein UDP- og ein TCP-profil, køyr same eining og nettverk mot den andre. Bruk den faktiske samsvarande fila i staden for å redigere transporten i ein kopiert profil. Ein stabil TCP-profil på ein veg der UDP blir nullstilt, snevrar problemet inn til den vegen; det beviser ikkje at TCP er den betre transporten overalt.

Same logikk gjeld for endepunkt. Prøv ein annan server og hald det opphavlege resultatet ved sida av. Viss berre éin utgang nullstiller økter, er det bevis om det endepunktet, ikkje grunn til å byggje kvar adapter på nytt på den berbare.

Etter kvar endring gjenntar du den opphavlege utløysaren og stadfester kvar trafikken faktisk går. Gjenvunnen internettilgang er ikkje same resultat som trafikk inne i tunnelen, og ein klient som stille har falle tilbake til ein direkte rute, ser sunn ut frå nettlesaren.

Stadfest rettinga, og hald på rollback

Ei retting blir stadfesta ved å gjenskape den opphavlege utløysaren, ikkje ved ei vellukka tilkopling. Lat tunnelen vere inaktiv forbi det gamle feilintervallet, suspender og ta opp att éin gong, og sjekk deretter alderen på handtrykket og utgangsadressa:

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

Hald på den førre profilen og dei førre timerverdiane til den nye åtferda overlever ein heil arbeidsdag. Viss brotta kjem tilbake, gjenopprett sikkerheitskopien, og bruk deretter endringane på nytt éin om gongen slik at det andre forsøket startar frå ein kjend tilstand.

Viss loggen blir verande rein og tunnelen framleis bryt med eit gjentakande intervall, er neste stopp serversida for den økta. Ta med øktidentifikatoren til klienten og det nøyaktige brottidspunktet, fordi det paret er det som gjer ein serverlogg søkbar. Lenkjevala til protokollen er dokumenterte i OpenVPN 2.6-handboka når du treng den nøyaktige tydinga av ein verdi.