Miksi nc -uz ei voi todistaa, että OpenVPN-palvelin on valmis

Komennon nc -uz ajaminen OpenVPN palvelinta vastaan ei mittaa juuri mitään, ja OpenBSD:n käsikirja sanoo sen varoituksissaan: UDP-skannaukset tuossa tilassa ilmoittavat onnistumisesta riippumatta siitä, kuunteleeko mikään. Poistumistila heijastaa paikallista lähetystä, ei etätilaa, joten valvoja, joka luottaa siihen, pitää kuollutta palvelinta terveenä niin kauan kuin prosessitaulukko näyttää uskottavalta. Korvaaminen alkaa päättämällä, mihin kysymykseen tarkistuksen pitäisi vastata, koska prosessi, kuuntelija, todennus ja sovelluksen tavoitettavuus ovat neljä eri havaintoa. Tarkistus, joka nimeää yhden niistä, on hyödyllinen; tarkistus, joka vihjaa kaikkiin neljään, on taakka.

Mitä UDP-tarkistus voi ja ei voi havaita

nc -uz lähettää datagrammin ja poistuu, ja palautettu tila kuvaa paikallista lähetystä. Suljettu portti voi vastata ICMP port unreachable, mutta tämän skannaustilan dokumentoitu käyttäytyminen ei muuta sitä epäonnistumiseksi, eikä suodatettu portti anna lainkaan vastausta. Hiljaisuus ja onnistuminen merkitsevät siis kutsujalle samaa.

Tämä tekee tarkistuksesta paikallisen pinon, ei palvelimen testin. Se ei vahvista, että isäntä on tavoitettavissa, että portti on sidottu, että OpenVPN-prosessi on käynnissä tai että asiakas voisi todentaa. TCP-yhteystesti on vahvempi, koska kättely antaa selvän vastauksen, mutta vain kun käyttöönotto todella kuuntelee TCP:tä. Tarkistuksen vaihtaminen TCP:hen samalla numerolla testaa kuuntelijaa, jota ei ehkä ole, ja vain UDP:tä käyttävää palvelinta vastaan se epäonnistuttaa terveen palvelun.

Tarkistuksen sovittaminen määritettyyn siirtotiehen tulee ennen kumpaankaan tulokseen luottamista. UDP-käyttöönotto tarvitsee eri signaalin, ei eri protokollaa.

Kolme kutsujaa, kolme eri kysymystä

Valmius riippuu siitä, kuka kysyy. Palvelunhallinta, joka käynnistää kaatuneen prosessin uudelleen, tarvitsee tiedon siitä, että instanssi käynnistyi ja sitoi kuuntelijansa. Kuormantasaaja tarvitsee tiedon siitä, että nyt saapuva asiakas hyväksyttäisiin. Valvontajärjestelmä tarvitsee tiedon siitä, että polku todellisesta verkosta kuljettaa yhä istuntoa sallittuun resurssiin.

Nämä eivät ole sama tarkistus, eikä yksi tarkistus voi rehellisesti kattaa kaikkia kolmea. Valitse ensin kutsuja ja sitten todiste.

Rakenna tarkistus nykyisestä instanssista

OpenVPN kirjoittaa käynnistysrivin, kun instanssi lopettaa alustuksen, ja se rivi on hyödyllinen todiste paikallisesta käynnistyksestä. Lue se nykyisestä käynnistyksestä äläkä lisättävän tiedoston lopusta, koska viime viikon onnistuminen luetaan täsmälleen kuten minuutin takainen onnistuminen. Palvelin voi myös lopettaa alustuksen ennen kuin yksikään asiakas on koskaan yhdistänyt, joten rivi ei kerro todennuksesta mitään.

Käynnistystarkistuksessa yhdistä prosessin tila nykyiseen lokitodisteeseen ja kuuntelijaan, joka vastaa määritettyä siirtotietä. Tarkistuksen pitäisi epäonnistua, kun prosessi on käynnissä mutta ei ole lopettanut alustusta, mikä tarkoittaa, että lokikysely on rajattava tähän käynnistykseen ja tähän yksikköön.

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

Kolme tulostetta, kolme väitettä: yksikkö on aktiivinen, tämä käynnistys tuotti alustusrivin ja jokin pitää UDP-porttia. Mikään niistä ei kerro, että asiakas voi yhdistää. Pidä ne erillään tilasivulla, jotta tapahtuma ei luhistu yhdeksi vihreäksi pisteeksi.

Riko se tarkoituksella ja katso tarkistusta

Tarkistus on luotettava vasta, kun olet nähnyt sen epäonnistuvan. Pysäytä palvelin, aja tarkistus ja vahvista odotettu tulos. Käynnistä se sitten uudelleen ja vahvista, että tarkistus palautuu ilman mitään muuta muutosta.

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

Lue lohko rivi riviltä. Netcat-komento tulostaa exit=0 , vaikka mikään ei ole sidottu, ja siinä on koko ongelma yhdellä rivillä. Ensimmäinen ss ei tulosta mitään, uudelleenkäynnistys onnistuu ja toinen ss näyttää kuuntelijan taas. Jos tarkistuksesi läpäisee pysäytettyä palvelinta vastaan, se mittaa paikallista pinoa eikä mitään muuta.

Vastakkainen epäonnistuminen on myös tärkeä. Tarkistus, joka epäonnistuu tervettä palvelinta vastaan, aiheuttaa uudelleenkäynnistyksiä, joita ei koskaan tarvittu, ja uudelleenkäynnistyssilmukka on itsessään katkos. Testaa molemmat suunnat ennen kuin kytket tarkistuksen mihinkään, mikä voi toimia sen perusteella.

Mitä tilarivin pitäisi sanoa

Kirjaa, minkä rajan kukin tarkistus kattaa: prosessi, kuuntelija, todennus tai sovellus. Yksi tarkistus kattaa harvoin useampaa kuin yhtä, ja tilasivu, joka puristaa ne “up”-tilaan, kätkee eron, jolla on merkitystä tapahtuman aikana. Verkkopolulle käytä oikeaa asiakasta, jolla on oma identiteetti, anna sen suorittaa kättely ja yksi harmiton sallittu toimenpide ja katkaise sitten. Se harjoittaa ohjauskanavaa, todennuskäytäntöä ja kuuntelijaa yhdellä askeleella.

Pidä tämä identiteetti erillään oikeista käyttäjistä ja anna sille vähimmäisoikeudet, jotka tarkistus tarvitsee. Laajan pääsyn valmiustarkistus on mukavuuden vuoksi lisätty uusi hyökkäyspinta. Kierrätä sen tunnistetiedot kuin millä tahansa muulla tilillä, koska tarkistus, joka lopettaa todennuksen, näyttää täsmälleen palvelimelta, joka lopetti asiakkaiden hyväksymisen.

Nimeä raja hälytyksen tekstissä, jotta ensimmäinen vastaaja tietää, katsoako yksikköä, pistoketta, varmennetta vai reittiä. Tarkistusta, joka ei voi sanoa mitä todisti, luotetaan väärästä syystä, ja juuri niin netcat-tarkistus alun perin säilyi.