FreeBind prieš After=: systemd lizdo susiejimas su VPN adresu

Įkrovimo metu lizdo vienetas, susiejantis fiksuotą VPN adresą, gali nepavykti dar prieš tuneliui jį priskiriant, ir už jo esanti tarnyba niekada nepasileidžia. Du jungikliai atrodo kaip pataisos ir sprendžia skirtingas tos problemos puses. FreeBind leidžia systemd sukurti klausytoją, kol adreso dar nėra. After= tik išdėsto užduotis, todėl keičia, kada dalykai prasideda, bet nepadaro, kad adresas atsirastų anksčiau.

Dvi skirtingos problemos, du skirtingi jungikliai

Pirmoji problema – susiejimo klaida: branduolys atsisako klausytis adreso, kurio pagrindinis kompiuteris neturi, todėl lizdo vienetas iš karto nepavyksta ir tarnyba niekada neaktyvuojama. Antroji problema – pasirengimo klaida: adresas galiausiai egzistuoja, bet kažkas bando jį naudoti, kol tunelis dar neperduoda srauto. FreeBind sprendžia pirmąją ir nieko nedaro dėl antrosios. Tvarkos direktyvos tiesiogiai nesprendžia nė vienos, nes jos tik nusprendžia, kas kokia tvarka prasideda. Pavadinti klaidą, kuri iš tikrųjų yra, ir yra visas sprendimas.

Patvirtinkite, kuri iš dviejų yra, iš žurnalo, o ne iš tarnybos aprašymo. Susiejimo klaida įvardija adresą ir praneša, kad jo negalima priskirti. Pasirengimo klaida paprastai pasirodo vėliau – kaip skirtasis laikas arba iš kitos pusės matomas atmestas ryšys, o žurnaluose lieka visiškai sveikas lizdo vienetas.

FreeBind: klausytojas egzistuoja prieš adresą

FreeBind nurodo branduoliui leisti susieti su ne vietiniu adresu, todėl systemd gali įkrovimo metu sukurti klausantį lizdą ir perduoti jį programai, kai tik programa pasileidžia. Tai ir yra lizdo aktyvavimo esmė, ir priežastis, kodėl lizdas gali pergyventi už jo esančią tarnybą.

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

Tuščias priskyrimas išvalo iš tiekėjo vieneto paveldėtus klausymo įrašus prieš pridedant naują, o tai neleidžia likusiam wildcard klausytojui atsakyti visose sąsajose. Pakeiskite adresą ir prievadą savaisiais ir patikrinkite veiksmingą vienetą, o ne vien drop-in failą. Naudokite drop-in vieneto pavadinimu, o ne redaguokite paketo failą vietoje, nes kitas paketo atnaujinimas perrašys pakeitimą ir nepaliks jokio ketinimo pėdsako. Tada pritaikykite jį perkrovimo ir paleidimo iš naujo procedūra, kurios tikisi lizdo vienetas.

systemd lizdų žinynas dokumentuoja IPv4 ir IPv6 elgseną už šios parinkties, o svarbi detalė ta, kad ji taikoma susiejimui, o ne maršrutizavimui. Niekas jame nepriskiria adreso ir nepaleidžia VPN. FreeBind yra klausytojui suteiktas leidimas, o ne sąsajos pakaitalas.

After= ir Wants=: tvarka nėra pasirengimas

Tvarka ir reikalavimas yra atskiros ašys, o jų painiojimas sukuria vienetus, kurie prasideda teisinga tvarka ir vis tiek nepavyksta. After=vpn-client.service reiškia tik tai, kad jei abi užduotys paleidžiamos, ši laukia, kol kita bus paleista. Jis neįtraukia VPN ir nelaukia, kol VPN baigs jungtis.

Reikalavimo direktyvos, tokios kaip Wants= ir Requires=, tvarko aktyvavimą ir skiriasi tuo, kas nutinka, kai priklausomybė nepavyksta: viena tęsia, kita sustoja. Nė viena nežino, ką reiškia prijungtas tunelis. VPN procesas gali būti aktyvus nepriskyrus adreso arba su priskirtu adresu ir be maršruto iki partnerio, ir abi būsenos tenkina priklausomybę. Jei programai reikia, kad adresas egzistuotų, modeliuokite tą sąlygą aiškiai, o ne laikykite proceso paleidimo pasirengimo įrodymu.

Patikrinkite, ką vienetas iš tikrųjų deklaruoja, naudodami systemctl cat ir systemctl show -p After -p Wants -p Requires. Trijų skirtingų katalogų drop-in gali pridėti direktyvų, kurių niekada nerašėte, o systemd skaito tik veiksmingą vienetą.

Ko network-online.target nedaro

Vienetas, išdėstytas po network-online.target, laukia, kol tinklo valdytojas paskelbs tinklą tinkamu naudoti, o tai yra įkrovimo sinchronizacijos taškas, o ne nuolatinė sąlyga. Jis nieko nesako apie tai, ar konkretus tunelis pakeltas, ir nebeveiks, kai VPN po pietų vėl prisijungs. Laikyti jį prisijungimo stebėtoju yra labiausiai paplitęs klaidingas to tikslo skaitymas.

systemd projektas tiesiogiai dokumentuoja šį skirtumą, o praktinė pasekmė ta, kad viskas, kam reikia tunelio adreso, turi pats turėti priklausomybę. Vienetas, kuris palaukia network-online ir tada susieja tunelio adresą, yra teisingas tik tada, kai tunelis atsitiktinai pakyla pirmas, o tai atsitiktinumas, o ne dizainas.

Išbandykite gyvavimo ciklą, kurį iš tikrųjų pasirinkote

Išbandykite švarų įkrovimą, užklausą po to, kai atsiranda adresas, ir elgseną po to, kai VPN nukrenta ir grįžta. Šie trys atvejai atskiria veikiantį klausytoją nuo veikiančios tarnybos.

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

Pirmoji komanda pagauna vieneto failo klaidas prieš paleidimą iš naujo, antroji parodo sujungtą vienetą, o trečioji įrodo, ar klausytojas egzistuoja ir kokiame adrese. Klausytojas wildcard adresu ten, kur tikėjotės tunelio adreso, yra būtent ta liekana, kurią tuščias ListenStream turėjo pašalinti. Pakartokite trečiąją komandą po VPN prisijungimo iš naujo, kad pamatytumėte, ar adresas pasislinko.

Pasirinkite gyvavimo ciklą sąmoningai: arba laisvai susietą klausytoją, kuris laukia, kol grįš stabilus adresas, arba tarnybą, kuri sustoja kartu su tuneliu ir vėl pasileidžia atsistačius. Tai skirtingi dizainai ir jie nepavyksta skirtingai. Tada laikykite prieigos politiką susietą su tais šaltiniais ir keliais, kuriuos ketinote, nes paskirties adreso susiejimas nereikalauja, kad priimti paketai atėjo per patikimą sąsają.