Kial nc -uz ne povas pruvi, ke OpenVPN-servilo estas preta

Lanĉi nc -uz kontraŭ OpenVPN servilo preskaŭ nenion mezuras, kaj la manlibro de OpenBSD diras tion en siaj atentigoj: UDP-skanoj en tiu reĝimo raportas sukceson sendepende de tio, ĉu io aŭskultas. La elirstato spegulas la lokan sendon, ne la malproksiman staton, do kontrolisto, kiu fidas ĝin, tenas mortan servilon markita kiel sana tiel longe, kiel la procezotabelo aspektas kredebla. Anstataŭigi ĝin komenciĝas per decido, al kiu demando la kontrolo devas respondi, ĉar procezo, aŭskultanto, aŭtentigo kaj atingeblo de la aplikaĵo estas kvar malsamaj observoj. Kontrolo, kiu nomas unu el ili, estas utila; kontrolo, kiu implicas ĉiujn kvar, estas ŝarĝo.

Kion UDP-kontrolo povas kaj ne povas observi

nc -uz sendas datagramon kaj eliras, kaj la stato, kiun ĝi redonas, priskribas la lokan sendon. Fermita pordo povas respondi per ICMP port unreachable, sed la dokumentita konduto de ĉi tiu skana reĝimo ne transformas tion en malsukceson, kaj filtrita pordo tute ne produktas respondon. Do silento kaj sukceso signifas la saman aferon por la alvokanto.

Tio faras la kontrolon teston de la loka stako, ne de la servilo. Ĝi ne establas, ke la gastiganto estas atingebla, ke la pordo estas ligita, ke la procezo OpenVPN funkcias aŭ ke kliento povus aŭtentigi. TCP-konekta testo estas pli forta, ĉar la manpremo donas definitivan respondon, sed nur kiam la starigo vere aŭskultas sur TCP. Ŝanĝi la kontrolon al TCP sur la sama numero testas aŭskultanton, kiu eble ne ekzistas, kaj kontraŭ servilo nur kun UDP ĝi malsukcesigos sanan servon.

Adapti la kontrolon al la agordita transporto venas antaŭ fidi ajnan el la du rezultoj. UDP-starigo bezonas alian signalon, ne alian protokolon.

Tri alvokantoj, tri malsamaj demandoj

Preteco dependas de tio, kiu demandas. Servadministranto, kiu restartigas kraŝintan procezon, devas scii, ke la instanco ekfunkciis kaj ligis sian aŭskultanton. Ŝarĝbalancilo devas scii, ke kliento alvenanta nun estus akceptita. Monitorada sistemo devas scii, ke la vojo el reala reto ankoraŭ portas sesion al permesita rimedo.

Tiuj ne estas la sama kontrolo, kaj unu kontrolo ne povas honeste kovri ĉiujn tri. Elektu unue la alvokanton, poste la pruvon.

Konstruu la kontrolon el la nuna instanco

OpenVPN skribas startan linion, kiam instanco finas la inicializadon, kaj tiu linio estas utila pruvo pri loka starto. Legu ĝin el la nuna starto, ne el la fino de aldonita dosiero, ĉar sukceso de pasinta semajno legiĝas same kiel sukceso de antaŭ minuto. Servilo ankaŭ povas fini la inicializadon antaŭ ol iu ajn kliento iam konektiĝis, do la linio diras nenion pri aŭtentigo.

Por starta kontrolo, parigu la procezan staton kun nuna protokola pruvo kaj aŭskultanto, kiu kongruas kun la agordita transporto. La kontrolo devus malsukcesi, kiam la procezo funkcias sed ne finis la inicializadon, kio signifas, ke la protokola demando devas esti limigita al ĉi tiu starto kaj ĉi tiu unuo.

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

Tri eligoj, tri asertoj: la unuo estas aktiva, ĉi tiu starto produktis la inicializadan linion, kaj io tenas la UDP-pordon. Neniu el ili diras, ke kliento povas konektiĝi. Tenu ilin aparte sur la stata paĝo, por ke okazaĵo ne kolapsu en unu verdan punkton.

Rompu ĝin intence kaj observu la kontrolon

Kontrolo estas fidinda nur post kiam vi vidis ĝin malsukcesi. Haltigu la servilon, lanĉu la kontrolon kaj konfirmu la rezulton, kiun vi atendas. Poste restartigu ĝin kaj konfirmu, ke la kontrolo resaniĝas sen iu ajn alia ŝanĝo.

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

Legu la blokon linio post linio. La komando netcat presas exit=0 dum nenio estas ligita, kaj tio estas la tuta problemo en unu linio. La unua ss presas nenion, la restartigo sukcesas, kaj la dua ss denove montras la aŭskultanton. Se via kontrolo pasas kontraŭ la haltigita servilo, ĝi mezuras la lokan stakon kaj nenion alian.

La kontraŭa malsukceso ankaŭ gravas. Kontrolo, kiu malsukcesas kontraŭ sana servilo, kaŭzas restartigojn, kiuj neniam estis necesaj, kaj restartiga buklo estas mem interrompo. Testu ambaŭ direktojn antaŭ ol vi konekti la kontrolon al io, kio povas agi laŭ ĝi.

Kion la stata linio devus diri

Notu, kiun limon ĉiu kontrolo kovras: procezo, aŭskultanto, aŭtentigo aŭ aplikaĵo. Unu kontrolo malofte kovras pli ol unu, kaj stata paĝo, kiu kunpremas ilin al “up”, kaŝas la diferencon, kiu gravas dum okazaĵo. Por la reta vojo uzu realan klienton kun dediĉita identeco, lasu ĝin fini la manpremon kaj unu sendanĝeran permesitan operacion, poste malkonektu. Tio ekzercas la regan kanalon, la aŭtentigan politikon kaj la aŭskultanton en unu paŝo.

Tenu tiun identecon aparte de realaj uzantoj kaj donu al ĝi la minimumajn permesojn, kiujn la kontrolo bezonas. Preteca kontrolo kun vasta aliro estas nova ataksurfaco aldonita por komforto. Rotaciu ĝiajn akreditaĵojn kiel ĉe iu ajn alia konto, ĉar kontrolo, kiu ĉesas aŭtentigi, aspektas ekzakte kiel servilo, kiu ĉesis akcepti klientojn.

Nomu la limon en la alarmteksto, por ke la unua respondanto sciu, ĉu rigardi la unuon, la ingon, la atestilon aŭ la itineron. Kontrolo, kiu ne povas diri, kion ĝi pruvis, estos fidita pro la malĝusta kialo, kaj tiel la netcat-kontrolo unuavice postvivis.