FreeBind gegn After=: að binda systemd-socket við VPN-tölu

Við ræsingu getur socket-eining sem bindur fasta VPN-tölu mistekist áður en göngin úthluta henni, og þjónustan fyrir aftan byrjar aldrei. Tveir rofar líta út eins og lagfæringar og leysa mismunandi helminga þess vandamáls. FreeBind leyfir systemd að búa til hlustandann meðan talan vantar enn. After= raðar aðeins verkum, svo það breytir því hvenær hlutir byrja án þess að talan komi fyrr.

Tvö mismunandi vandamál, tveir mismunandi rofar

Fyrsta vandamálið er bindingarmistök: kjarninn neitar að hlusta á tölu sem hýsilinn á ekki, svo socket-einingin mistekst samstundis og þjónustan er aldrei virkjuð. Annað vandamálið er reiðubúnaðarmistök: talan er loks til, en eitthvað reynir að nota hana áður en göngin flytja umferð. FreeBind tekur á því fyrra og gerir ekkert fyrir það síðara. Röðunarfyrirmælin taka ekki á hvorugu beint, því þau ákveða aðeins hvað byrjar í hvaða röð. Að nefna mistökin sem þú hefur í raun er öll ákvörðunin.

Staðfestu hvort tveggja þú hefur í annálnum, ekki í lýsingunni á þjónustunni. Bindingarmistök nefna tölu og tilkynna að ekki sé hægt að úthluta henni. Reiðubúnaðarmistök birtast venjulega síðar, sem tímaútrun eða hafnað tenging séð frá hinum endanum, með fullkomlega heilbrigða socket-einingu í annálnum.

FreeBind: hlustandinn er til áður en talan

FreeBind segir kjarnanum að leyfa bindingu við ekki-staðbundna tölu, svo systemd getur búið til hlustandi socket við ræsingu og afhent forritinu hvenær sem forritið byrjar. Það er tilgangur socket-virkjunar og ástæðan fyrir því að socket getur lifað lengur en þjónustan fyrir aftan.

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

Tóma úthlutunin hreinsar hlustunarskrár sem erfast frá einingu birgjans áður en nýja er bætt við, sem kemur í veg fyrir að afgangs wildcard-hlustandi svari á öllum tengi. Skiptið út tölunni og portinu fyrir þín eigin og sannreynið virku eininguna, ekki aðeins drop-in skrána. Notið drop-in undir nafni einingarinnar í stað þess að breyta pakkaskrá á staðnum, því næsta pakkauppfærsla yfirskrifar breytinguna og skilur engin merki eftir um áformið. Beitið því síðan með endurhleðslu- og endurræsingarferlinu sem socket-einingin býst við.

systemd socket-viðmiðið skjalfestir IPv4- og IPv6-hegðunina bak við valkostinn, og mikilvæga smáatriðið er að hann á við bindingu en ekki leiðsögn. Ekkert í því úthlutar tölu eða ræsir VPN. FreeBind er leyfi sem hlustandanum er veitt, ekki staðgengill fyrir tengið.

After= og Wants=: röð er ekki reiðubúnaður

Röð og krafa eru aðskildir ásar, og að rugla þeim framleiðir einingar sem byrja í réttri röð og mistekst samt. After=vpn-client.service þýðir aðeins að ef bæði verkin eru ræst bíður þessi eftir að hitt sé ræst. Það dregur VPN ekki inn og bíður ekki eftir að VPN ljúki tengingu.

Kröfufyrirmæli eins og Wants= og Requires= sjá um virkjun og eru ólík í því hvað gerist þegar fyrirhafnarskiðningin mistekst: önnur heldur áfram og hin stöðvast. Hvorug veit hvað tengd göng þýða. VPN-ferli getur verið virkt án úthlutaðrar tölu, eða með úthlutaðri tölu og án leiðar að mótaðilanum, og bæði ástand uppfylla skilyrðið. Ef forritið þarf að talan sé til, mótaðu það skilyrði skýrt í stað þess að líta á ræsingu ferlisins sem sönnun reiðubúnaðar.

Athugið hvað einingin lýsir í raun með systemctl cat og systemctl show -p After -p Wants -p Requires. Drop-in úr þremur mismunandi möppum geta bætt við fyrirmælum sem þú skrifaðir aldrei, og systemd les aðeins virku eininguna.

Hvað network-online.target gerir ekki

Eining sem er röðuð eftir network-online.target bíður eftir að netstjórinn lýsi netið nothæft, sem er samstillingarpunktur við ræsingu en ekki viðvarandi skilyrði. Hún segir ekkert um hvort tiltekin göng séu uppi og kviknar ekki aftur þegar VPN tengist aftur síðdegis. Að líta á hana sem eftirlit með endurtengingu er algengasta rangtúlkun þessa marks.

systemd-verkefnið skjalfestir þann mun beint, og hagnýta afleiðingin er að allt sem þarf göngutölu verður sjálft að eiga skilyrðið. Eining sem bíður network-online og bindur síðan göngutölu er aðeins rétt þegar göngin fara tilviljunarkennt fyrst upp, og það er tilviljun en ekki hönnun.

Prófið lífsferilinn sem þið völduð í raun

Prófið hreina ræsingu, beiðni eftir að talan birtist og hegðunina eftir að VPN dettur og kemur aftur. Þessi þrjú tilvik aðskilja virkan hlustanda frá virkri þjónustu.

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

Fyrsta skipunin grípur villur í einingarskránni fyrir endurræsingu, önnur sýnir sameinuðu eininguna og þriðja sannar hvort hlustandinn er til og á hvaða tölu. Hlustandi á wildcard-tölu þar sem þú bjóst við göngutölu er einmitt afgangurinn sem tóma ListenStream átti að fjarlægja. Endurtakið þriðju skipunina eftir endurtengingu VPN til að sjá hvort talan færðist.

Veljið lífsferilinn af ásettu ráði: annaðhvort frjálst bundinn hlustanda sem bíður þess að stöðug tala komi aftur, eða þjónustu sem stöðvast með göngunum og byrjar aftur við endurheimt. Þetta eru mismunandi hönnun og þær mistekst á mismunandi vegu. Haldið síðan aðgangsstefnunni bundinni við upptök og slóðir sem þið ætluðuð, því binding ákvörðunartölu krefst þess ekki að samþykkt pakkar hafi komið um treyst tengi.