FreeBind pret After=: systemd ligzdas piesaiste VPN adresei

Sāknēšanas laikā ligzdas vienība, kas piesaista fiksētu VPN adresi, var neizdoties pirms tunelis to piešķīris, un aiz tās esošais pakalpojums nekad nesākas. Divi slēdži izskatās kā labojumi un risina dažādas šīs problēmas puses. FreeBind ļauj systemd izveidot klausītāju, kamēr adreses vēl nav. After= tikai sakārto uzdevumus, tāpēc tas maina, kad lietas sākas, bet nepanāk, ka adrese pienāk agrāk.

Divas dažādas problēmas, divi dažādi slēdži

Pirmā problēma ir piesaistes kļūda: kodols atsakās klausīties adresē, kas resursdatoram nepieder, tāpēc ligzdas vienība nekavējoties neizdodas un pakalpojums nekad netiek aktivizēts. Otrā problēma ir gatavības kļūda: adrese galu galā pastāv, bet kaut kas mēģina to izmantot, pirms tunelis pārvada datplūsmu. FreeBind risina pirmo un neko nedara otrajai. Secības direktīvas tieši nerisina nevienu, jo tās tikai izlemj, kas kādā secībā sākas. Kļūdas nosaukšana, kas jums patiešām ir, ir viss lēmums.

Pārliecinieties, kura no abām ir, žurnālā, nevis pakalpojuma aprakstā. Piesaistes kļūda nosauc adresi un ziņo, ka to nevar piešķirt. Gatavības kļūda parasti parādās vēlāk, kā taimauts vai no otras puses redzams noraidīts savienojums, kamēr žurnālos ir pilnīgi vesela ligzdas vienība.

FreeBind: klausītājs pastāv pirms adreses

FreeBind liek kodolam atļaut piesaisti ne-lokālai adresei, lai systemd varētu izveidot klausošos ligzdu sāknēšanas laikā un nodot to lietotnei, kad vien lietotne sākas. Tā ir ligzdas aktivizācijas būtība un iemesls, kāpēc ligzda var pārdzīvot aiz tās esošo pakalpojumu.

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

Tukšais piešķīrums notīra no piegādātāja vienības mantotos klausīšanās ierakstus pirms jaunā pievienošanas, kas neļauj atlikušajam wildcard klausītājam atbildēt visos saskarnēs. Aizstājiet adresi un portu ar savējiem un pārbaudiet efektīvo vienību, nevis tikai drop-in failu. Izmantojiet drop-in zem vienības nosaukuma, nevis rediģējiet pakotnes failu uz vietas, jo nākamais pakotnes atjauninājums pārrakstīs labojumu un neatstās nekādas nolūka pēdas. Pēc tam piemērojiet to ar pārlādes un restartēšanas procedūru, ko ligzdas vienība sagaida.

systemd ligzdu uzziņa dokumentē IPv4 un IPv6 uzvedību aiz šīs opcijas, un svarīgā detaļa ir tā, ka tā attiecas uz piesaisti, nevis maršrutēšanu. Nekas tajā nepiešķir adresi un nepalaiž VPN. FreeBind ir klausītājam piešķirta atļauja, nevis saskarnes aizstājējs.

After= un Wants=: secība nav gatavība

Secība un prasība ir atsevišķas asis, un to sajaukšana rada vienības, kas sākas pareizā secībā un tomēr neizdodas. After=vpn-client.service nozīmē tikai to, ka, ja tiek palaisti abi uzdevumi, šis gaida otra palaišanu. Tas neievelk VPN un negaida, kamēr VPN pabeidz savienošanos.

Prasības direktīvas, piemēram, Wants= un Requires=, nodarbojas ar aktivizāciju, un tās atšķiras ar to, kas notiek, kad atkarība neizdodas: viena turpina, otra apstājas. Neviena nezina, ko nozīmē savienots tunelis. VPN process var būt aktīvs bez piešķirtas adreses, vai ar piešķirtu adresi un bez maršruta uz partneri, un abi stāvokļi apmierina atkarību. Ja lietotnei ir vajadzīga adreses pastāvēšana, modelējiet šo nosacījumu skaidri, nevis uzskatiet procesa palaišanu par gatavības pierādījumu.

Pārbaudiet, ko vienība patiešām deklarē, ar systemctl cat un systemctl show -p After -p Wants -p Requires. Drop-in no trim dažādām mapēm var pievienot direktīvas, ko nekad neesat rakstījis, un systemd lasa tikai efektīvo vienību.

Ko network-online.target nedara

Vienība, kas sakārtota pēc network-online.target, gaida, kad tīkla pārvaldnieks pasludinās tīklu lietojamu, kas ir sāknēšanas sinhronizācijas punkts, nevis pastāvīgs nosacījums. Tā neko nepasaka par to, vai konkrēts tunelis ir augšā, un neiedarbosies vēlreiz, kad VPN pēcpusdienā atkal pievienosies. Uzskatīt to par atkārtotas pievienošanās monitoru ir visizplatītākā šī mērķa nepareizā lasīšana.

systemd projekts dokumentē šo atšķirību tieši, un praktiskā sekas ir tāda, ka visam, kam vajadzīga tuneļa adrese, pašam jāpārvalda atkarība. Vienība, kas sagaida network-online un pēc tam piesaista tuneļa adresi, ir pareiza tikai tad, kad tunelis nejauši paceļas pirmais, un tas ir nejaušība, nevis dizains.

Pārbaudiet dzīves ciklu, kuru patiešām izvēlējāties

Pārbaudiet tīru sāknēšanu, pieprasījumu pēc adreses parādīšanās un uzvedību pēc tam, kad VPN nokrīt un atgriežas. Šie trīs gadījumi atdala strādājošu klausītāju no strādājoša pakalpojuma.

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

Pirmā komanda pārķer vienības faila kļūdas pirms restartēšanas, otrā parāda apvienoto vienību, un trešā pierāda, vai klausītājs pastāv un kurā adresē. Klausītājs wildcard adresē tur, kur gaidījāt tuneļa adresi, ir tieši tas atlikums, kas tukšajam ListenStream bija jānoņem. Atkārtojiet trešo komandu pēc VPN atkārtotas pievienošanās, lai redzētu, vai adrese ir pārvietojusies.

Izvēlieties dzīves ciklu apzināti: vai nu brīvi piesaistītu klausītāju, kas gaida stabilas adreses atgriešanos, vai pakalpojumu, kas apstājas kopā ar tuneli un atkal sākas pēc atjaunošanās. Tie ir dažādi dizaini un tie neizdodas dažādi. Pēc tam turiet piekļuves politiku saistītu ar tiem avotiem un ceļiem, ko bijāt iecerējis, jo galamērķa adreses piesaiste neprasa, lai pieņemtās paketes būtu ieradušās caur uzticamu saskarni.