VPN bly ontkoppel? Werk dit in hierdie volgorde deur

Voordat jy die kliënt herinstalleer, skryf drie dinge neer: hoe lank die tonnel op was, wat die kliënt gesê het toe dit onderbreek het, en of die masjien intussen geslaap of van netwerk verander het. Daardie nota is die enigste bewyse wat jy later sal hê, en herinstallasie wis dit gewoonlik uit. ’n Onderbreking teen ’n herhaalbare interval is ’n tydhouer of ’n toestandverval; ’n onderbreking op ’n toevallige oomblik is ’n padprobleem. Die volgorde hieronder keer dat jy drie dinge tegelyk verander en niks leer nie.

Stap een: teken die interval en die foutteks aan

Begin met die kliënt se eie logboek eerder as die verskaffer se paneelbord. Op ’n Linux-kliënt dek die dienslogboek plus die lewendige tonneltoestand die meeste daarvan:

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

Teken die tydstempels van die laaste suksesvolle handdruk en die oomblik toe verkeer gestop het aan, nie net die oomblik toe die ikoon van kleur verander het nie. ’n GUI-kliënt wat agterna sê dit is ontkoppel, rapporteer dalk ’n toestand wat die kern sekondes vroeër bereik het.

Hou die bewoording van die fout. ’n Tydverstreke, ’n verwerping van verifikasie en ’n adapter- of drywerfout wys op drie verskillende lae, en die meeste vermoorde moeite in hierdie probleem kom daaruit dat hulle as een behandel word. Kopieer die reël woordeliks in jou nota.

Stap twee: verander een veranderlike, nie die profiel nie

Hou die toestel en die profiel vas en skuif die masjien na ’n ander toegangsnetwerk, soos ’n selfoon se hotspot. Dit is die goedkoopste toets wat die kliënt van die pad skei. Hardloop dit lank genoeg om die oorspronklike foutinterval te dek; twee stabiele minute bewys niks oor ’n onderbreking wat by minuut dertig gebeur nie.

’n Skootrekenaar met ’n Ethernet-poort gee jou ’n tweede vergelyking wat Wi-Fi heeltemal uit die prentjie verwyder. As die tonnel op albei alternatiewe hou, verdien die oorspronklike toegangsnetwerk die aandag: toegangspunt-roaming, ’n verbruikersrouter wie se vertaaltabel verval, of ’n opstroomskakel wat langdurige strome terugstel.

Skryf neer watter veranderlike jy verander het. ’n Vergelyking tel net wanneer alles anders dieselfde gebly het, en dit sluit die bediener-eindpunt en die tyd van die dag in.

Stap drie: karteer die interval na ’n laag

Die lengte van ’n goeie sessie is die mees informatiewe enkele getal wat jy het. Lees dit teen hierdie lys voordat jy aan tydhouers raak:

• Onderbreking ná slaap of hervatting: het die tonneltoestand die opskorting oorleef, maar die koppelvlak het nie. Kyk na die kliënt se gedrag met herverbinding by hervatting en of die diens die tonnel herbegin of op verkeer wag.
• Onderbreking slegs wanneer dit ledig is: het iets in die middel die stroom laat verval. Dit is die geval waarvoor keepalives bestaan.
• Onderbreking by ’n vaste sessie-ouderdom: ’n herverifikasie- of hersleutelgebeurtenis, nie ’n padfout nie. ’n Duidelike verwerping in die logboek op daardie presiese interval is die aanduiding.
• Onderbreking tydens groot oordragte of groot bladsye: vermoed MTU en fragmentasie, nie ’n ledige tydhouer nie.

Vir die ledige geval is die instellings protokolspesifiek en albei kante maak saak. OpenVPN se keepalive 10 60 op die bediener stuur elke 10 sekondes ’n ping en herbegin die skakel ná 60 sekondes sonder een; WireGuard-kliënte agter NAT gebruik PersistentKeepalive = 25 in die peer-blok. OpenVPN heronderhandel ook die datakanaal op ’n tydhouer, reneg-sec, wat in 2.x by verstek 3600 sekondes is.

Moenie aggressiewe waardes uit ’n ander verskaffer se gids kopieer nie. ’n Kort tydverstreke op ’n verliesryke mobiele skakel veroorsaak die ontkoppelings wat dit veronderstel was om te voorkom, en waardes wat die bediener stuur, oorheers wat jy in die kliëntprofiel stel.

Stap vier: vergelyk een ondersteunde alternatief

As die operateur beide ’n UDP- en ’n TCP-profiel publiseer, hardloop dieselfde toestel en netwerk teen die ander een. Gebruik die werklike ooreenstemmende lêer eerder as om die transport in ’n gekopieerde profiel te wysig. ’n Stabiele TCP-profiel op ’n pad waar UDP terugstel, vernou die probleem tot daardie pad; dit bewys nie dat TCP oral die beter transport is nie.

Dieselfde logika geld vir eindpunte. Probeer een ander bediener en hou die oorspronklike resultaat langsaan. As slegs een uitgang sessies terugstel, is dit bewyse oor daardie eindpunt, nie ’n rede om elke adapter op die skootrekenaar te herbou nie.

Herhaal ná enige skakel die oorspronklike sneller en bevestig waar verkeer werklik heen gaan. Herwonne internettoegang is nie dieselfde resultaat as verkeer binne die tonnel nie, en ’n kliënt wat stilweg na ’n direkte roete teruggeval het, lyk gesond vanuit die blaaier.

Verifieer die regstelling, en hou die terugrol

’n Regstelling word geverifieer deur die oorspronklike sneller te reproduseer, nie deur ’n suksesvolle verbinding nie. Laat die tonnel ledig verby die ou foutinterval, skort een keer op en hervat, en kyk daarna na die handdruk-ouderdom en die uitgangsadres:

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

Hou die vorige profiel en die vorige tydhouerwaardes totdat die nuwe gedrag ’n volle werksdag oorleef. As die onderbrekings terugkeer, herstel die rugsteun, en pas dan een verandering op ’n slag weer toe sodat die tweede poging van ’n bekende toestand begin.

As die logboek skoon bly en die tonnel steeds teen ’n herhaalbare interval onderbreek, is die volgende stop die bedienerkant vir daardie sessie. Neem die kliënt se sessie-identifiseerder en die presiese onderbrekingstyd saam, want daardie paar maak ’n bedienerlogboek deursoekbaar. Die protokol se skakelopsies word in die OpenVPN 2.6-handleiding gedokumenteer wanneer jy die presiese semantiek van ’n waarde nodig het.