Hvorfor nc -uz ikke kan bevise at en OpenVPN-server er klar

Å kjøre nc -uz mot en OpenVPN server måler nesten ingenting, og OpenBSD-håndboken sier det i forbeholdene sine: UDP-skanninger i den modusen rapporterer suksess uansett om noe lytter eller ikke. Utgangsstatusen gjenspeiler den lokale sendingen, ikke den eksterne tilstanden, så en overvåker som stoler på den holder en død server merket som frisk så lenge procestabellen ser rimelig ut. Å erstatte den begynner med å avgjøre hvilket spørsmål kontrollen skal svare på, fordi prosess, lytter, autentisering og applikasjonens tilgjengelighet er fire forskjellige observasjoner. En test som navngir én av dem er nyttig; en test som antyder alle fire er en byrde.

Hva en UDP-test kan og ikke kan observere

nc -uz sender et datagram og avslutter, og statusen den returnerer beskriver den lokale sendingen. En lukket port kan svare med ICMP port unreachable, men den dokumenterte oppførselen i denne skannemodusen gjør det ikke til en feil, og en filtrert port gir ingen svar i det hele tatt. Taushet og suksess betyr derfor det samme for den som kaller.

Det gjør testen til en test av den lokale stakken, ikke av serveren. Den fastslår ikke at verten er tilgjengelig, at porten er bundet, at OpenVPN-prosessen kjører, eller at en klient kunne autentisere seg. En TCP-tilkoblingstest er sterkere fordi håndtrykket gir et entydig svar, men bare når utplasseringen faktisk lytter på TCP. Å bytte testen til TCP på samme nummer tester en lytter som kanskje ikke finnes, og mot en server som bare bruker UDP vil det få en frisk tjeneste til å feile.

Å tilpasse testen til den konfigurerte transporten kommer før tillit til noen av de to resultatene. En UDP-utplassering trenger et annet signal, ikke en annen protokoll.

Tre kallere, tre forskjellige spørsmål

Klarhet avhenger av hvem som spør. En tjenestebehandler som starter en krasjet prosess på nytt, må vite at instansen startet og bandt lytteren sin. En lastbalanserer må vite at en klient som kommer nå, ville bli akseptert. Et overvåkingssystem må vite at veien fra et ekte nettverk fortsatt bærer en sesjon til en tillatt ressurs.

Dette er ikke den samme kontrollen, og én test kan ikke ærlig dekke alle tre. Velg først den som kaller, og deretter beviset.

Bygg testen fra den gjeldende instansen

OpenVPN skriver en oppstartslinje når en instans er ferdig med initialiseringen, og den linjen er nyttig bevis om lokal oppstart. Les den fra den gjeldende oppstarten i stedet for fra halen av en fil som legges til, fordi en suksess fra forrige uke leses nøyaktig som en suksess fra et minutt siden. En server kan også være ferdig med initialiseringen før noen klient noen gang har koblet til, så linjen sier ingenting om autentisering.

For en oppstartskontroll, kombiner prosessstatus med gjeldende loggbevis og en lytter som samsvarer med den konfigurerte transporten. Kontrollen bør feile når prosessen kjører, men ikke er ferdig med initialiseringen, noe som betyr at loggspørringen må begrenses til denne oppstarten og denne enheten.

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åstander: enheten er aktiv, denne oppstarten produserte initialiseringslinjen, og noe holder UDP-porten. Ingen av dem sier at en klient kan koble til. Hold dem atskilt på statussiden, slik at en hendelse ikke kollapser til én grønn prikk.

Bryt det med vilje og se på testen

En test er bare pålitelig når du har sett den feile. Stopp serveren, kjør testen, og bekreft resultatet du forventer. Start den deretter på nytt, og bekreft at testen kommer seg uten noen annen 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 blokken linje for linje. Netcat-kommandoen skriver ut exit=0 , mens ingenting er bundet, og det er hele problemet på én linje. Den første ss skriver ikke ut noe, omstarten lykkes, og den andre ss viser lytteren igjen. Hvis testen din passerer mot den stoppede serveren, måler den den lokale stakken og ingenting annet.

Den motsatte feilen betyr også noe. En test som feiler mot en frisk server, forårsaker omstarter som aldri var nødvendige, og en omstartsløkke er i seg selv et avbrudd. Test begge retninger før du kobler testen til noe som kan handle på den.

Hva statuslinjen bør si

Noter hvilken grense hver kontroll dekker: prosess, lytter, autentisering eller applikasjon. Én kontroll dekker sjelden mer enn én, og en statusside som komprimerer dem til “up”, skjuler forskjellen som betyr noe under en hendelse. For nettverksveien, bruk en ekte klient med en dedikert identitet, la den fullføre håndtrykket og én ufarlig tillatt operasjon, og koble den deretter fra. Det trener kontrollkanalen, autentiseringspolicyen og lytteren i ett trinn.

Hold den identiteten atskilt fra ekte brukere og gi den de minimale tillatelsene kontrollen trenger. En klarhetstest med bred tilgang er en ny angrepsflate lagt til for bekvemmelighetens skyld. Roter påloggingsinformasjonen dens som for enhver annen konto, fordi en test som slutter å autentisere ser nøyaktig ut som en server som sluttet å akseptere klienter.

Navngi grensen i varselteksten, slik at den første som reagerer vet om hun skal se på enheten, soklen, sertifikatet eller ruten. En test som ikke kan si hva den har bevist, vil bli stolt på av feil grunn, og det er hvordan netcat-kontrollen overlevde i utgangspunktet.