Miért nem tudja a nc -uz bizonyítani, hogy egy OpenVPN-kiszolgáló készen áll

A nc -uz futtatása egy OpenVPN kiszolgáló ellen szinte semmit sem mér, és az OpenBSD kézikönyve ezt mondja a fenntartásaiban: az UDP-vizsgálatok abban a módban sikert jelentenek, akár figyel valami, akár nem. A kilépési állapot a helyi küldést tükrözi, nem a távoli állapotot, ezért a felügyelő, amely megbízik benne, halott kiszolgálót tart egészségesként megjelölve, amíg a folyamattábla hihetőnek tűnik. A lecserélése annak eldöntésével kezdődik, melyik kérdésre kell az ellenőrzésnek válaszolnia, mert a folyamat, a figyelő, a hitelesítés és az alkalmazás elérhetősége négy különböző megfigyelés. Egy próba, amely megnevez egyet közülük, hasznos; egy próba, amely mind a négyet sugallja, teher.

Mit tud és mit nem tud megfigyelni egy UDP-próba

nc -uz küld egy datagramot és kilép, és a visszaadott állapot a helyi küldést írja le. Egy zárt port válaszolhat ICMP port unreachable üzenettel, de ennek a vizsgálati módnak a dokumentált viselkedése nem alakítja ezt hibává, és egy szűrt port egyáltalán nem ad választ. A csend és a siker tehát ugyanazt jelenti a hívó számára.

Ez a próbát a helyi verem, nem a kiszolgáló tesztjévé teszi. Nem állapítja meg, hogy a gazdagép elérhető, hogy a port kötött, hogy az OpenVPN folyamat fut, vagy hogy egy kliens tudna hitelesíteni. A TCP-kapcsolati teszt erősebb, mert a kézfogás egyértelmű választ ad, de csak akkor, ha a telepítés valóban TCP-n figyel. A próba átállítása TCP-re ugyanazon a számon olyan figyelőt tesztel, amely talán nem is létezik, és egy csak UDP-t használó kiszolgálóval szemben egy egészséges szolgáltatást buktat el.

A próba illesztése a beállított átvitelhez megelőzi a két eredmény bármelyikébe vetett bizalmat. Egy UDP-telepítésnek más jelre van szüksége, nem más protokollra.

Három hívó, három különböző kérdés

A készenlét attól függ, ki kérdez. Egy szolgáltatáskezelő, amely újraindít egy összeomlott folyamatot, tudni akarja, hogy a példány elindult és lekötötte a figyelőjét. Egy terheléselosztó tudni akarja, hogy egy most érkező kliens elfogadásra kerülne. Egy megfigyelő rendszer tudni akarja, hogy egy valódi hálózat felőli útvonal még mindig munkamenetet visz egy engedélyezett erőforráshoz.

Ezek nem ugyanaz az ellenőrzés, és egy próba nem tudja mindhármat tisztességesen lefedni. Először a hívót válassza, aztán a bizonyítékot.

A próbát a jelenlegi példányból építse fel

Az OpenVPN indítási sort ír, amikor egy példány befejezi az inicializálást, és ez a sor hasznos bizonyíték a helyi indításról. A jelenlegi indításból olvassa, ne egy hozzáfűzött fájl végéről, mert a múlt heti siker pontosan úgy olvasható, mint egy perccel ezelőtti siker. Egy kiszolgáló akkor is befejezheti az inicializálást, mielőtt bármelyik kliens valaha csatlakozott volna, ezért a sor semmit sem mond a hitelesítésről.

Indítási ellenőrzéshez párosítsa a folyamat állapotát a jelenlegi naplóbizonyítékkal és a beállított átvitelhez illeszkedő figyelővel. Az ellenőrzésnek akkor kell meghiúsulnia, amikor a folyamat fut, de még nem fejezte be az inicializálást, ami azt jelenti, hogy a naplólekérdezést erre az indításra és erre az egységre kell korlátozni.

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

Három kimenet, három állítás: az egység aktív, ez az indítás állította elő az inicializálási sort, és valami fogja az UDP-portot. Egyik sem mondja, hogy egy kliens csatlakozhat. Tartsa őket külön az állapotoldalon, hogy egy incidens ne omladjon össze egyetlen zöld ponttá.

Törje el szándékosan, és figyelje a próbát

Egy próba csak akkor megbízható, ha látta meghiúsulni. Állítsa le a kiszolgálót, futtassa a próbát, és erősítse meg a várt eredményt. Utána indítsa újra, és erősítse meg, hogy a próba minden más változtatás nélkül helyreáll.

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

Olvassa végig a blokkot soronként. A netcat parancs ezt írja ki: exit=0 , miközben semmi sincs lekötve, és ez a teljes probléma egyetlen sorban. Az első ss semmit sem ír ki, az újraindítás sikerül, és a második ss újra mutatja a figyelőt. Ha a próbája a leállított kiszolgálóval szemben is átmegy, akkor a helyi vermet méri, és semmi mást.

Az ellenkező irányú hiba is számít. Egy próba, amely egy egészséges kiszolgálóval szemben meghiúsul, olyan újraindításokat okoz, amelyekre soha nem volt szükség, és az újraindítási hurok önmagában is kiesés. Mindkét irányt tesztelje, mielőtt a próbát bármihez csatlakoztatná, ami cselekedhet rá.

Mit kellene mondania az állapotsornak

Jegyezze fel, melyik határt fedi le az egyes ellenőrzés: folyamat, figyelő, hitelesítés vagy alkalmazás. Egy ellenőrzés ritkán fed többet egynél, és az az állapotoldal, amely “up” alá préseli őket, elrejti az incidens alatt számító különbséget. A hálózati útvonalhoz valódi klienst használjon dedikált identitással, hagyja befejezni a kézfogást és egy ártalmatlan engedélyezett műveletet, majd bontsa a kapcsolatot. Ez egy lépésben gyakoroltatja a vezérlőcsatornát, a hitelesítési szabályzatot és a figyelőt.

Tartsa ezt az identitást külön a valódi felhasználóktól, és adja meg neki a minimális jogosultságokat, amelyekre az ellenőrzésnek szüksége van. A széles hozzáférésű készenléti próba egy új támadási felület, amelyet a kényelemért adtak hozzá. Forgassa a hitelesítő adatait, mint bármely más fióknál, mert egy próba, amely abbahagyja a hitelesítést, pontosan úgy néz ki, mint egy kiszolgáló, amely abbahagyta a kliensek fogadását.

Nevezze meg a határt a riasztás szövegében, hogy az első reagáló tudja, az egységet, a foglalatot, a tanúsítványt vagy az útvonalat kell-e néznie. Egy próbát, amely nem tudja megmondani, mit bizonyított, rossz okból fognak megbízhatónak tartani, és a netcat-ellenőrzés éppen így maradt fenn eleve.