FreeBind proti After=: vezava systemd vtičnice na naslov VPN

Ob zagonu lahko vtičniška enota, ki veže fiksni naslov VPN, spodleti, preden ji tunel dodeli naslov, in storitev za njo se nikoli ne zažene. Dve stikali sta videti kot popravka in rešujeta različni polovici te težave. FreeBind omogoča systemd, da ustvari poslušalca, medtem ko naslov še manjka. After= le razvrsti opravila, zato spreminja, kdaj se stvari začnejo, ne da bi naslov prišel prej.

Dve različni težavi, dve različni stikali

Prva težava je napaka pri vezavi: jedro zavrne poslušanje na naslovu, ki ga gostitelj ne poseduje, zato vtičniška enota takoj spodleti in storitev se nikoli ne aktivira. Druga težava je napaka pripravljenosti: naslov na koncu obstaja, a nekaj ga poskuša uporabiti, preden tunel prenaša promet. FreeBind rešuje prvo in ne naredi ničesar za drugo. Direktive vrstnega reda ne rešujejo nobene neposredno, ker le odločajo, kaj se v katerem vrstnem redu začne. Poimenovati napako, ki jo res imate, je celotna odločitev.

Preverite, katero od dveh imate, v dnevniku, ne v opisu storitve. Napaka pri vezavi navede naslov in sporoči, da ga ni mogoče dodeliti. Napaka pripravljenosti se običajno pojavi pozneje, kot potek časa ali zavrnjena povezava, videna z druge strani, medtem ko je v dnevnikih povsem zdrava vtičniška enota.

FreeBind: poslušalec obstaja pred naslovom

FreeBind jedru naroči, naj dovoli vezavo na nelokalni naslov, tako da lahko systemd ob zagonu ustvari poslušajočo vtičnico in jo preda aplikaciji, kadar koli se aplikacija zažene. To je smisel aktivacije z vtičnico in razlog, da lahko vtičnica preživi storitev za seboj.

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

Prazna dodelitev izbriše vnose poslušanja, podedovane od enote ponudnika, preden se doda novi, kar prepreči preostalemu poslušalcu wildcard, da bi odgovarjal na vseh vmesnikih. Zamenjajte naslov in vrata s svojimi in preverite učinkovito enoto, ne le datoteke drop-in. Uporabite drop-in pod imenom enote, namesto da urejate datoteko paketa na mestu, ker bo naslednja posodobitev paketa prepisala spremembo in ne bo pustila nobene sledi o nameri. Nato jo uporabite s postopkom ponovnega nalaganja in zagona, ki ga vtičniška enota pričakuje.

Referenca za systemd vtičnice dokumentira vedenje IPv4 in IPv6 za to možnostjo, pomembna podrobnost pa je, da velja za vezavo in ne za usmerjanje. Nič v njej ne dodeli naslova ali zažene VPN. FreeBind je dovoljenje, dano poslušalcu, ne nadomestilo vmesnika.

After= in Wants=: vrstni red ni pripravljenost

Vrstni red in zahteva sta ločeni osi, njuno mešanje pa ustvari enote, ki se zaženejo v pravem vrstnem redu in vseeno spodletijo. After=vpn-client.service pomeni le, da če se zaženeta obe opravili, to čaka na zagon drugega. Ne potegne VPN in ne čaka, da VPN konča povezovanje.

Zahtevne direktive, kot sta Wants= in Requires=, skrbijo za aktivacijo in se razlikujejo v tem, kaj se zgodi, ko odvisnost spodleti: ena nadaljuje, druga se ustavi. Nobena ne ve, kaj pomeni povezan tunel. Proces VPN je lahko aktiven brez dodeljenega naslova ali z dodeljenim naslovom in brez poti do partnerja, oba stanja pa izpolnjujeta odvisnost. Če aplikacija potrebuje obstoj naslova, modelirajte ta pogoj izrecno, namesto da bi zagon procesa imeli za dokaz pripravljenosti.

Preverite, kaj enota v resnici razglasi, z systemctl cat in systemctl show -p After -p Wants -p Requires. Drop-in iz treh različnih map lahko dodajo direktive, ki jih niste nikoli napisali, systemd pa bere le učinkovito enoto.

Česa network-online.target ne naredi

Enota, razvrščena za network-online.target, čaka, da upravitelj omrežja razglasi omrežje za uporabno, kar je sinhronizacijska točka ob zagonu in ne trajen pogoj. Ne pove ničesar o tem, ali je določen tunel gor, in se ne sproži znova, ko se VPN sredi popoldneva znova poveže. Imeti ga za nadzornik ponovne povezave je najpogostejše napačno branje tega cilja.

Projekt systemd to razliko dokumentira neposredno, praktična posledica pa je, da mora vse, kar potrebuje naslov tunela, odvisnost imeti samo. Enota, ki počaka na network-online in nato veže naslov tunela, je pravilna le, ko se tunel slučajno dvigne prvi, in to je naključje, ne zasnova.

Preizkusite življenjski cikel, ki ste ga res izbrali

Preizkusite čist zagon, zahtevo po pojavu naslova in vedenje po tem, ko VPN pade in se vrne. Ti trije primeri ločijo delujočega poslušalca od delujoče storitve.

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

Prvi ukaz ujame napake v datoteki enote pred ponovnim zagonom, drugi pokaže združeno enoto, tretji pa dokaže, ali poslušalec obstaja in na katerem naslovu. Poslušalec na naslovu wildcard tam, kjer ste pričakovali naslov tunela, je natanko tisti ostanek, ki naj bi ga prazni ListenStream odstranil. Po ponovni povezavi VPN ponovite tretji ukaz in preverite, ali se je naslov premaknil.

Življenjski cikel izberite zavestno: bodisi prosto vezan poslušalec, ki čaka na vrnitev stabilnega naslova, bodisi storitev, ki se ustavi s tunelom in se ob obnovitvi znova zažene. To so različne zasnove in spodletijo na različne načine. Nato držite politiko dostopa vezano na vire in poti, ki ste jih nameravali, ker vezava ciljnega naslova ne zahteva, da so sprejeti paketi prispeli skozi zaupanja vreden vmesnik.