Waarom nc -uz niet kan bewijzen dat een OpenVPN-server klaar is

Het draaien van nc -uz tegen een OpenVPN server meet bijna niets, en de OpenBSD-handleiding zegt dat in zijn waarschuwingen: UDP-scans in die modus melden succes, of er nu iets luistert of niet. De exitstatus weerspiegelt het lokale verzenden, niet de externe toestand, dus een supervisor die erop vertrouwt, houdt een dode server als gezond gemarkeerd zolang de procestabel aannemelijk lijkt. Het vervangen begint met de beslissing welke vraag de controle moet beantwoorden, want proces, luisteraar, authenticatie en bereikbaarheid van de applicatie zijn vier verschillende observaties. Een controle die er één benoemt, is nuttig; een controle die alle vier impliceert, is een last.

Wat een UDP-controle wel en niet kan waarnemen

nc -uz stuurt een datagram en stopt, en de status die het teruggeeft beschrijft het lokale verzenden. Een gesloten poort kan antwoorden met ICMP port unreachable, maar het gedocumenteerde gedrag van deze scanmodus maakt daar geen fout van, en een gefilterde poort geeft helemaal geen antwoord. Stilte en succes betekenen voor de aanroeper dus hetzelfde.

Daarmee is de controle een test van de lokale stack, niet van de server. Ze stelt niet vast dat de host bereikbaar is, dat de poort gebonden is, dat het OpenVPN-proces draait of dat een client zich zou kunnen authenticeren. Een TCP-verbindingstest is sterker omdat de handdruk een duidelijk antwoord geeft, maar alleen wanneer de uitrol echt op TCP luistert. De controle naar TCP op hetzelfde nummer omzetten test een luisteraar die er misschien niet is, en tegen een server met alleen UDP laat het een gezonde dienst mislukken.

De controle afstemmen op het geconfigureerde transport komt vóór vertrouwen in een van beide resultaten. Een UDP-uitrol heeft een ander signaal nodig, geen ander protocol.

Drie aanroepers, drie verschillende vragen

Gereedheid hangt ervan af wie het vraagt. Een servicemanager die een gecrasht proces herstart, moet weten dat de instantie is gestart en zijn luisteraar heeft gebonden. Een load balancer moet weten dat een client die nu aankomt, zou worden geaccepteerd. Een monitoringsysteem moet weten dat het pad van een echt netwerk nog steeds een sessie naar een toegestane bron draagt.

Dat is niet dezelfde controle, en één controle kan niet alle drie eerlijk dekken. Kies eerst de aanroeper en dan het bewijs.

Bouw de controle vanuit de huidige instantie

OpenVPN schrijft een opstartregel wanneer een instantie klaar is met initialiseren, en die regel is nuttig bewijs over de lokale start. Lees hem uit de huidige start in plaats van uit de staart van een aangevuld bestand, want een succes van vorige week leest precies zoals een succes van een minuut geleden. Een server kan ook klaar zijn met initialiseren voordat ooit een client verbinding heeft gemaakt, dus de regel zegt niets over authenticatie.

Voor een opstartcontrole combineert u de procestoestand met actueel logbewijs en een luisteraar die bij het geconfigureerde transport past. De controle moet falen wanneer het proces draait maar niet klaar is met initialiseren, wat betekent dat de logquery beperkt moet blijven tot deze boot en deze unit.

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

Drie uitvoerwaarden, drie beweringen: de unit is actief, deze boot produceerde de initialisatieregel, en iets houdt de UDP-poort. Geen ervan zegt dat een client kan verbinden. Houd ze gescheiden op de statuspagina, zodat een incident niet in één groene stip samenvalt.

Breek het expres en kijk naar de controle

Een controle is pas betrouwbaar als u hem hebt zien falen. Stop de server, voer de controle uit en bevestig het verwachte resultaat. Start hem daarna weer en bevestig dat de controle herstelt zonder enige andere wijziging.

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

Lees het blok regel voor regel. Het netcat-commando drukt exit=0 af terwijl er niets gebonden is, en dat is het hele probleem in één regel. De eerste ss drukt niets af, de herstart lukt, en de tweede ss toont de luisteraar weer. Als uw controle slaagt tegen de gestopte server, meet hij de lokale stack en niets anders.

De omgekeerde fout telt ook. Een controle die faalt tegen een gezonde server veroorzaakt herstarts die nooit nodig waren, en een herstartlus is op zichzelf een storing. Test beide richtingen voordat u de controle aansluit op iets dat erop kan handelen.

Wat de statusregel zou moeten zeggen

Noteer welke grens elke controle dekt: proces, luisteraar, authenticatie of applicatie. Eén controle dekt zelden meer dan één, en een statuspagina die ze tot “up” samendrukt, verbergt het verschil dat tijdens een incident telt. Gebruik voor het netwerkpad een echte client met een eigen identiteit, laat die de handdruk en één onschuldige toegestane bewerking voltooien en verbreek daarna de verbinding. Dat oefent het besturingskanaal, het authenticatiebeleid en de luisteraar in één stap.

Houd die identiteit gescheiden van echte gebruikers en geef haar de minimale rechten die de controle nodig heeft. Een gereedheidscontrole met brede toegang is een nieuw aanvalsoppervlak dat voor het gemak is toegevoegd. Roteer haar inloggegevens zoals bij elk ander account, want een controle die stopt met authenticeren ziet er precies uit als een server die stopte met het accepteren van clients.

Benoem de grens in de alarmtekst, zodat de eerste reageerder weet of hij naar de unit, de socket, het certificaat of de route moet kijken. Een controle die niet kan zeggen wat ze heeft bewezen, wordt om de verkeerde reden vertrouwd, en zo heeft de netcat-controle het überhaupt overleefd.