VPN-ul se deconectează constant? Urmați această ordine

Înainte de a reinstala clientul, notați trei lucruri: cât timp a rămas tunelul activ, ce a spus clientul când a căzut și dacă mașina a dormit sau a schimbat rețeaua între timp. Acea notă este singura dovadă pe care o veți avea mai târziu, iar reinstalarea de obicei o șterge. O cădere la un interval repetabil este un temporizator sau o expirare de stare; o cădere într-un moment aleatoriu este o problemă de traseu. Ordinea de mai jos vă împiedică să schimbați trei lucruri deodată și să nu învățați nimic.

Primul pas: notați intervalul și textul erorii

Începeți cu jurnalul clientului însuși, nu cu panoul furnizorului. Pe un client Linux, jurnalul serviciului plus starea live a tunelului acoperă cea mai mare parte:

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

Notați marcajele de timp ale ultimei strângeri de mână reușite și momentul în care traficul s-a oprit, nu doar momentul în care pictograma și-a schimbat culoarea. Un client GUI care spune deconectat după fapt s-ar putea să raporteze o stare la care nucleul a ajuns cu câteva secunde mai devreme.

Păstrați formularea erorii. Un timeout, o respingere a autentificării și o eroare de adaptor sau driver indică trei straturi diferite, iar cea mai mare parte a efortului irosit în această problemă vine din tratarea lor ca unul singur. Copiați linia cuvânt cu cuvânt în notă.

Al doilea pas: schimbați o variabilă, nu profilul

Țineți dispozitivul și profilul fixe și mutați mașina într-o altă rețea de acces, cum ar fi un hotspot de telefon. Acesta este cel mai ieftin test care separă clientul de traseu. Rulați-l suficient de mult pentru a acoperi intervalul de eșec inițial; două minute stabile nu dovedesc nimic despre o cădere care apare în minutul treizeci.

Un laptop cu port Ethernet oferă o a doua comparație care scoate complet Wi-Fi-ul din imagine. Dacă tunelul rezistă pe ambele alternative, rețeaua de acces inițială merită atenție: roaming între puncte de acces, un router de casă cu tabela de traducere expirată sau o legătură superioară care resetează fluxurile lungi.

Notați ce variabilă ați schimbat. O comparație contează doar când tot restul a rămas la fel, iar asta include punctul final al serverului și ora din zi.

Al treilea pas: asociați intervalul cu un strat

Durata unei sesiuni bune este singurul număr cel mai informativ pe care îl aveți. Citiți-l față de această listă înainte de a atinge temporizatoarele:

• Cădere după somn sau reluare: starea tunelului a supraviețuit suspendării, dar interfața nu. Verificați comportamentul de reconectare al clientului la reluare și dacă serviciul repornește tunelul sau așteaptă trafic.
• Cădere doar când este inactiv: ceva din mijloc a lăsat fluxul să expire. Exact pentru acest caz există keepalive.
• Cădere la o vârstă fixă a sesiunii: un eveniment de reautentificare sau de reînnoire a cheii, nu o defecțiune de traseu. O respingere explicită în jurnal exact la acel interval este semnul.
• Cădere în timpul transferurilor mari sau al paginilor mari: suspectați MTU și fragmentarea, nu un temporizator de inactivitate.

Pentru cazul inactiv, setările depind de protocol și ambele capete contează. keepalive 10 60 OpenVPN de pe server trimite un ping la fiecare 10 secunde și repornește legătura după 60 de secunde fără el; clienții WireGuard din spatele NAT folosesc PersistentKeepalive = 25 în blocul de partener. OpenVPN renegociază și canalul de date pe un temporizator, reneg-sec, care implicit este de 3600 de secunde în 2.x.

Nu copiați valori agresive din ghidul altui furnizor. Un timeout scurt pe o legătură mobilă cu pierderi produce exact deconectările pe care trebuia să le prevină, iar valorile trimise de server le înlocuiesc pe cele setate în profilul clientului.

Al patrulea pas: comparați o alternativă acceptată

Dacă operatorul publică atât un profil UDP, cât și unul TCP, rulați același dispozitiv și aceeași rețea împotriva celuilalt. Folosiți fișierul corespunzător real în loc să editați transportul într-un profil copiat. Un profil TCP stabil pe un traseu unde UDP este resetat restrânge problema la acel traseu; nu dovedește că TCP este transportul mai bun peste tot.

Aceeași logică se aplică punctelor finale. Încercați alt server și păstrați rezultatul inițial alături. Dacă doar o ieșire resetează sesiuni, aceasta este o dovadă despre acel punct final, nu un motiv pentru a reconstrui fiecare adaptor de pe laptop.

După orice schimbare, repetați declanșatorul inițial și confirmați unde merge de fapt traficul. Accesul la internet recâștigat nu este același rezultat ca traficul din interiorul tunelului, iar un client care a căzut în tăcere pe o rută directă pare sănătos din browser.

Verificați corectarea și păstrați revenirea

O corectare se verifică reproducând declanșatorul inițial, nu printr-o conexiune reușită. Lăsați tunelul inactiv dincolo de vechiul interval de eșec, suspendați și reluați o dată, apoi verificați vârsta strângerii de mână și adresa de ieșire:

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

Păstrați profilul anterior și valorile anterioare ale temporizatorului până când noul comportament supraviețuiește unei zile întregi de lucru. Dacă deconectările revin, restaurați copia de siguranță și apoi reaplicați modificările una câte una, astfel încât a doua încercare să pornească dintr-o stare cunoscută.

Dacă jurnalul rămâne curat și tunelul încă se deconectează la un interval repetabil, următoarea oprire este partea de server pentru acea sesiune. Luați cu dumneavoastră identificatorul de sesiune al clientului și momentul exact al deconectării, pentru că acea pereche face un jurnal de server căutabil. Opțiunile de legătură ale protocolului sunt documentate în manualul OpenVPN 2.6 când aveți nevoie de sensul exact al unei valori.