Monitorizați un VPN pe router fără să aveți încredere într-un singur bec de stare
Starea partenerului, ruta selectată și o sondă de aplicație permisă răspund la întrebări diferite. Alarmați pe granița care a eșuat, nu pe o pictogramă verde.
Pagina de stare spune conectat, becul este verde, iar biroul nu ajunge la serverul de fișiere. Unul dintre aceste fapte este despre tunel, celălalt despre calea prin el. Monitorizarea ambelor este diferența dintre o alertă pe care puteți acționa și una pe care învățați să o ignorați.
Cinci verificări, în ordine, de la partener spre exterior.
Verificarea 1: starea partenerului sau a asocierii
Fiecare protocol își expune propria stare. WireGuard afișează ultimul handshake și contoarele de transfer pentru fiecare partener prin wg show. OpenVPN scrie starea sesiunii în fișierul de stare sau în interfața de administrare, iar IPsec expune asocierile de securitate prin instrumente precum ipsec statusall. Capcana este să citiți marcajul temporal ca pe o sentință: un partener WireGuard inactiv fără nimic de trimis nu va face un handshake recent, iar aceasta nu este o cădere.
Comparați marcajul temporal cu traficul așteptat și setările keepalive înainte de a chema pe cineva.
Verificarea 2: ruta selectată
O interfață de tunel poate exista în timp ce nimic nu este rutat în ea. Verificați tabela de forwarding pentru destinația care vă interesează, nu pentru subrețeaua tunelului însuși. Dacă prefixul lipsește sau indică altundeva, starea partenerului este irelevantă.
Acea verificare prinde defecțiunea pe care un bec de stare nu o arată niciodată.
O a doua verificare utilă compară și adresa sursă. ip route get 10.20.5.10 returnează următorul salt, interfața și sursa preferată, iar o sursă greșită este suficientă pentru a rupe traficul de retur la capătul îndepărtat. Notați tripletul așteptat o dată, apoi alarmați când se schimbă orice element. Acea singură linie prinde modificările NAT, instabilitatea interfeței și erorile de rutare bazată pe politici.
Verificarea 3: o cale de aplicație permisă
Testați ceva reprezentativ pentru cerința reală. Un ping originat pe router pleacă de la adresa și politica routerului însuși, care pot diferi de traficul LAN forwardat, iar multe gazde limitează ICMP. Dacă cerința este un serviciu privat, testați acel serviciu pe portul lui real.
Păstrați volumul sondei modest. O buclă de monitorizare nu trebuie să devină traficul pe care îl măsoară.
Verificarea 4: ce s-a schimbat și când
Corelați modificările WAN, reînnoirile de chei, retragerile de rute și eșecurile aplicațiilor pe o singură cronologie. Distingeți o defecțiune a tunelului de o rută de rezervă care restabilește în tăcere accesul normal la internet, pentru că ambele produc rapoarte de utilizator identice și diagnostice opuse. Erorile de fus orar vor inversa ordinea, așa că normalizați înainte de comparare. Cronologia este ce transformă patru verificări într-o cauză.
Păstrați jurnalele pentru tranziții, nu pentru payload.
Verificarea 5: alarma trebuie să numească granița
O alarmă care spune VPN căzut trimite pe cineva în locul greșit jumătate din timp. Una care spune că handshake-ul partenerului este vechi de douăsprezece minute, ruta către 10.20.0.0/16 lipsește sau sonda către portul 445 eșuează indică o verificare anume.
Țineți contoare operaționale în loc să răsfoiți payload-uri. Contoarele răspund la întrebarea de monitorizare fără a colecta conținut de care nu aveți nevoie.
Și lăsați politica de comutare să decidă ce urmează. Monitorizarea trebuie să identifice care graniță a eșuat, nu să autorizeze o ocolire largă de fiecare dată când o sondă eșuează. Manualul OpenVPN 2.6 documentează fișierul de stare și interfața de administrare care fac prima verificare scriptabilă.