Keepalive și reconectările se configurează în aceeași suflare, dar rezolvă probleme diferite, de aceea reglarea uneia rareori o repară pe cealaltă. Un keepalive trimite trafic mic pentru a menține o intrare de stare în viață sau pentru a observa că un partener a încetat să răspundă. O reconectare dărâmă ce este stricat și reconstruiește relația, inclusiv chei, adrese și rute. Alege mecanismul care se potrivește defecțiunii, nu pe cel al cărui buton îl știi deja. Două întrebări decid: calea este moartă sau ceva dintre parteneri o uită?

Când maparea este problema

Un tunel care moare doar după minute de liniște pierde de obicei o intrare de traducere, nu un partener. Opțiunea PersistentKeepalive din WireGuard există pentru starea NAT și firewall, iar notele proiectului o descriu exact așa, nu ca pe o verificare de sănătate. Un interval de câteva zeci de secunde ține intrarea caldă, în timp ce un pachet în fiecare secundă este o decizie despre baterie, nu despre fiabilitate. OpenVPN ajunge în același loc prin ping și ping-restart , care observă mai întâi liniștea și apoi acționează.

Nici aceste setări nu sunt interschimbabile între protocoale. Politica de partener mort din IKEv2, temporizatorul ping din OpenVPN și keepalive din WireGuard răspund aceleiași întrebări cu trei sintaxe și trei valori implicite diferite, așa că a copia un număr între ele este o presupunere îmbrăcată în reglaj.

Când relația a dispărut

Dacă partenerul își schimbă adresa, acreditarea expiră sau capătul îndepărtat repornește, pachetele mici nu sunt reparația. Reconectarea trebuie să reconstruiască starea : obține o adresă, reinstalează rutele, renegociază cheile și, în unele implementări, reautentifică un utilizator.

Clienții care se reconectează nesupravegheați dețin un certificat sau un secret stocat. Un client care ar întreba un om eșuează exact când nu este nimeni prezent, iar acesta este scenariul în care reconectarea conta. Este o decizie de proiectare luată cu luni înainte, nu o setare pe care o poți schimba în timpul unei întreruperi.

Ce nu dovedește niciunul

Un tunel poate fi reconectat, cu chei și rute, în timp ce serviciul din spate este căzut, iar un keepalive poate ține o mapare deschisă pentru o sesiune al cărei server a dispărut de ore. Ambele mecanisme pot raporta succes în timp ce ceea ce te interesează cu adevărat nu este disponibil.

De aceea testul se termină cu o cerere reală. Trimite ceva prin tunel după intervalul care te interesează, apoi declanșează separat defecțiunea pentru care ai proiectat: o perioadă de inactivitate pentru cazul mapării, o repornire sau o schimbare de adresă pentru cazul reconectării.

Blocarea traficului direct este o decizie separată

O buclă de reconectare poate fi perfect sănătoasă în timp ce o aplicație folosește în liniște ruta obișnuită, iar asta este o scurgere, nu o defecțiune. Dacă cerința este ca nimic să nu iasă în afara tunelului, spune-o explicit în configurația clientului și dovedește-o coborând tunelul și urmărind ce se mai conectează. Niciunul dintre mecanisme nu implică acest comportament, iar nicio disciplină a reîncercărilor nu îl stabilește.

Notează ce mecanism a rulat și dacă o cerere nouă a reușit după aceea. Aceste două fapte sunt ce are nevoie următorul inginer, iar niciunul nu se vede într-o pictogramă de stare. O linie de jurnal care spune că clientul s-a reconectat nu este același lucru cu o cerere care a funcționat.

Scrie politica, nu doar numărul

Pune perechea într-o singură propoziție: intervalul de inactivitate, pragul de vitalitate, ce declanșează o reconstrucție , și ce face clientul în timp ce reîncearcă. Fără acea propoziție, fiecare incident viitor redeschide aceeași dezbatere dacă keepalive este prea scurt sau reconectarea prea lentă.

Notele WireGuard despre limitări sunt o reamintire utilă că keepalive este o soluție ocolitoare pentru middlebox-uri și nu un proiect general de vitalitate. Citește acea limitare înainte de a crește frecvența ca răspuns la o problemă pe care nu o poate rezolva.

Articole similare