Prečo nc -uz nedokáže preukázať, že server OpenVPN je pripravený

Spustenie nc -uz proti serveru OpenVPN takmer nič nemeria a príručka OpenBSD to hovorí vo svojich upozorneniach: UDP skenovania v tomto režime hlásia úspech bez ohľadu na to, či niečo počúva. Návratový kód odzrkadľuje miestne odoslanie, nie vzdialený stav, takže supervízor, ktorý mu verí, drží mŕtvy server označený ako zdravý, kým tabuľka procesov vyzerá vierohodne. Nahradenie sa začína rozhodnutím, na ktorú otázku má kontrola odpovedať, pretože proces, počúvajúci socket, autentifikácia a dostupnosť aplikácie sú štyri rôzne pozorovania. Sonda, ktorá pomenuje jedno z nich, je užitočná; sonda, ktorá naznačuje všetky štyri, je príťaž.

Čo UDP sonda môže a čo nemôže pozorovať

nc -uz odošle datagram a skončí a stav, ktorý vráti, opisuje miestne odoslanie. Zatvorený port môže odpovedať ICMP port unreachable, ale dokumentované správanie tohto režimu skenovania to na zlyhanie nepremení a filtrovaný port nevráti žiadnu odpoveď. Ticho a úspech teda pre volajúceho znamenajú to isté.

To robí zo sondy test miestneho zásobníka, nie servera. Nezistí, že je hostiteľ dostupný, že je port obsadený, že proces OpenVPN beží alebo že by sa klient mohol autentifikovať. Test TCP spojenia je silnejší, pretože handshake dáva jednoznačnú odpoveď, ale len keď nasadenie skutočne počúva na TCP. Prepnutie sondy na TCP na rovnakom čísle testuje socket, ktorý nemusí existovať, a proti serveru iba s UDP zlyhá zdravú službu.

Zosúladenie sondy s nakonfigurovaným transportom prichádza pred dôverou v ktorýkoľvek z oboch výsledkov. Nasadenie s UDP potrebuje iný signál, nie iný protokol.

Traja volajúci, tri rôzne otázky

Pripravenosť závisí od toho, kto sa pýta. Správca služieb, ktorý reštartuje spadnutý proces, musí vedieť, že inštancia naštartovala a obsadila svoj socket. Vyvažovač záťaže musí vedieť, že klient, ktorý príde teraz, bude prijatý. Monitorovací systém musí vedieť, že cesta z reálnej siete stále nesie reláciu k povolenému zdroju.

To nie je tá istá kontrola a jedna sonda nemôže poctivo pokryť všetky tri. Najprv vyberte volajúceho, potom dôkaz.

Zostavte sondu z aktuálnej inštancie

OpenVPN zapíše pri dokončení inicializácie inštancie štartovací riadok a ten je užitočným dôkazom o miestnom štarte. Čítajte ho z aktuálneho štartu, nie z konca pripisovaného súboru, pretože úspech z minulého týždňa sa číta presne ako úspech pred minútou. Server môže inicializáciu dokončiť aj skôr, než sa kedy pripojil akýkoľvek klient, takže riadok nič nehovorí o autentifikácii.

Pre kontrolu štartu spojte stav procesu s aktuálnym dôkazom z logu a socketom, ktorý zodpovedá nakonfigurovanému transportu. Kontrola má zlyhať, keď proces beží, ale inicializáciu nedokončil, čo znamená, že dotaz do logu musí byť obmedzený na tento štart a túto jednotku.

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

Tri výstupy, tri tvrdenia: jednotka je aktívna, tento štart vytvoril inicializačný riadok a niečo drží UDP port. Žiadny z nich nehovorí, že sa klient môže pripojiť. Držte ich na stavovej stránke oddelené, aby sa incident nezlial do jediného zeleného bodu.

Rozbite to naschvál a sledujte sondu

Sonda je dôveryhodná až vtedy, keď ste ju videli zlyhať. Zastavte server, spustite sondu a potvrďte očakávaný výsledok. Potom ho znova spustite a potvrďte, že sa sonda spamätá bez akéhokoľvek ďalšieho zásahu.

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

Čítajte blok riadok po riadku. Príkaz netcat vypíše exit=0 , pričom nič nie je obsadené, a to je celý problém na jednom riadku. Prvý ss nič nevypíše, reštart sa podarí a druhý ss znova ukáže socket. Ak vaša sonda prejde proti zastavenému serveru, meria miestny zásobník a nič iné.

Opačné zlyhanie je tiež dôležité. Sonda, ktorá zlyhá proti zdravému serveru, spôsobuje reštarty, ktoré nikdy neboli potrebné, a reštartovacia slučka je sama o sebe výpadok. Otestujte oba smery, kým sondu zapojíte do čohokoľvek, čo na ňu môže reagovať.

Čo má stavový riadok hovoriť

Zaznamenajte, ktorú hranicu každá kontrola pokrýva: proces, socket, autentifikáciu alebo aplikáciu. Jedna kontrola zriedka pokrýva viac ako jednu a stavová stránka, ktorá ich stláča do “up”, skrýva rozdiel, na ktorom počas incidentu záleží. Pre sieťovú cestu použite skutočného klienta s vyhradenou identitou, nechajte ho dokončiť handshake a jednu neškodnú povolenú operáciu a potom ho odpojte. To precvičí riadiaci kanál, zásady autentifikácie aj socket v jednom kroku.

Držte túto identitu oddelene od skutočných používateľov a dajte jej minimum oprávnení, ktoré kontrola potrebuje. Sonda pripravenosti so širokým prístupom je nová útočná plocha pridaná pre pohodlie. Rotujte jej prihlasovacie údaje ako pri každom inom účte, pretože sonda, ktorá prestane autentifikovať, vyzerá presne ako server, ktorý prestal prijímať klientov.

Pomenujte hranicu v texte upozornenia, aby prvý reagujúci vedel, či sa pozerať na jednotku, socket, certifikát alebo trasu. Sonda, ktorá nedokáže povedať, čo preukázala, bude prijatá z nesprávneho dôvodu, a práve tak kontrola netcat vôbec prežila.