De ce un tunel Azure OpenVPN cade aproximativ la fiecare șaizeci de secunde
Un tunel care cade la fiecare șaizeci de secunde și-a încheiat strângerea de mână, deci nimic nu îl blochează. Citiți mai întâi motivul deconectării, apoi comparați ambele temporizatoare keepalive.
Tunelul își încheie strângerea de mână, transportă trafic aproximativ un minut și apoi se reconectează. Această secvență elimină suspectul obișnuit, deoarece un firewall care ar bloca portul ar fi oprit strângerea de mână, nu sesiunea. Ce aveți este un dezacord privind vitalitatea: o parte a decis că cealaltă a amuțit și a demolat un tunel funcțional. Linia din jurnal spune care parte, și ea alege corectura.
Citiți acea linie înainte de a atinge orice temporizator.
Mitul: ceva de pe traseu blochează tunelul
Dacă un port ar fi blocat, conexiunea ar eșua de la început și ar rămâne eșuată. Un ciclu repetat înseamnă că mesajele de control circulă, sesiunile se stabilesc și ceva mai târziu în conversație expiră continuu. Blocarea produce tăcere, iar asta produce un ritm.
Ritmul este indiciul util. Temporizatoarele îl produc; pierderea de pachete rar.
Citiți motivul deconectării înaintea temporizatorului
OpenVPN își numește motivul, iar fiecare nume indică un subsistem diferit. Session invalidated: KEEPALIVE_TIMEOUT este un temporizator care expiră, așa că comparați valorile ping și ping-restart la ambele capete. AUTH_FAILED sunt acreditări sau starea certificatului, iar nicio modificare a temporizatorului nu va ajuta. O eroare TLS înseamnă că părțile nu au ajuns deloc în faza keepalive.
Notați ora conectării, ora deconectării și dacă intervalul este stabil până la secundă. Acea singură măsurătoare separă un program configurat de o coincidență.
Un interval stabil este un temporizator. Unul care derivează este mai probabil o problemă de traseu sau o sesiune deplasată.
Două temporizatoare keepalive care nu s-au înțeles niciodată
Profilurile exportate din portal mai poartă uneori linii precum keepalive sau ping-restart copiate dintr-un șablon de server comunitar. Gateway-ul rulează propria detectare a partenerului mort și impune propriile așteptări, iar cele două programe nu trebuie să coincidă. Când diferă, clientul repornește după un program cu care gateway-ul nu a fost niciodată de acord.
Cele două valori nu sunt același control. ping este cât de des trimite clientul un ecou, iar ping-restart este cât așteaptă fără să audă nimic înainte de a demola tunelul. Un profil cu ping-restart scurt și un gateway care răspunde încet vor reporni la fiecare perioadă liniștită, ceea ce este exact forma unui ciclu de un minut.
Cea mai mică modificare pe partea clientului este să neutralizați temporizatoarele la nivelul superior al profilului, în afara fiecărui bloc inline:
keepalive 0 0Salvați, reîncărcați profilul, reconectați-vă. O sesiune deja aflată în memorie păstrează valorile vechi, motiv pentru care editarea pare uneori că nu a făcut nimic.
Numele certificatului se poate muta sub picioarele voastre
Autentificarea prin certificat Azure depinde de faptul că clientul se încrede în numele pe care gateway-ul îl prezintă astăzi. O linie verify-x509-name într-o descărcare mai veche poate fixa un nume pe care o reconstrucție a gateway-ului sau o reînnoire a certificatului l-a schimbat de atunci, iar nepotrivirea se manifestă ca o buclă de reconectare și nu ca o eroare clară. Ștergerea liniei restabilește conectivitatea, ceea ce o face un diagnostic bun și o corectură permanentă proastă, deoarece elimină și verificarea. Odată ce tunelul rezistă, restabiliți linia cu numele pe care gateway-ul îl prezintă de fapt.
Testați o a doua generație de client pe aceeași mașină înainte de a edita gateway-ul. Dacă un client intră în buclă și celălalt rezistă, profilul nu este problema.
Ce trebuie schimbat și în ce ordine
Verificați apoi o sesiune deplasată. Două dispozitive care partajează un certificat se pot elimina reciproc, iar rezultatul pare periodic pentru că ambele părți continuă să se reconecteze. Comparați înregistrările de sesiune punct-la-locație pentru aceeași identitate care apare iar și iar.
Apoi testați traseul inactiv rulând trafic continuu timp de câteva minute. Dacă căderile se opresc în timp ce traficul curge, temporizatorul important aparține unui dispozitiv NAT sau unui echilibrator de sarcină de pe traseu, nu OpenVPN.
Setările gateway-ului ar trebui schimbate doar după aceste patru teste.