FreeBind kontra After=: systemd socket kötése VPN-címhez

Indításkor egy rögzített VPN-címet kötő socket-egység meghiúsulhat, mielőtt az alagút hozzárendelné a címet, és a mögötte lévő szolgáltatás soha nem indul el. Két kapcsoló javításnak látszik, és a probléma különböző felét oldja meg. A FreeBind engedi, hogy a systemd a figyelőt még a cím hiányában létrehozza. Az After= csak a feladatokat rendezi, tehát megváltoztatja, mikor indulnak a dolgok, de nem teszi korábbra a cím megérkezését.

Két különböző probléma, két különböző kapcsoló

Az első probléma a kötési hiba: a kernel megtagadja a figyelést olyan címen, amellyel a gazdagép nem rendelkezik, ezért a socket-egység azonnal meghiúsul, és a szolgáltatás soha nem aktiválódik. A második probléma a készenléti hiba: a cím végül létezik, de valami már a használatára törekszik, mielőtt az alagút forgalmat szállítana. A FreeBind az elsőt kezeli, a másodikkal nem tesz semmit. A sorrendi irányelvek egyiket sem kezelik közvetlenül, mert csak azt döntik el, mi milyen sorrendben indul. Annak megnevezése, hogy melyik hiba áll fenn valójában, maga a döntés.

A naplóból, ne a szolgáltatás leírásából erősítse meg, melyik áll fenn. A kötési hiba megnevez egy címet, és jelzi, hogy nem rendelhető hozzá. A készenléti hiba általában később jelenik meg, időtúllépésként vagy a túloldalról látott elutasított kapcsolatként, miközben a naplókban teljesen egészséges socket-egység szerepel.

FreeBind: a figyelő a cím előtt létezik

A FreeBind azt mondja a kernelnek, hogy engedélyezze a kötést nem helyi címre, így a systemd indításkor létrehozhatja a figyelő socketet, és átadhatja az alkalmazásnak, valahányszor az alkalmazás elindul. Ez a socket-aktiválás lényege, és ez az oka, amiért a socket túlélheti a mögötte lévő szolgáltatást.

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

Az üres hozzárendelés törli a szállító egységétől örökölt figyelési bejegyzéseket, mielőtt az új hozzáadódna, ami megakadályozza, hogy egy maradék wildcard-figyelő minden interfészen válaszoljon. Cserélje ki a címet és a portot a sajátjára, és az effektív egységet ellenőrizze, ne csak a drop-in fájlt. A csomagfájl helyben történő szerkesztése helyett használjon drop-int az egység neve alatt, mert a következő csomagfrissítés felülírja a szerkesztést, és nem hagy nyomot a szándékból. Ezután a socket-egység által elvárt újratöltési és újraindítási eljárással alkalmazza.

A systemd socket-referencia dokumentálja az opció mögötti IPv4- és IPv6-viselkedést, és a fontos részlet, hogy a kötésre vonatkozik, nem az útválasztásra. Semmi nem rendel hozzá címet és nem indít VPN-t. A FreeBind a figyelőnek adott engedély, nem az interfész helyettesítője.

After= és Wants=: a sorrend nem készenlét

A sorrend és a követelmény külön tengelyek, és összekeverésük olyan egységeket eredményez, amelyek a helyes sorrendben indulnak, és mégis meghiúsulnak. A After=vpn-client.service csak azt jelenti, hogy ha mindkét feladat elindul, ez megvárja a másik elindulását. Nem húzza be a VPN-t, és nem várja meg, hogy a VPN befejezze a kapcsolódást.

A követelmény-irányelvek, például a Wants= és a Requires=, az aktiválást kezelik, és abban különböznek, mi történik a függőség meghiúsulásakor: az egyik folytatódik, a másik leáll. Egyik sem tudja, mit jelent a csatlakozott alagút. Egy VPN-folyamat aktív lehet hozzárendelt cím nélkül, vagy hozzárendelt címmel és a partner felé vezető útvonal nélkül, és mindkét állapot kielégíti a függőséget. Ha az alkalmazásnak szüksége van a cím létezésére, modellezze ezt a feltételt kifejezetten, ahelyett hogy a folyamat indulását a készenlét bizonyítékának tekintené.

Ellenőrizze, mit deklarál valójában az egység a systemctl cat és a systemctl show -p After -p Wants -p Requires segítségével. Három különböző könyvtárból származó drop-in olyan irányelveket adhat hozzá, amelyeket soha nem írt meg, és a systemd csak az effektív egységet olvassa.

Amit a network-online.target nem tesz

A network-online.target után rendezett egység megvárja, hogy a hálózatkezelő használhatónak nyilvánítsa a hálózatot, ami indítási szinkronizációs pont, nem folyamatos feltétel. Semmit nem mond arról, hogy egy adott alagút fent van-e, és nem aktiválódik újra, amikor egy VPN kora délután újracsatlakozik. Újracsatlakozás-figyelőnek tekinteni a cél leggyakoribb félreolvasása.

A systemd projekt közvetlenül dokumentálja ezt a különbséget, és a gyakorlati következmény az, hogy mindennek, aminek alagútcímre van szüksége, magának kell birtokolnia a függőséget. Egy egység, amely megvárja a network-online-t, majd alagútcímet köt, csak akkor helyes, ha az alagút véletlenül előbb jön fel, ez pedig véletlen, nem tervezés.

Tesztelje a ténylegesen választott életciklust

Tesztelje a tiszta indítást, a cím megjelenése utáni kérést, és a viselkedést, miután a VPN leesik és visszatér. Ez a három eset választja el a működő figyelőt a működő szolgáltatástól.

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

Az első parancs az újraindítás előtt elkapja az egységfájl hibáit, a második az összevont egységet mutatja, a harmadik pedig bizonyítja, hogy létezik-e a figyelő, és melyik címen. A figyelő wildcard-címen ott, ahol alagútcímet várt, pontosan az a maradék, amelyet az üres ListenStream-nek el kellett volna távolítania. Ismételje meg a harmadik parancsot VPN-újracsatlakozás után, hogy lássa, elmozdult-e a cím.

Válassza meg az életciklust szándékosan: vagy egy szabadon kötött figyelőt, amely egy stabil cím visszatérésére vár, vagy egy szolgáltatást, amely az alagúttal leáll, és helyreálláskor újraindul. Ezek különböző tervek, és különböző módon hiúsulnak meg. Ezután tartsa a hozzáférési szabályzatot a szándékolt forrásokhoz és útvonalakhoz kötve, mert a célcím kötése nem követeli meg, hogy az elfogadott csomagok megbízható interfészen érkeztek.