Zakaj nc -uz ne more dokazati, da je strežnik OpenVPN pripravljen

Zagon nc -uz proti strežniku OpenVPN skoraj ničesar ne izmeri, in priročnik OpenBSD to pove v svojih opozorilih: skeniranja UDP v tem načinu sporočajo uspeh ne glede na to, ali kaj posluša. Izhodni status odraža lokalno pošiljanje, ne oddaljenega stanja, zato nadzornik, ki mu zaupa, drži mrtev strežnik označen kot zdrav, dokler je tabela procesov videti verjetna. Zamenjava se začne z odločitvijo, na katero vprašanje mora preverjanje odgovoriti, ker so proces, poslušalec, preverjanje pristnosti in dosegljivost aplikacije štiri različna opažanja. Preizkus, ki poimenuje eno od njih, je koristen; preizkus, ki nakazuje vse štiri, je breme.

Kaj lahko preizkus UDP opazuje in česa ne

nc -uz pošlje datagram in se konča, vrnjeni status pa opisuje lokalno pošiljanje. Zaprta vrata lahko odgovorijo z ICMP port unreachable, vendar dokumentirano vedenje tega načina skeniranja tega ne spremeni v napako, filtrirana vrata pa ne dajo nobenega odgovora. Tišina in uspeh torej za klicatelja pomenita isto.

To naredi preizkus preizkusom lokalnega sklada, ne strežnika. Ne ugotovi, da je gostitelj dosegljiv, da so vrata vezana, da proces OpenVPN teče ali da bi se odjemalec lahko preveril. Preizkus povezave TCP je močnejši, ker rokovanje da jasen odgovor, a le ko namestitev res posluša na TCP. Preklop preizkusa na TCP na isti številki preizkusi poslušalca, ki ga morda ni, in proti strežniku samo z UDP bo pustil zdravo storitev propasti.

Uskladitev preizkusa s konfiguriranim prenosom pride pred zaupanjem v kateri koli od obeh rezultatov. Namestitev UDP potrebuje drug signal, ne drugega protokola.

Trije klicatelji, tri različna vprašanja

Pripravljenost je odvisna od tega, kdo vpraša. Upravitelj storitev, ki znova zažene strnjen proces, mora vedeti, da se je instanca zagnala in vezala svojega poslušalca. Izravnalnik obremenitve mora vedeti, da bi bil odjemalec, ki pride zdaj, sprejet. Nadzorni sistem mora vedeti, da pot iz resničnega omrežja še vedno nosi sejo do dovoljenega vira.

To ni isto preverjanje in en preizkus ne more pošteno pokriti vseh treh. Najprej izberite klicatelja, nato dokaz.

Zgradite preizkus iz trenutne instance

OpenVPN zapiše zagonsko vrstico, ko instanca konča inicializacijo, in ta vrstica je koristen dokaz o lokalnem zagonu. Berite jo iz trenutnega zagona, ne s konca pripisane datoteke, ker se uspeh od prejšnjega tedna bere natanko tako kot uspeh od pred minuto. Strežnik lahko inicializacijo konča tudi preden se je kdaj povezal kateri koli odjemalec, zato vrstica ne pove ničesar o preverjanju pristnosti.

Za zagonski preizkus povežite stanje procesa s trenutnim dokazom iz dnevnika in poslušalcem, ki ustreza konfiguriranemu prenosu. Preizkus mora propasti, ko proces teče, a inicializacije ni končal, kar pomeni, da je treba poizvedbo v dnevnik omejiti na ta zagon in to enoto.

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

Trije izhodi, tri trditve: enota je aktivna, ta zagon je ustvaril inicializacijsko vrstico in nekaj drži vrata UDP. Nobena od njih ne pravi, da se odjemalec lahko poveže. Držite jih ločeno na strani stanja, da se incident ne zlije v eno zeleno piko.

Zlomite to namerno in opazujte preizkus

Preizkus je zanesljiv šele, ko ste videli, da je propadel. Ustavite strežnik, zaženite preizkus in potrdite pričakovani rezultat. Nato ga znova zaženite in potrdite, da si preizkus opomore brez kakršne koli druge spremembe.

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

Preberite blok vrstico za vrstico. Ukaz netcat izpiše exit=0 , medtem ko nič ni vezano, in to je vsa težava v eni vrstici. Prvi ss ne izpiše ničesar, ponovni zagon uspe, drugi ss pa znova pokaže poslušalca. Če vaš preizkus uspe proti ustavljenemu strežniku, meri lokalni sklad in nič drugega.

Tudi nasprotna napaka šteje. Preizkus, ki spodleti proti zdravemu strežniku, povzroči ponovne zagone, ki nikoli niso bili potrebni, ponovni zagon pa je sam po sebi izpad. Preizkusite obe smeri, preden preizkus priključite na karkoli, kar lahko ukrepa na podlagi njega.

Kaj naj pove vrstica stanja

Zapišite, katero mejo pokriva vsak preizkus: proces, poslušalec, preverjanje pristnosti ali aplikacijo. En preizkus redko pokrije več kot eno, stran stanja, ki jih stisne v “up”, pa skrije razliko, ki je med incidentom pomembna. Za omrežno pot uporabite pravega odjemalca z namensko identiteto, pustite mu dokončati rokovanje in eno neškodljivo dovoljeno operacijo, nato pa ga odklopite. To vadi krmilni kanal, politiko preverjanja pristnosti in poslušalca v enem koraku.

To identiteto hranite ločeno od resničnih uporabnikov in ji dajte najmanjše pravice, ki jih preizkus potrebuje. Preizkus pripravljenosti s širokim dostopom je nova napadalna površina, dodana zaradi udobja. Vrtite njene poverilnice kot pri vsakem drugem računu, ker je preizkus, ki preneha preverjati pristnost, videti natanko kot strežnik, ki je prenehal sprejemati odjemalce.

Poimenujte mejo v besedilu opozorila, da bo prvi, ki se odzove, vedel, ali naj pogleda enoto, vtičnico, potrdilo ali pot. Preizkusu, ki ne more povedati, kaj je dokazal, bodo zaupali iz napačnega razloga, in prav zato je preizkus z netcatom sploh preživel.