Waarom nc -uz nie kan bewys dat 'n OpenVPN-bediener gereed is nie

Om nc -uz teen 'n OpenVPN bediener te laat loop, meet byna niks, en die OpenBSD-handleiding sê dit in sy waarskuwings: UDP-skanderings in daardie modus meld sukses ongeag of iets luister. Die uitgangstatus weerspieël die plaaslike stuur, nie die afgeleë toestand nie, so 'n toesighouer wat daarop vertrou, hou 'n dooie bediener as gesond gemerk solank die prosestabel geloofwaardig lyk. Om dit te vervang begin met die besluit watter vraag die kontrole moet beantwoord, want proses, luisteraar, verifikasie en bereikbaarheid van die toepassing is vier verskillende waarnemings. 'n Toets wat een daarvan noem, is nuttig; 'n toets wat al vier impliseer, is 'n las.

Wat 'n UDP-toets kan en nie kan waarneem nie

nc -uz stuur 'n datagram en stop, en die status wat dit teruggee beskryf die plaaslike stuur. 'n Geslote poort kan met ICMP port unreachable antwoord, maar die gedokumenteerde gedrag van hierdie skandeermodus skakel dit nie na 'n fout om nie, en 'n gefiltreerde poort gee glad geen antwoord nie. Stilte en sukses beteken dus dieselfde vir die oproeper.

Dit maak die toets 'n toets van die plaaslike stapel, nie van die bediener nie. Dit stel nie vas dat die gasheer bereikbaar is, dat die poort gebind is, dat die OpenVPN-proses loop, of dat 'n kliënt kon verifieer nie. 'n TCP-verbindingstoets is sterker omdat die handdruk 'n duidelike antwoord gee, maar net wanneer die ontplooiing werklik op TCP luister. Om die toets na TCP op dieselfde nommer te skakel, toets 'n luisteraar wat dalk nie bestaan nie, en teen 'n slegs-UDP-bediener sal dit 'n gesonde diens laat misluk.

Om die toets by die gekonfigureerde vervoer te pas, kom voor die vertroue in enige van die twee resultate. 'n UDP-ontplooiing het 'n ander sein nodig, nie 'n ander protokol nie.

Drie oproepers, drie verskillende vrae

Gereed hang af van wie vra. 'n Diensbestuurder wat 'n gestopte proses herbegin, moet weet dat die instansie begin het en sy luisteraar gebind het. 'n Lasbalanseerder moet weet dat 'n kliënt wat nou aankom, aanvaar sou word. 'n Moniteringstelsel moet weet dat die pad vanaf 'n werklike netwerk nog 'n sessie na 'n toegelate hulpbron dra.

Dit is nie dieselfde kontrole nie, en een toets kan nie al drie eerlik dek nie. Kies eers die oproeper en dan die bewyse.

Bou die toets uit die huidige instansie

OpenVPN skryf 'n opstartreël wanneer 'n instansie klaar initialiseer, en daardie reël is nuttige bewyse oor plaaslike opstart. Lees dit uit die huidige begin eerder as uit die stert van 'n aangevulde lêer, want 'n sukses van verlede week lees presies soos 'n sukses van 'n minuut gelede. 'n Bediener kan ook klaar initialiseer voordat enige kliënt ooit gekoppel het, so die reël sê niks oor verifikasie nie.

Vir 'n opstartkontrole, kombineer prosestoestand met huidige logbewyse en 'n luisteraar wat by die gekonfigureerde vervoer pas. Die kontrole moet misluk wanneer die proses loop maar nog nie klaar initialiseer het nie, wat beteken die lognavraag moet tot hierdie opstart en hierdie eenheid beperk word.

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

Drie uitsette, drie bewerings: die eenheid is aktief, hierdie opstart het die initialiseringsreël opgelewer, en iets hou die UDP-poort. Nie een van hulle sê 'n kliënt kan koppel nie. Hou hulle apart op die statusbladsy sodat 'n voorval nie in 'n enkele groen kolletjie inmekaarsak nie.

Breek dit doelbewus en kyk na die toets

'n Toets is eers betroubaar wanneer jy dit sien misluk het. Stop die bediener, laat loop die toets en bevestig die resultaat wat jy verwag. Begin dit dan weer en bevestig dat die toets herstel sonder enige ander verandering.

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 die blok reël vir reël. Die netcat-opdrag druk exit=0 terwyl niks gebind is nie, wat die hele probleem in een reël is. Die eerste ss druk niks, die herbegin slaag, en die tweede ss wys weer die luisteraar. As jou toets teen die gestopte bediener slaag, meet dit die plaaslike stapel en niks anders nie.

Die teenoorgestelde fout maak ook saak. 'n Toets wat teen 'n gesonde bediener misluk, veroorsaak herbeginnings wat nooit nodig was nie, en 'n herbegin-lus is sy eie onderbreking. Toets beide rigtings voordat jy die toets aan iets koppel wat daarop kan reageer.

Wat die statusreël moet sê

Teken aan watter grens elke kontrole dek: proses, luisteraar, verifikasie of toepassing. Een kontrole dek selde meer as een, en 'n statusbladsy wat hulle tot “up” saampers, verberg die verskil wat tydens 'n voorval saak maak. Vir die netwerkpad, gebruik 'n werklike kliënt met 'n toegewyde identiteit, laat dit die handdruk en een onskadelike toegelate bewerking voltooi en ontkoppel dan. Dit oefen die beheerkanaal, die verifikasiestelsel en die luisteraar in een stap.

Hou daardie identiteit apart van werklike gebruikers en gee dit die minimum regte wat die kontrole nodig het. 'n Gereedheidstoets met wye toegang is 'n nuwe aanvalsoppervlak wat vir gerief bygevoeg is. Roteer sy geloofsbriewe soos enige ander rekening, want 'n toets wat ophou verifieer, lyk presies soos 'n bediener wat opgehou het om kliënte te aanvaar.

Noem die grens in die waarskuwingsteks, sodat die eerste reageerder weet of hy na die eenheid, die sokkel, die sertifikaat of die roete moet kyk. 'n Toets wat nie kan sê wat dit bewys het nie, sal om die verkeerde rede vertrou word, en dit is hoe die netcat-kontrole in die eerste plek oorleef het.