Miks nc -uz ei suuda tõestada, et OpenVPN server on valmis

Käivitamine nc -uz vastu OpenVPN serverit ei mõõda peaaegu midagi, ja OpenBSD käsiraamat ütleb seda oma märkustes: UDP-skaneerimised selles režiimis teatavad õnnestumisest olenemata sellest, kas miski kuulab. Väljumisstaatus peegeldab kohalikku saatmist, mitte kaugemat olekut, seega haldur, kes seda usaldab, hoiab surnud serverit terveks märgituna seni, kuni protsessitabel tundub usutav. Asendamine algab otsusest, millele küsimusele peaks kontroll vastama, sest protsess, kuulaja, autentimine ja rakenduse kättesaadavus on neli erinevat vaatlust. Kontroll, mis nimetab ühte neist, on kasulik; kontroll, mis vihjab kõigile neljale, on koorem.

Mida UDP-kontroll suudab ja ei suuda jälgida

nc -uz saadab datagrammi ja väljub ning tagastatav staatus kirjeldab kohalikku saatmist. Suletud port võib vastata ICMP port unreachable, kuid selle skaneerimisrežiimi dokumenteeritud käitumine ei muuda seda ebaõnnestumiseks ja filtreeritud port ei anna üldse vastust. Nii tähendavad vaikus ja õnnestumine kutsuja jaoks sama.

See muudab kontrolli kohaliku virna, mitte serveri testiks. See ei tuvasta, et host on kättesaadav, et port on seotud, et OpenVPN protsess töötab või et klient saaks autentida. TCP-ühenduse test on tugevam, sest käepigistus annab kindla vastuse, kuid ainult siis, kui juurutus tegelikult TCP-l kuulab. Kontrolli viimine TCP-le samal numbril testib kuulajat, mida ei pruugi olemas olla, ja ainult UDP-l töötava serveri vastu paneb see terve teenuse ebaõnnestuma.

Kontrolli sobitamine seadistatud transpordiga tuleb enne mõlema tulemuse usaldamist. UDP juurutus vajab teistsugust signaali, mitte teistsugust protokolli.

Kolm kutsujat, kolm erinevat küsimust

Valmidus sõltub sellest, kes küsib. Teenusehaldur, kes taaskäivitab kokku jooksnud protsessi, peab teadma, et eksemplar käivitus ja sidus oma kuulaja. Koormusjaotur peab teadma, et praegu saabuv klient võetaks vastu. Seiresüsteem peab teadma, et tee tegelikust võrgust kannab endiselt seanssi lubatud ressursini.

Need ei ole sama kontroll ja üks kontroll ei saa kõiki kolme ausalt katta. Valige esmalt kutsuja, seejärel tõend.

Ehitage kontroll praegusest eksemplarist

OpenVPN kirjutab käivitusrea, kui eksemplar lõpetab initsialiseerimise, ja see rida on kasulik tõend kohaliku käivituse kohta. Lugege seda praegusest käivitusest, mitte lisatava faili lõpust, sest eelmise nädala õnnestumine loetakse täpselt samamoodi nagu minuti tagune õnnestumine. Server võib initsialiseerimise lõpetada ka enne, kui ükski klient on kunagi ühendunud, seega ei ütle rida autentimise kohta midagi.

Käivituskontrolli jaoks siduge protsessi olek praeguse logitõendiga ja kuulajaga, mis vastab seadistatud transpordile. Kontroll peaks ebaõnnestuma, kui protsess töötab, kuid ei ole initsialiseerimist lõpetanud, mis tähendab, et logipäring tuleb piirata selle käivituse ja selle üksusega.

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

Kolm väljundit, kolm väidet: üksus on aktiivne, see käivitus tekitas initsialiseerimisrea ja miski hoiab UDP-porti. Ükski neist ei ütle, et klient saab ühenduda. Hoidke neid olekulehel eraldi, et juhtum ei kollapseeruks üheks roheliseks täpiks.

Lõhkuge see meelega ja jälgige kontrolli

Kontroll on usaldusväärne alles siis, kui olete näinud seda ebaõnnestumas. Peatage server, käivitage kontroll ja kinnitage oodatud tulemus. Seejärel käivitage see uuesti ja kinnitage, et kontroll taastub ilma ühegi muu muudatuseta.

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

Lugege plokki rida rea haaval. Käsk netcat prindib exit=0 samal ajal kui miski ei ole seotud, ja see on kogu probleem ühes reas. Esimene ss ei prindi midagi, taaskäivitus õnnestub ja teine ss näitab kuulajat uuesti. Kui teie kontroll läbib peatatud serveri vastu, mõõdab see kohalikku virna ja mitte midagi muud.

Vastupidine ebaõnnestumine on samuti oluline. Kontroll, mis ebaõnnestub terve serveri vastu, põhjustab taaskäivitusi, mida polnud kunagi vaja, ja taaskäivituste tsükkel on ise katkestus. Testige mõlemat suunda enne, kui ühendate kontrolli millegagi, mis saab selle põhjal tegutseda.

Mida peaks olekurea ütlema

Pange kirja, millist piiri iga kontroll katab: protsess, kuulaja, autentimine või rakendus. Üks kontroll katab harva rohkem kui ühte, ja olekuleht, mis need “up” alla kokku surub, varjab erinevust, mis juhtumi ajal loeb. Võrgutee jaoks kasutage tegelikku klienti, kellel on eraldi identiteet, laske tal lõpetada käepigistus ja üks kahjutu lubatud toiming, seejärel katkestage ühendus. See harjutab juhtkanalit, autentimispoliitikat ja kuulajat ühe sammuga.

Hoidke seda identiteeti tegelikest kasutajatest eraldi ja andke sellele miinimumõigused, mida kontroll vajab. Laia juurdepääsuga valmiduskontroll on mugavuse huvides lisatud uus ründepind. Pöörake selle volitusi nagu iga teise konto puhul, sest kontroll, mis lõpetab autentimise, näeb välja täpselt nagu server, mis lõpetas klientide vastuvõtmise.

Nimetage piir hoiatustekstis, et esimene reageerija teaks, kas vaadata üksust, pesa, sertifikaati või marsruuti. Kontroll, mis ei suuda öelda, mida ta tõestas, saab usalduse vale põhjuse tõttu, ja nii jäigi netcat-kontroll esialgu ellu.