FreeBind vs After=: systemd soketi sidumine VPN-aadressiga

Alglaadimisel võib fikseeritud VPN-aadressi siduv soketiüksus nurjuda enne, kui tunnel selle määrab, ja selle taga olev teenus ei käivitu kunagi. Kaks lülitit näivad lahendustena ja lahendavad selle probleemi erinevaid pooli. FreeBind laseb systemd-il kuulaja luua siis, kui aadress veel puudub. After= ainult järjestab töid, seega muudab see, millal asjad algavad, ilma et aadress varem kohale jõuaks.

Kaks erinevat probleemi, kaks erinevat lülitit

Esimene probleem on sidumise tõrge: kernel keeldub kuulamisest aadressil, mida host ei oma, seega soketiüksus nurjub kohe ja teenust ei aktiveerita kunagi. Teine probleem on valmisoleku tõrge: aadress on lõpuks olemas, aga miski üritab seda kasutada enne, kui tunnel liiklust kannab. FreeBind tegeleb esimesega ja ei tee teise jaoks midagi. Järjestusdirektiivid ei tegele otseselt kummagagi, sest need otsustavad ainult, mis mis järjekorras algab. Selle tõrke nimetamine, mis teil tegelikult on, ongi kogu otsus.

Kinnitage, kumb neist teil on, päevikust, mitte teenuse kirjeldusest. Sidumise tõrge nimetab aadressi ja teatab, et seda ei saa määrata. Valmisoleku tõrge ilmub tavaliselt hiljem, aegumise või vastaspoolelt nähtud tagasilükatud ühendusena, samal ajal kui logis on täiesti terve soketiüksus.

FreeBind: kuulaja on enne aadressi

FreeBind ütleb kernelile, et lubada sidumist mittekohaliku aadressiga, nii et systemd saab alglaadimisel kuulava soketi luua ja anda selle rakendusele üle alati, kui rakendus käivitub. See on soketiaktiveerimise mõte ja põhjus, miks socket võib selle taga olevast teenusest kauem kesta.

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

Tühi määramine kustutab tarnijaüksusest päritud kuulamis-kirjed enne uue lisamist, mis takistab ülejäänud metamärgiga kuulajal igal liidesel vastata. Asendage aadress ja port enda omadega ning kontrollige tegelikku üksust, mitte ainult drop-in-faili. Kasutage drop-in-faili üksuse nime all, mitte ärge muutke paketifaili kohapeal, sest järgmine pakendiuuendus kirjutab muudatuse üle ja ei jäta kavatsusest jälge. Seejärel rakendage see uuesti laadimise ja taaskäivitamise protseduuriga, mida soketiüksus ootab.

systemd socketi viide dokumenteerib selle valiku taga olevat IPv4 ja IPv6 käitumist ning oluline üksikasja on, et see kehtib sidumise, mitte marsruutimise kohta. Miski selles ei määra aadressi ega käivita VPN-i. FreeBind on kuulajale antud luba, mitte liidese asendaja.

After= ja Wants=: järjestus ei ole valmisolek

Järjestus ja nõue on eraldi teljed ning nende segamine tekitab üksusi, mis algavad õiges järjekorras ja nurjuvad ikkagi. After=vpn-client.service tähendab ainult, et kui mõlemad tööd käivitatakse, ootab see teise käivitumist. See ei tõmba VPN-i sisse ega oota, kuni VPN ühendumise lõpetab.

Nõudedirektiivid nagu Wants= ja Requires= tegelevad aktiveerimisega ja erinevad selle poolest, mis juhtub, kui sõltuvus nurjub: üks jätkab, teine peatub. Kumbki ei tea, mida tähendab ühendatud tunnel. VPN-protsess võib olla aktiivne ilma määratud aadressita või määratud aadressiga ja ilma marsruudita partnerini, ja mõlemad olekud rahuldavad sõltuvuse. Kui rakendus vajab, et aadress oleks olemas, modelleerige see tingimus selgesõnaliselt, selle asemel et pidada protsessi käivitumist valmisoleku tõestuseks.

Kontrollige, mida üksus tegelikult deklareerib, käskudega systemctl cat ja systemctl show -p After -p Wants -p Requires. Drop-in-failid kolmest erinevast kataloogist võivad lisada direktiive, mida te kunagi ei kirjutanud, ja systemd loeb ainult tegelikku üksust.

Mida network-online.target ei tee

Üksus, mis on järjestatud pärast network-online.target, ootab, kuni võrguhaldur kuulutab võrgu kasutatavaks, mis on alglaadimise sünkroniseerimispunkt, mitte pidev tingimus. See ei ütle midagi selle kohta, kas konkreetne tunnel on üleval, ja ei käivitu uuesti, kui VPN pärastlõunal uuesti ühendub. Selle pidamine taasühendumise monitoriks on kõige levinum selle sihtmärgi vale lugemine.

systemd projekt dokumenteerib selle erinevuse otse ja praktiline tagajärg on, et kõik, mis vajab tunneli aadressi, peab sõltuvust ise omama. Üksus, mis ootab network-online'i ja seejärel seob tunneli aadressi, on õige ainult siis, kui tunnel juhtub esimesena üles tulema, ja see on kokkusattumus, mitte disain.

Katsetage elutsüklit, mille te tegelikult valisite

Katsetage puhast alglaadimist, päringut pärast aadressi ilmumist ja käitumist pärast seda, kui VPN kukub ja naaseb. Need kolm juhtumit eristavad töötavat kuulajat töötavast teenusest.

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

Esimene käsk püüab üksusefaili vead enne taaskäivitust, teine näitab ühendatud üksust ja kolmas tõestab, kas kuulaja on olemas ja millisel aadressil. Kuulaja metamärgiga aadressil seal, kus ootasite tunneli aadressi, on täpselt see jääk, mille tühi ListenStream pidi eemaldama. Korrake kolmandat käsku pärast VPN-i taasühendumist, et näha, kas aadress liikus.

Valige elutsükkel teadlikult: kas vabalt seotud kuulaja, mis ootab stabiilse aadressi naasmist, või teenus, mis peatub koos tunneliga ja käivitub taastumisel uuesti. Need on erinevad disainid ja need nurjuvad erineval moel. Seejärel hoidke juurdepääsupoliitika seotud nende allikate ja radadega, mida kavatsesite, sest sihtaadressi sidumine ei nõua, et vastuvõetud paketid saabusid usaldusväärse liidese kaudu.