Proč nc -uz nedokáže prokázat, že server OpenVPN je připraven

Spuštění nc -uz proti serveru OpenVPN téměř nic neměří a příručka OpenBSD to říká ve svých upozorněních: UDP skenování v tomto režimu hlásí úspěch bez ohledu na to, zda něco poslouchá. Návratový kód odráží místní odeslání, nikoli vzdálený stav, takže supervizor, který mu věří, drží mrtvý server označený jako zdravý, dokud tabulka procesů vypadá uvěřitelně. Nahrazení začíná rozhodnutím, na kterou otázku má kontrola odpovědět, protože proces, naslouchající socket, autentizace a dostupnost aplikace jsou čtyři různá pozorování. Sonda, která pojmenuje jedno z nich, je užitečná; sonda, která naznačuje všechna čtyři, je přítěž.

Co UDP sonda může a co nemůže pozorovat

nc -uz odešle datagram a skončí a stav, který vrátí, popisuje místní odeslání. Zavřený port může odpovědět ICMP port unreachable, ale dokumentované chování tohoto režimu skenování to na selhání nepřevádí a filtrovaný port nevrátí žádnou odpověď. Ticho a úspěch tedy pro volajícího znamenají totéž.

To dělá ze sondy test místního zásobníku, nikoli serveru. Nezjistí, že je host dostupný, že je port obsazen, že proces OpenVPN běží nebo že by se klient mohl autentizovat. Test TCP spojení je silnější, protože handshake dává jednoznačnou odpověď, ale jen když nasazení skutečně poslouchá na TCP. Přepnutí sondy na TCP na stejném čísle testuje socket, který nemusí existovat, a proti serveru pouze s UDP selže zdravou službu.

Sladění sondy s nakonfigurovaným transportem přichází před důvěrou v kterýkoli z obou výsledků. Nasazení s UDP potřebuje jiný signál, ne jiný protokol.

Tři volající, tři různé otázky

Připravenost závisí na tom, kdo se ptá. Správce služeb, který restartuje spadlý proces, musí vědět, že instance nastartovala a obsadila svůj socket. Vyvažovač zátěže musí vědět, že klient, který přijde nyní, bude přijat. Monitorovací systém musí vědět, že cesta z reálné sítě stále nese relaci k povolenému prostředku.

To není stejná kontrola a jedna sonda nemůže poctivě pokrýt všechny tři. Nejprve vyberte volajícího, potom důkaz.

Sestavte sondu z aktuální instance

OpenVPN zapíše při dokončení inicializace instance startovní řádek a ten je užitečným důkazem o místním startu. Čtěte ho z aktuálního startu, ne z konce připisovaného souboru, protože úspěch z minulého týdne se čte přesně jako úspěch před minutou. Server může inicializaci dokončit i dřív, než se kdy připojil jakýkoli klient, takže řádek nic neříká o autentizaci.

Pro kontrolu startu spojte stav procesu s aktuálním důkazem z logu a socketem, který odpovídá nakonfigurovanému transportu. Kontrola má selhat, když proces běží, ale inicializaci nedokončil, což znamená, že dotaz do logu musí být omezen na tento start a tuto jednotku.

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

Tři výstupy, tři tvrzení: jednotka je aktivní, tento start vytvořil inicializační řádek a něco drží UDP port. Žádný z nich neříká, že se klient může připojit. Držte je na stavové stránce oddělené, aby se incident nesléval do jediného zeleného bodu.

Rozbijte to schválně a sledujte sondu

Sonda je důvěryhodná, teprve když jste ji viděli selhat. Zastavte server, spusťte sondu a potvrďte očekávaný výsledek. Pak ho znovu spusťte a potvrďte, že se sonda vzpamatuje bez jakékoli další změny.

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

Čtěte blok řádek po řádku. Příkaz netcat vypíše exit=0 , přitom nic není obsazeno, a to je celý problém na jednom řádku. První ss nic nevypíše, restart uspěje a druhý ss znovu ukáže socket. Pokud vaše sonda projde proti zastavenému serveru, měří místní zásobník a nic jiného.

Opačné selhání je také důležité. Sonda, která selže proti zdravému serveru, způsobuje restarty, které nebyly nikdy potřeba, a restartovací smyčka je sama o sobě výpadek. Otestujte oba směry, než sondu zapojíte do čehokoli, co na ni může reagovat.

Co má stavový řádek říkat

Zaznamenejte, kterou hranici každá kontrola pokrývá: proces, socket, autentizaci nebo aplikaci. Jedna kontrola zřídka pokrývá víc než jednu a stavová stránka, která je slisuje do “up”, skrývá rozdíl, na kterém během incidentu záleží. Pro síťovou cestu použijte skutečného klienta s vyhrazenou identitou, nechte ho dokončit handshake a jednu neškodnou povolenou operaci a pak ho odpojte. To procvičí řídicí kanál, zásady autentizace i socket v jednom kroku.

Držte tuto identitu oddělenou od skutečných uživatelů a dejte jí minimum oprávnění, která kontrola potřebuje. Sonda připravenosti se širokým přístupem je nová útočná plocha přidaná pro pohodlí. Rotujte její přihlašovací údaje jako u každého jiného účtu, protože sonda, která přestane autentizovat, vypadá přesně jako server, který přestal přijímat klienty.

Pojmenujte hranici v textu upozornění, aby první reagující věděl, zda se dívat na jednotku, socket, certifikát nebo trasu. Sonda, která nedokáže říct, co prokázala, bude přijata z nesprávného důvodu, a právě tak kontrola netcat vůbec přežila.