Kvifor nc -uz ikkje kan prova at ein OpenVPN-server er klar

Å køyra nc -uz mot ein OpenVPN server måler nesten ingenting, og OpenBSD-handboka seier det i atterhalda sine: UDP-skanningar i den modusen rapporterer suksess anten noko lyttar eller ikkje. Utgangsstatusen speglar den lokale sendinga, ikkje den eksterne tilstanden, så ein overvakar som stolar på han held ein død server merkt som frisk så lenge procestabellen ser rimeleg ut. Å erstatta han byrjar med å avgjera kva spørsmål kontrollen skal svara på, fordi prosess, lyttar, autentisering og tilgjenge til applikasjonen er fire ulike observasjonar. Ein test som namngir éin av dei er nyttig; ein test som antydar alle fire er ei bør.

Kva ein UDP-test kan og ikkje kan observera

nc -uz sender eit datagram og avsluttar, og statusen han returnerer skildrar den lokale sendinga. Ein lukka port kan svara med ICMP port unreachable, men den dokumenterte åtferda i denne skannemodusen gjer det ikkje til ein feil, og ein filtrert port gir ingen svar i det heile. Tagnad og suksess tyder derfor det same for den som kallar.

Det gjer testen til ein test av den lokale stakken, ikkje av serveren. Han slår ikkje fast at verten er tilgjengeleg, at porten er bunden, at OpenVPN-prosessen køyrer, eller at ein klient kunne autentisera seg. Ein TCP-tilkoplingstest er sterkare fordi handtrykket gir eit eintydig svar, men berre når utrullinga faktisk lyttar på TCP. Å byta testen til TCP på same nummer testar ein lyttar som kanskje ikkje finst, og mot ein server som berre brukar UDP vil det få ei frisk teneste til å feila.

Å tilpassa testen til den konfigurerte transporten kjem før tillit til noko av dei to resultata. Ei UDP-utrulling treng eit anna signal, ikkje ein annan protokoll.

Tre kallarar, tre ulike spørsmål

Klarheit avheng av kven som spør. Ein tenestebehandlar som startar ein krasja prosess på nytt, må vita at instansen starta og batt lyttaren sin. Ein lastbalansar må vita at ein klient som kjem no, ville bli godteken. Eit overvakingssystem må vita at vegen frå eit ekte nettverk framleis ber ein sesjon til ein tillaten ressurs.

Dette er ikkje den same kontrollen, og ein test kan ikkje ærleg dekkja alle tre. Vel fyrst den som kallar, og deretter provet.

Bygg testen frå den gjeldande instansen

OpenVPN skriv ei oppstartsline når ein instans er ferdig med initialiseringa, og den lina er nyttig prov om lokal oppstart. Les henne frå den gjeldande oppstarten i staden for frå halen av ei fil som blir lagd til, fordi ein suksess frå førre veke blir lesen nøyaktig som ein suksess frå eit minutt sidan. Ein server kan òg vera ferdig med initialiseringa før nokon klient nokon gong har kopla til, så lina seier ingenting om autentisering.

For ein oppstartskontroll, kombiner prosessstatus med gjeldande loggprov og ein lyttar som samsvarer med den konfigurerte transporten. Kontrollen bør feila når prosessen køyrer, men ikkje er ferdig med initialiseringa, noko som tyder at loggspørjinga må avgrensast til denne oppstarten og denne eininga.

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

Tre utdata, tre påstandar: eininga er aktiv, denne oppstarten produserte initialiseringslina, og noko held UDP-porten. Ingen av dei seier at ein klient kan kopla til. Hald dei fråskilde på statussida, slik at ei hending ikkje kollapsar til éin grøn prikk.

Bryt det med vilje og sjå på testen

Ein test er berre påliteleg når du har sett han feila. Stopp serveren, køyr testen, og stadfest resultatet du ventar. Start han deretter på nytt, og stadfest at testen kjem seg utan noka anna endring.

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

Les blokka line for line. Netcat-kommandoen skriv ut exit=0 , medan ingenting er bunde, og det er heile problemet på éi line. Den fyrste ss skriv ikkje ut noko, omstarten lukkast, og den andre ss viser lyttaren igjen. Viss testen din passerer mot den stoppa serveren, måler han den lokale stakken og ingenting anna.

Den motsette feilen tyder òg noko. Ein test som feilar mot ein frisk server, fører til omstartar som aldri var naudsynte, og ei omstartsløkke er i seg sjølv eit avbrot. Test begge retningar før du koplar testen til noko som kan handla på han.

Kva statuslina bør seia

Noter kva grense kvar kontroll dekkjer: prosess, lyttar, autentisering eller applikasjon. Éin kontroll dekkjer sjeldan meir enn éin, og ei statusside som komprimerer dei til “up”, skjuler skilnaden som tel under ei hending. For nettverksvegen, bruk ein ekte klient med ein dedikert identitet, la han fullføra handtrykket og éin ufarleg tillaten operasjon, og kopla han deretter frå. Det trenar kontrollkanalen, autentiseringspolicyen og lyttaren i eitt steg.

Hald den identiteten fråskild frå ekte brukarar og gi han dei minimale løyva kontrollen treng. Ein klarheitstest med brei tilgang er ei ny åtaksoverflate lagd til for å vera praktisk. Roter påloggingsinformasjonen hans som for kvar annan konto, fordi ein test som sluttar å autentisera ser nøyaktig ut som ein server som slutta å ta imot klientar.

Namngi grensa i varselteksten, slik at den fyrste som reagerer veit om ho skal sjå på eininga, sokelen, sertifikatet eller ruta. Ein test som ikkje kan seia kva han har prova, vil bli stolt på av feil grunn, og det er korleis netcat-kontrollen overlevde i utgangspunktet.