FreeBind dhidi ya After=: kufunga socket ya systemd kwenye anwani ya VPN

Wakati wa kuwasha, kitengo cha socket kinachofunga anwani isiyobadilika ya VPN kinaweza kushindwa kabla handaki haijaitoa, na huduma iliyo nyuma yake haianzi kamwe. Swichi mbili zinaonekana kama marekebisho na hutatua nusu tofauti za tatizo hilo. FreeBind humruhusu systemd kuunda msikilizaji wakati anwani bado haipo. After= hupanga kazi tu, kwa hiyo hubadilisha wakati mambo yanaanza bila kufanya anwani ifike mapema.

Matatizo mawili tofauti, swichi mbili tofauti

Tatizo la kwanza ni kushindwa kwa ufungaji: kerneli hukataa kusikiliza kwenye anwani ambayo mwenyeji hana, kwa hiyo kitengo cha socket hushindwa mara moja na huduma haiwashwi kamwe. Tatizo la pili ni kushindwa kwa utayari: anwani ipo mwishowe, lakini kitu kinajaribu kuitumia kabla handaki halijabeba trafiki. FreeBind hushughulikia la kwanza na haifanyi chochote kwa la pili. Maagizo ya mpangilio hayashughulikii yote moja kwa moja, kwa sababu huamua tu nini kinaanza kwa mpangilio gani. Kutaja kushindwa ulicho nacho kwa kweli ndio uamuzi wote.

Thibitisha ni kipi kati ya mawili ulicho nacho kutoka kwenye jarida, si kutoka kwenye maelezo ya huduma. Kushindwa kwa ufungaji hutaja anwani na kuripoti kwamba haiwezi kutolewa. Kushindwa kwa utayari kwa kawaida huonekana baadaye, kama muda kuisha au muunganisho uliokataliwa unaoonekana kutoka upande wa pili, wakati kumbukumbu zina kitengo cha socket chenye afya kamili.

FreeBind: msikilizaji yupo kabla ya anwani

FreeBind huambia kerneli kuruhusu ufungaji kwenye anwani isiyo ya ndani, ili systemd aweze kuunda socket inayosikiliza wakati wa kuwasha na kuipatia programu kila programu inapoanza. Hiyo ndiyo maana ya uanzishaji wa socket, na sababu socket inaweza kuishi zaidi ya huduma iliyo nyuma yake.

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

Ugawaji tupu hufuta maingizo ya kusikiliza yaliyorithiwa kutoka kitengo cha msambazaji kabla ya kuongeza mapya, jambo ambalo huzuia msikilizaji wildcard aliyebaki kujibu kwenye kila kiolesura. Badilisha anwani na bandari kwa zako na uthibitishe kitengo kinachofanya kazi, si faili ya drop-in pekee. Tumia drop-in chini ya jina la kitengo badala ya kuhariri faili ya kifurushi mahali pake, kwa sababu sasisho la kifurushi lijalo litafuta uhariri na haliache alama yoyote ya nia. Kisha itumie kupitia utaratibu wa kupakia upya na kuwasha upya ambao kitengo cha socket unatarajia.

Marejeleo ya socket ya systemd huandika tabia ya IPv4 na IPv6 nyuma ya chaguo hili, na maelezo muhimu ni kwamba yanahusu ufungaji na si uelekezaji. Hakuna chochote ndani yake kinachotoa anwani au kuanzisha VPN. FreeBind ni ruhusa inayotolewa kwa msikilizaji, si badala ya kiolesura.

After= na Wants=: mpangilio si utayari

Mpangilio na sharti ni mihimili tofauti, na kuzichanganya huzalisha vitengo vinavyoanza kwa mpangilio sahihi na bado hushindwa. After=vpn-client.service inamaanisha tu kwamba kama kazi zote mbili zinaanzishwa, hii inasubiri nyingine ianzishwe. Haivuti VPN na haisubiri VPN imalize kuunganisha.

Maagizo ya sharti kama Wants= na Requires= hushughulikia uanzishaji, na hutofautiana katika kile kinachotokea tegemezi linaposhindwa: moja linaendelea na lingine linasimama. Hakuna hata moja linalojua maana ya handaki iliyounganishwa. Mchakato wa VPN unaweza kuwa hai bila anwani iliyotolewa, au ukiwa na anwani iliyotolewa na bila njia kwa mwenzake, na hali zote mbili zinatosheleza tegemezi. Ikiwa programu inahitaji anwani iwepo, fanya modeli ya sharti hilo kwa uwazi badala ya kuchukua kuanza kwa mchakato kama uthibitisho wa utayari.

Angalia kile kitengo kinachotangaza kwa kweli kwa systemctl cat na systemctl show -p After -p Wants -p Requires. Drop-in kutoka saraka tatu tofauti zinaweza kuongeza maagizo ambayo hukuwahi kuandika, na systemd husoma kitengo kinachofanya kazi pekee.

Kile network-online.target haifanyi

Kitengo kilichopangwa baada ya network-online.target husubiri meneja wa mtandao atangaze mtandao kuwa unaweza kutumika, ambayo ni sehemu ya usawazishaji wakati wa kuwasha na si sharti la kudumu. Haisemi chochote kuhusu kama handaki fulani iko juu, na haitawaka tena VPN inapounganishwa tena katikati ya mchana. Kuichukulia kama kifuatiliaji cha kuunganisha tena ni usomaji mbaya unaojulikana zaidi wa lengo hilo.

Mradi wa systemd huandika tofauti hiyo moja kwa moja, na tokeo la kiutendaji ni kwamba kitu chochote kinachohitaji anwani ya handaki lazima kimiliki tegemezi lenyewe. Kitengo kinachosubiri network-online kisha kufunga anwani ya handaki ni sahihi tu wakati handaki linatokea kwanza juu kwa bahati, na hiyo ni bahati na si ubunifu.

Jaribu mzunguko wa maisha uliouona kweli

Jaribu kuwasha safi, ombi baada ya anwani kuonekana, na tabia baada ya VPN kuanguka na kurudi. Hali hizo tatu hutenganisha msikilizaji anayefanya kazi na huduma inayofanya kazi.

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

Amri ya kwanza hunasa makosa ya faili ya kitengo kabla ya kuwasha upya, ya pili huonyesha kitengo kilichounganishwa, na ya tatu huthibitisha kama msikilizaji yupo na kwenye anwani gani. Msikilizaji kwenye anwani ya wildcard mahali ulipotarajia anwani ya handaki ni mabaki hasa ambayo ListenStream tupu ilipaswa kuondoa. Rudia amri ya tatu baada ya VPN kuunganishwa tena ili kuona kama anwani imehamia.

Chagua mzunguko wa maisha kwa makusudi: ama msikilizaji aliyefungwa kwa uhuru anayesubiri anwani thabiti irudi, au huduma inayosimama na handaki na kuanza tena wakati wa kupona. Hizi ni miundo tofauti na hushindwa kwa njia tofauti. Kisha shikilia sera ya ufikiaji ikiwa imefungwa kwa vyanzo na njia ulizokusudia, kwa sababu kufunga anwani ya lengwa hakuhitaji kwamba pakiti zilizokubaliwa zimefika kupitia kiolesura kinachoaminika.