FreeBind eta After=: systemd socket bat VPN helbide bati lotzea

Abioan, VPN helbide finko bat lotzen duen socket unitate batek huts egin dezake tunelak helbidea esleitu aurretik, eta haren atzeko zerbitzua ez da inoiz abiarazten. Bi etengailuk konponbide dirudite eta arazo horren erdi desberdinak konpontzen dituzte. FreeBindek systemd-ri entzulea sortzen uzten dio helbidea oraindik falta den bitartean. After= lanak ordenatzen ditu soilik, beraz gauzak noiz hasten diren aldatzen du, helbidea lehenago iritsarazi gabe.

Bi arazo desberdin, bi etengailu desberdin

Lehen arazoa lotura-hutsegitea da: kernelak ukatzen du ostalariak ez duen helbide batean entzutea, beraz socket unitateak berehala huts egiten du eta zerbitzua ez da inoiz aktibatzen. Bigarren arazoa prestutasun-hutsegitea da: helbidea azkenean badago, baina zerbait hura erabiltzen saiatzen da tunelak trafikoa eraman aurretik. FreeBindek lehena lantzen du eta ez du ezer egiten bigarrenerako. Ordena-zuzentarauak ez dira zuzenean bietako batekin ere aritzen, zer noiz hasten den erabakitzen baitute soilik. Benetan duzun hutsegitea izendatzea da erabaki osoa.

Egiaztatu bi horietako zein duzun erregistrotik, ez zerbitzuaren deskribapenetik. Lotura-hutsegiteak helbide bat aipatzen du eta ezin dela esleitu jakinarazten du. Prestutasun-hutsegitea normalean geroago agertzen da, denbora-muga edo beste aldetik ikusitako konexio ukatua bezala, erregistroetan socket unitate guztiz osasuntsua dagoelarik.

FreeBind: entzulea helbidea baino lehen dago

FreeBindek kernelari helbide ez-lokalean lotzea baimendu dezala esaten dio, horrela systemdek abioan entzuten duen socketa sor dezake eta aplikazioari eman diezaioke aplikazioa hasten den bakoitzean. Hori da socket aktibazioaren zentzua eta socketa haren atzeko zerbitzuaren gainetik iraun dezakeen arrazoia.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Esleipen hutsak hornitzailearen unitatetik heredatutako entzute-sarrerak ezabatzen ditu berria gehitu aurretik, eta horrek gainerako wildcard entzule bat interfaze guztietan erantzutea eragozten du. Ordeztu helbidea eta ataka zureekin eta egiaztatu unitate eraginkorra, ez drop-in fitxategia soilik. Erabili drop-in bat unitatearen izenpean paketeko fitxategia bertan editatu beharrean, hurrengo pakete-eguneratzeak edizioa gainidatziko baitu eta asmoaren arrastorik ez du utziko. Ondoren aplikatu socket unitateak espero duen birkarga eta berrabiarazte prozeduraren bidez.

systemd socket erreferentziak aukeraren atzeko IPv4 eta IPv6 portaera dokumentatzen du, eta xehetasun garrantzitsua da loturari aplikatzen zaiola, ez bideratzeari. Ezerk ez du helbiderik esleitzen ezta VPNik abiarazten ere. FreeBind entzuleari emandako baimena da, ez interfazearen ordezkoa.

After= eta Wants=: ordena ez da prestutasuna

Ordena eta baldintza ardatz bereiziak dira, eta hauek nahasteak ordena egokian hasten diren eta hala ere huts egiten duten unitateak sortzen ditu. After=vpn-client.service ek esan nahi du, bi lanak abiarazten badira, honek bestea abiaraztea itxaroten duela. Ez du VPN-a erakartzen eta ez du VPN-a konektatzen amaitzea itxaroten.

Wants= eta Requires= bezalako baldintza-zuzentarauak aktibazioaz arduratzen dira eta desberdinak dira mendekotasunak huts egitean zer gertatzen den: batek jarraitzen du, besteak gelditzen da. Batak ere ez daki zer esan nahi duen konektatutako tunel batek. VPN prozesu bat aktibo egon daiteke helbiderik esleitu gabe, edo helbidea esleitua eta parekidera biderik gabe, eta bi egoerek betetzen dute mendekotasuna. Aplikazioak helbidea existitzea behar badu, modelatu baldintza hori esplizituki, prozesuaren hasiera prestutasunaren froga balitz bezala hartu beharrean.

Egiaztatu unitateak benetan zer adierazten duen systemctl cat eta systemctl show -p After -p Wants -p Requires erabiliz. Hiru direktorio desberdinetako drop-in-ek inoiz idatzi ez zenituen zuzentarauak gehi ditzakete, eta systemdek unitate eraginkorra soilik irakurtzen du.

network-online.target-ek egiten ez duena

network-online.target ren ondoren ordenatutako unitate batek sare-kudeatzaileak sarea erabilgarri dela adieraztea itxaroten du, eta hori abioko sinkronizazio-puntu bat da, ez baldintza jarraitua. Ez du ezer esaten tunel jakin bat martxan ote dagoen, eta ez da berriro piztuko VPN bat arratsalde erdian berriz konektatzen denean. Berrikonexio-monitore gisa hartzea helburu horren okerreko irakurketa ohikoena da.

systemd proiektuak bereizketa hori zuzenean dokumentatzen du, eta ondorio praktikoa da tunel helbide bat behar duen edozein gauzak berak eduki behar duela mendekotasuna. network-online itxaron eta gero tunel helbide bat lotzen duen unitate bat zuzena da tunela kasualitatez lehenengo igotzen denean soilik, eta hori kasualitatea da, ez diseinua.

Probatu benetan aukeratu duzun bizi-zikloa

Probatu abio garbia, helbidea agertu ondorengo eskaera eta VPN-a erori eta itzuli ondorengo portaera. Hiru kasu horiek entzule funtzionala zerbitzu funtzionaletik bereizten dute.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Lehen komandoak unitate-fitxategiko erroreak harrapatzen ditu berrabiarazi aurretik, bigarrenak unitate bateratua erakusten du, eta hirugarrenak entzulea existitzen den eta zein helbidetan frogatzen du. Tunel helbidea espero zenuen tokian wildcard helbideko entzule bat da ListenStream hutsak kendu behar zuen hondarra zehazki. Errepikatu hirugarren komandoa VPN-a berriz konektatu ondoren helbidea mugitu den ikusteko.

Aukeratu bizi-zikloa berariaz: edo helbide egonkor baten itzulera itxaroten duen entzule libreki lotua, edo tunelarekin gelditzen den eta berreskuratzean berriro abiarazten den zerbitzua. Diseinu desberdinak dira eta modu desberdinetan huts egiten dute. Gero mantendu sarbide-politika asmo zenuen iturri eta bideei lotuta, helmuga-helbide bat lotzeak ez baitu eskatzen onartutako paketeak interfaze fidagarri batetik iritsi izana.