Wêrom nc -uz net bewize kin dat in OpenVPN-tsjinner klear is

It draaien fan nc -uz tsjin in OpenVPN tsjinner mjit hast neat, en de OpenBSD-hânlieding seit it yn syn warskôgings: UDP-skans yn dy modus melde súkses, oft der no wat harket of net. De útgongstatus wjerspegelet it lokale ferstjoeren, net de fiere tastân, dus in tafersjochhâlder dy't derop fertrout hâldt in deade tsjinner as sûn markearre salang't de prosestabel leaudber liket. It ferfangen begjint mei te besluten hokker fraach de keuring beäntwurdzje moat, want proses, harker, autentikaasje en berikberens fan de applikaasje binne fjouwer ferskillende waarnimmings. In keuring dy't ien fan dy neamt is nuttich; in keuring dy't alle fjouwer ymplisearret is in lêst.

Wat in UDP-keuring waarnimme kin en wat net

nc -uz stjoert in datagram en giet fuort, en de status dy't it weromjout beskriuwt it lokale ferstjoeren. In sletten poarte kin antwurdzje mei ICMP port unreachable, mar it dokumintearre gedrach fan dizze skanmodus makket dêr gjin mislearring fan, en in filtere poarte jout hielendal gjin antwurd. Dêrom betsjutte stilte en súkses itselde foar de oanropper.

Dat makket de keuring in test fan 'e lokale stapel, net fan 'e tsjinner. It fêststelt net dat de host berikber is, dat de poarte bûn is, dat it OpenVPN-proses draait of dat in klant autentisearje koe. In TCP-ferbiningstest is sterker, om't de hânskudding in dúdlik antwurd jout, mar allinnich as de ynset echt op TCP harket. De keuring op itselde nûmer nei TCP omsette testet in harker dy't der miskien net is, en tsjin in tsjinner mei allinnich UDP sil it in sûne tsjinst mislearje litte.

It ôfstimmen fan 'e keuring op it konfigurearre ferfier komt foar it fertrouwen yn ien fan beide resultaten. In UDP-ynset hat in oar sinjaal nedich, net in oar protokol.

Trije oanroppers, trije ferskillende fragen

Klear hinget ôf fan wa't it freget. In tsjinstbehearder dy't in stoart proses werstart moat witte dat de ynstânsje start is en syn harker bûn hat. In lêstferpartsjer moat witte dat in klant dy't no oankomt akseptearre wurde soe. In monitoring-systeem moat witte dat it paad fan in echt netwurk noch in sesje nei in tastien boarne draacht.

Dat is net deselde keuring, en ien keuring kin net alle trije earlik dekke. Kies earst de oanropper en dan it bewiis.

Bou de keuring fan 'e hjoeddeiske ynstânsje

OpenVPN skriuwt in startrigel as in ynstânsje it initialisearjen dien hat, en dy rigel is nuttich bewiis oer de lokale start. Lês him fan 'e hjoeddeiske start en net fan 'e sturt fan in oanfolle bestân, want súkses fan ferline wike lêst krekt as súkses fan in minút lyn. In tsjinner kin it initialisearjen ek dien meitsje foardat ea in klant ferbûn is, dus de rigel seit neat oer autentikaasje.

Foar in startkeuring kombinearje jo de prosestastân mei aktueel bewiis út it loch en in harker dy't by it konfigurearre ferfier past. De keuring moat mislearje as it proses draait mar it initialisearjen net dien hat, wat betsjut dat de lochfraach beheind wurde moat ta dizze boot en dizze ienheid.

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

Trije útgeans, trije bewearings: de ienheid is aktyf, dizze boot hat de initialisaasjerigel makke, en der is wat dat de UDP-poarte hâldt. Net ien fan dy seit dat in klant ferbine kin. Hâld se apart op 'e statuspagina, sadat in ynsidint net yn ien grien punt gearfalt.

Breek it mei opsetsin en besjoch de keuring

In keuring is pas fertrouber as jo him mislearje sjoen hawwe. Stopje de tsjinner, draai de keuring en befêstigje it resultaat dat jo ferwachtsje. Start him dan wer en befêstigje dat de keuring betteret sûnder oare feroaring.

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 it blok rigel foar rigel. It netcat-kommando printsje exit=0 wylst der neat bûn is, en dat is it hiele probleem yn ien rigel. De earste ss printsjet neat, de werstart slagget, en de twadde ss lit de harker wer sjen. As jo keuring tsjin 'e stoppe tsjinner slagget, mjit er de lokale stapel en neat oars.

De tsjinstelde mislearring is ek wichtich. In keuring dy't tsjin in sûne tsjinner mislearret feroarsaket werstarts dy't nea nedich wiene, en in werstart-lus is sels in steuring. Test beide rjochtingen foardat jo de keuring oan eat keppelje dat derop hannelje kin.

Wat de statusrigel sizze moat

Skriuw op hokker grins elke keuring dekt: proses, harker, autentikaasje of applikaasje. Ien keuring dekt selden mear as ien, en in statuspagina dy't se yn “up” gearpakt ferberget it ferskil dat by in ynsidint ta saak docht. Brûk foar it netwurkpaad in echte klant mei in eigen identiteit, lit him de hânskudding en ien harmless tasteane operaasje dien meitsje en ferbine dan. Dat oefenet it kontrôlekanaal, it autentikaasjebelied en de harker yn ien stap.

Hâld dy identiteit apart fan echte brûkers en jou him de minimale rjochten dy't de keuring nedich hat. In klearheidskeuring mei brede tagong is in nij oanfalsoerflak dat foar gemak tafoege is. Rotaasje de ynloggegevens lykas by elk oar akkount, want in keuring dy't ophâldt mei autentisearjen liket krekt as in tsjinner dy't ophâldt mei klanten akseptearjen.

Neam de grins yn 'e alerte tekst, sadat de earste reagearder wit oft er nei de ienheid, de socket, it sertifikaat of de rûte sjen moat. In keuring dy't net sizze kin wat er bewiisd hat, sil om 'e ferkearde reden fertroud wurde, en sa hat de netcat-keuring it earst oerlibbe.