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

At køre nc -uz mod en OpenVPN server måler næsten intet, og OpenBSD-håndbogen siger det i sine forbehold: UDP-scanninger i den tilstand rapporterer succes, uanset om noget lytter. Exitstatussen afspejler den lokale afsendelse, ikke den fjerne tilstand, så en supervisor, der stoler på den, holder en død server markeret som sund, så længe procestabellen ser rimelig ud. At erstatte den begynder med at afgøre, hvilket spørgsmål kontrollen skal besvare, fordi proces, lytter, godkendelse og applikationens tilgængelighed er fire forskellige observationer. En test, der navngiver én af dem, er nyttig; en test, der antyder alle fire, er en byrde.

Hvad en UDP-test kan og ikke kan observere

nc -uz sender et datagram og afslutter, og den status, den returnerer, beskriver den lokale afsendelse. En lukket port kan svare med ICMP port unreachable, men den dokumenterede adfærd i denne scanningsfunktion gør det ikke til en fejl, og en filtreret port giver slet ikke noget svar. Tavshed og succes betyder derfor det samme for den, der kalder.

Det gør testen til en test af den lokale stak, ikke af serveren. Den fastslår ikke, at værten kan nås, at porten er bundet, at OpenVPN-processen kører, eller at en klient kunne godkende. En TCP-forbindelsestest er stærkere, fordi håndtrykket giver et entydigt svar, men kun når installationen faktisk lytter på TCP. At skifte testen til TCP på samme nummer tester en lytter, der måske ikke findes, og mod en server, der kun kører UDP, vil det få en sund tjeneste til at fejle.

At tilpasse testen til den konfigurerede transport kommer før tillid til et af de to resultater. En UDP-installation har brug for et andet signal, ikke en anden protokol.

Tre kaldere, tre forskellige spørgsmål

Klarhed afhænger af, hvem der spørger. En tjenestestyring, der genstarter en nedbrudt proces, skal vide, at instansen startede og bandt sin lytter. En load balancer skal vide, at en klient, der ankommer nu, ville blive accepteret. Et overvågningssystem skal vide, at vejen fra et rigtigt netværk stadig bærer en session til en tilladt ressource.

Det er ikke den samme kontrol, og én test kan ikke ærligt dække alle tre. Vælg først den, der kalder, og derefter beviset.

Byg testen ud fra den aktuelle instans

OpenVPN skriver en opstartslinje, når en instans er færdig med at initialisere, og den linje er nyttigt bevis om lokal opstart. Læs den fra den aktuelle start i stedet for fra halen af en tilføjet fil, fordi en succes fra sidste uge læses præcis som en succes fra et minut siden. En server kan også være færdig med at initialisere, før nogen klient nogensinde har forbundet, så linjen siger intet om godkendelse.

Til en opstartskontrol skal du parre procestilstand med aktuelt logbevis og en lytter, der matcher den konfigurerede transport. Kontrollen bør fejle, når processen kører, men ikke er færdig med at initialisere, hvilket betyder, at logforespørgslen skal begrænses til denne opstart og denne enhed.

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

Tre output, tre påstande: enheden er aktiv, denne opstart producerede initialiseringslinjen, og noget holder UDP-porten. Ingen af dem siger, at en klient kan forbinde. Hold dem adskilt på statussiden, så en hændelse ikke kollapser til en enkelt grøn prik.

Bryd det med vilje og se testen

En test er kun troværdig, når du har set den fejle. Stop serveren, kør testen, og bekræft det resultat, du forventer. Start den derefter igen, og bekræft, at testen kommer sig uden nogen anden ændring.

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

Læs blokken linje for linje. Netcat-kommandoen udskriver exit=0 , mens intet er bundet, og det er hele problemet på én linje. Den første ss udskriver intet, genstarten lykkes, og den anden ss viser lytteren igen. Hvis din test består mod den stoppede server, måler den den lokale stak og intet andet.

Den modsatte fejl betyder også noget. En test, der fejler mod en sund server, forårsager genstarter, som aldrig var nødvendige, og en genstartsloop er i sig selv et nedbrud. Test begge retninger, før du kobler testen til noget, der kan handle på den.

Hvad statuslinjen bør sige

Notér, hvilken grænse hver kontrol dækker: proces, lytter, godkendelse eller applikation. Én kontrol dækker sjældent mere end én, og en statusside, der komprimerer dem til “up”, skjuler den forskel, der betyder noget under en hændelse. Brug en rigtig klient med en dedikeret identitet til netværksvejen, lad den fuldføre håndtrykket og én harmløs tilladt handling, og afbryd derefter. Det træner kontrolkanalen, godkendelsespolitikken og lytteren i ét trin.

Hold den identitet adskilt fra rigtige brugere og giv den de minimale tilladelser, kontrollen har brug for. En klarhedstest med bred adgang er en ny angrebsoverflade tilføjet for nemheds skyld. Rotér dens legitimationsoplysninger som enhver anden konto, fordi en test, der holder op med at godkende, ser præcis ud som en server, der holdt op med at acceptere klienter.

Navngiv grænsen i alarmteksten, så den første, der reagerer, ved, om vedkommende skal kigge på enheden, soklen, certifikatet eller ruten. En test, der ikke kan sige, hvad den har bevist, vil blive stolet på af den forkerte grund, og det er, hvordan netcat-kontrollen overhovedet overlevede.