De ce nc -uz nu poate dovedi că un server OpenVPN este pregătit

Rularea nc -uz împotriva unui server OpenVPN aproape nu măsoară nimic, iar manualul OpenBSD spune asta în rezervele sale: scanările UDP în acel mod raportează succes indiferent dacă ceva ascultă sau nu. Starea de ieșire reflectă trimiterea locală, nu starea de la distanță, așa că un supraveghetor care se bazează pe ea ține un server mort marcat ca sănătos atâta timp cât tabelul de procese pare plauzibil. Înlocuirea începe cu decizia la ce întrebare trebuie să răspundă verificarea, pentru că proces, ascultător, autentificare și accesibilitatea aplicației sunt patru observații diferite. O sondă care numește una dintre ele este utilă; o sondă care le implică pe toate patru este o povară.

Ce poate și ce nu poate observa o sondă UDP

nc -uz trimite un datagram și iese, iar starea returnată descrie trimiterea locală. Un port închis poate răspunde cu ICMP port unreachable, dar comportamentul documentat al acestui mod de scanare nu transformă asta într-un eșec, iar un port filtrat nu produce niciun răspuns. Deci tăcerea și succesul înseamnă același lucru pentru apelant.

Asta face din sondă un test al stivei locale, nu al serverului. Nu stabilește că gazda este accesibilă, că portul este legat, că procesul OpenVPN rulează sau că un client s-ar putea autentifica. Un test de conexiune TCP este mai puternic pentru că strângerea de mână dă un răspuns clar, dar numai când implementarea ascultă într-adevăr pe TCP. Trecerea sondei pe TCP la același număr testează un ascultător care poate să nu existe, iar împotriva unui server doar cu UDP va face să eșueze un serviciu sănătos.

Potrivirea sondei cu transportul configurat vine înainte de a avea încredere în oricare dintre cele două rezultate. O implementare UDP are nevoie de un alt semnal, nu de un alt protocol.

Trei apelanți, trei întrebări diferite

Disponibilitatea depinde de cine întreabă. Managerul de servicii care repornește un proces căzut trebuie să știe că instanța a pornit și și-a legat ascultătorul. Echilibratorul de încărcare trebuie să știe că un client care sosește acum ar fi acceptat. Sistemul de monitorizare trebuie să știe că drumul dintr-o rețea reală mai duce o sesiune către o resursă permisă.

Acestea nu sunt aceeași verificare, iar o singură sondă nu poate acoperi cinstit toate trei. Alegeți mai întâi apelantul, apoi dovada.

Construiți sonda pornind de la instanța curentă

OpenVPN scrie o linie de pornire când o instanță termină inițializarea, iar acea linie este o dovadă utilă despre pornirea locală. Citiți-o din pornirea curentă, nu din coada unui fișier la care se adaugă, pentru că un succes de săptămâna trecută se citește exact ca un succes de acum un minut. Un server poate termina inițializarea și înainte ca vreun client să se fi conectat vreodată, așa că linia nu spune nimic despre autentificare.

Pentru o verificare de pornire, îmbinați starea procesului cu dovada actuală din jurnal și cu un ascultător care corespunde transportului configurat. Verificarea trebuie să eșueze când procesul rulează dar nu a terminat inițializarea, ceea ce înseamnă că interogarea jurnalului trebuie limitată la această pornire și la această unitate.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Trei ieșiri, trei afirmații: unitatea este activă, această pornire a produs linia de inițializare și ceva ține portul UDP. Niciuna nu spune că un client se poate conecta. Țineți-le separate pe pagina de stare, ca un incident să nu se prăbușească într-un singur punct verde.

Stricați-o intenționat și urmăriți sonda

O sondă este de încredere abia după ce ați văzut-o eșuând. Opriți serverul, rulați sonda și confirmați rezultatul așteptat. Apoi porniți-l din nou și confirmați că sonda își revine fără nicio altă modificare.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Citiți blocul linie cu linie. Comanda netcat afișează exit=0 în timp ce nimic nu este legat, și aceasta este toată problema într-o singură linie. Prima ss nu afișează nimic, repornirea reușește, iar a doua ss arată din nou ascultătorul. Dacă sonda dumneavoastră trece împotriva serverului oprit, ea măsoară stiva locală și nimic altceva.

Și eșecul opus contează. O sondă care eșuează împotriva unui server sănătos provoacă reporniri care nu erau niciodată necesare, iar o buclă de reporniri este ea însăși o întrerupere. Testați ambele direcții înainte de a conecta sonda la ceva ce poate acționa pe baza ei.

Ce ar trebui să spună linia de stare

Notați ce frontieră acoperă fiecare verificare: proces, ascultător, autentificare sau aplicație. O verificare acoperă rar mai mult de una, iar o pagină de stare care le comprimă în “up” ascunde diferența care contează în timpul unui incident. Pentru calea de rețea, folosiți un client real cu o identitate dedicată, lăsați-l să termine strângerea de mână și o operațiune permisă inofensivă, apoi deconectați-l. Asta exersează canalul de control, politica de autentificare și ascultătorul într-un singur pas.

Țineți acea identitate separată de utilizatorii reali și dați-i permisiunile minime de care are nevoie verificarea. O sondă de disponibilitate cu acces larg este o nouă suprafață de atac adăugată pentru comoditate. Rotiți-i acreditările ca la orice alt cont, pentru că o sondă care nu mai autentifică arată exact ca un server care a încetat să accepte clienți.

Numiți frontiera în textul alertei, ca primul intervenient să știe dacă să se uite la unitate, la soclu, la certificat sau la rută. O sondă care nu poate spune ce a dovedit va fi crezută din motivul greșit, și exact așa a supraviețuit verificarea cu netcat de la început.