Zašto nc -uz ne može dokazati da je OpenVPN server spreman

Pokretanje nc -uz prema serveru OpenVPN gotovo ništa ne mjeri, a OpenBSD priručnik to kaže u svojim napomenama: UDP skeniranja u tom režimu prijavljuju uspjeh bez obzira na to sluša li išta. Izlazni status odražava lokalno slanje, a ne udaljeno stanje, pa nadzornik koji mu vjeruje drži mrtav server označen kao zdrav sve dok tablica procesa izgleda uvjerljivo. Zamjena počinje odlukom na koje pitanje provjera treba odgovoriti, jer su proces, slušalac, autentifikacija i dostupnost aplikacije četiri različita zapažanja. Provjera koja imenuje jedno od njih je korisna; provjera koja implicira sva četiri je teret.

Šta UDP provjera može, a šta ne može primijetiti

nc -uz šalje datagram i izlazi, a status koji vraća opisuje lokalno slanje. Zatvoren port može odgovoriti ICMP port unreachable, ali dokumentirano ponašanje ovog režima skeniranja to ne pretvara u neuspjeh, a filtriran port ne daje nikakav odgovor. Zato tišina i uspjeh za pozivaoca znače isto.

To provjeru čini testom lokalnog steka, a ne servera. Ona ne utvrđuje da je host dostupan, da je port vezan, da proces OpenVPN radi ili da bi se klijent mogao autentificirati. TCP test povezivanja je jači jer rukovanje daje konačan odgovor, ali samo kada implementacija zaista sluša na TCP-u. Prebacivanje provjere na TCP na istom broju testira slušaoca koji možda ne postoji, a prema serveru samo na UDP-u oborit će zdravu uslugu.

Usklađivanje provjere s konfiguriranim transportom dolazi prije povjerenja u bilo koji od dva rezultata. UDP implementacija treba drugačiji signal, a ne drugačiji protokol.

Tri pozivaoca, tri različita pitanja

Spremnost zavisi od toga ko pita. Upravitelj usluga koji ponovno pokreće srušeni proces mora znati da je instanca pokrenuta i vezala svoj slušalac. Balanser opterećenja mora znati da bi klijent koji sada dolazi bio prihvaćen. Sistem za nadzor mora znati da put iz stvarne mreže još nosi sesiju do dopuštenog resursa.

To nije ista provjera i jedna provjera ne može iskreno pokriti sve tri. Prvo izaberite pozivaoca, zatim dokaz.

Izgradite provjeru iz trenutne instance

OpenVPN zapisuje liniju pokretanja kada instanca završi inicijalizaciju, a ta linija je koristan dokaz o lokalnom pokretanju. Čitajte je iz trenutnog pokretanja, a ne s kraja dopisane datoteke, jer se uspjeh od prošle sedmice čita isto kao uspjeh od prije minute. Server također može završiti inicijalizaciju prije nego što se ikada povezao ijedan klijent, pa linija ne govori ništa o autentifikaciji.

Za provjeru pokretanja spojite stanje procesa s trenutnim dokazom iz dnevnika i slušaocem koji odgovara konfiguriranom transportu. Provjera treba pasti kada proces radi, ali nije završio inicijalizaciju, što znači da upit prema dnevniku mora biti ograničen na ovo pokretanje i ovu jedinicu.

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

Tri izlaza, tri tvrdnje: jedinica je aktivna, ovo pokretanje je proizvelo liniju inicijalizacije i nešto drži UDP port. Nijedan od njih ne kaže da se klijent može povezati. Držite ih odvojeno na stranici statusa kako se incident ne bi stisnuo u jednu zelenu točku.

Slomite to namjerno i promatrajte provjeru

Provjera je pouzdana tek nakon što ste je vidjeli da pada. Zaustavite server, pokrenite provjeru i potvrdite rezultat koji očekujete. Zatim ga ponovno pokrenite i potvrdite da se provjera oporavlja bez ikakve druge promjene.

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

Čitajte blok red po red. Naredba netcat ispisuje exit=0 dok ništa nije vezano, i to je cijeli problem u jednom redu. Prvi ss ne ispisuje ništa, ponovno pokretanje uspijeva, a drugi ss ponovno pokazuje slušaoca. Ako vaša provjera prolazi prema zaustavljenom serveru, ona mjeri lokalni stek i ništa drugo.

Suprotan neuspjeh je također važan. Provjera koja pada prema zdravom serveru uzrokuje ponovna pokretanja koja nikada nisu bila potrebna, a petlja ponovnog pokretanja je sama po sebi prekid. Testirajte oba smjera prije nego što provjeru povežete s bilo čim što može djelovati na nju.

Šta bi linija statusa trebala reći

Zabilježite koju granicu pokriva svaka provjera: proces, slušalac, autentifikaciju ili aplikaciju. Jedna provjera rijetko pokriva više od jedne, a stranica statusa koja ih sabija u “up” skriva razliku koja je važna tijekom incidenta. Za mrežni put upotrijebite stvarnog klijenta s namjenskim identitetom, pustite ga da završi rukovanje i jednu bezopasnu dopuštenu operaciju, zatim ga odspojite. To uvježbava kontrolni kanal, politiku autentifikacije i slušaoca u jednom koraku.

Držite taj identitet odvojeno od stvarnih korisnika i dajte mu minimalne dozvole koje provjera treba. Provjera spremnosti sa širokim pristupom je nova napadna površina dodana radi udobnosti. Mijenjajte njezine vjerodajnice kao i na svakom drugom računu, jer provjera koja prestane s autentifikacijom izgleda točno kao server koji je prestao prihvaćati klijente.

Imenujte granicu u tekstu upozorenja kako bi prvi koji reagira znao treba li gledati jedinicu, utičnicu, certifikat ili rutu. Provjera koja ne može reći što je dokazala bit će prihvaćena iz pogrešnog razloga, i tako je netcat provjera uopće preživjela.