FreeBind kundrejt After=: lidhja e një socket systemd me një adresë VPN

Gjatë nisjes, një njësi socket që lidh një adresë fikse VPN mund të dështojë përpara se tuneli ta ketë caktuar atë, dhe shërbimi pas saj nuk niset kurrë. Dy çelësa duken si rregullime dhe zgjidhin gjysma të ndryshme të atij problemi. FreeBind i lejon systemd të krijojë dëgjuesin ndërsa adresa mungon ende. After= vetëm rendit detyrat, pra ndryshon se kur nisin gjërat pa e bërë adresën të arrijë më herët.

Dy probleme të ndryshme, dy çelësa të ndryshëm

Problemi i parë është një dështim lidhjeje: kerneli refuzon të dëgjojë në një adresë që hosti nuk e zotëron, kështu që njësia socket dështon menjëherë dhe shërbimi nuk aktivizohet kurrë. Problemi i dytë është një dështim gatishmërie: adresa ekziston në fund, por diçka përpiqet ta përdorë përpara se tuneli të transportojë trafik. FreeBind trajton të parin dhe nuk bën asgjë për të dytin. Direktivat e rendit nuk trajtojnë asnjërin drejtpërdrejt, sepse ato vetëm vendosin çfarë niset dhe në çfarë sekuence. Të emërtosh dështimin që ke në të vërtetë është e gjithë vendimi.

Konfirmoni cilin nga të dy e keni nga regjistri, jo nga përshkrimi i shërbimit. Një dështim lidhjeje emërton një adresë dhe raporton se nuk mund të caktohet. Një dështim gatishmërie zakonisht shfaqet më vonë, si skadim kohe ose lidhje e refuzuar e parë nga ana tjetër, me një njësi socket krejt të shëndoshë në regjistra.

FreeBind: dëgjuesi ekziston përpara adresës

FreeBind i thotë kernelit të lejojë një lidhje me një adresë jo-lokale, kështu që systemd mund të krijojë socketin e dëgjimit gjatë nisjes dhe t'ia dorëzojë aplikacionit sa herë që aplikacioni niset. Ky është qëllimi i aktivizimit me socket, dhe arsyeja pse socketi mund t'i mbijetojë shërbimit pas tij.

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

Caktimi bosh fshin zërat e dëgjimit të trashëguar nga njësia e furnizuesit përpara se të shtohet ai i ri, gjë që pengon një dëgjues wildcard të mbetur të përgjigjet në çdo ndërfaqe. Zëvendësoni adresën dhe portin me tuajat dhe verifikoni njësinë efektive, jo vetëm skedarin drop-in. Përdorni një drop-in nën emrin e njësisë në vend që të redaktoni një skedar pakete në vend, sepse përditësimi i ardhshëm i paketës do ta mbishkruajë redaktimin dhe nuk do të lërë asnjë gjurmë të qëllimit. Më pas aplikojeni përmes procedurës së rimbushjes dhe rinisjes që pret njësia socket.

Referenca e socketëve të systemd dokumenton sjelljen IPv4 dhe IPv6 pas këtij opsioni, dhe detaji i rëndësishëm është se zbatohet për lidhjen dhe jo për drejtimin e rrugës. Asgjë në të nuk cakton një adresë ose nuk nis një VPN. FreeBind është një leje që i jepet dëgjuesit, jo një zëvendësim i ndërfaqes.

After= dhe Wants=: rendi nuk është gatishmëri

Rendi dhe kërkesa janë akse të ndara, dhe ngatërrimi i tyre prodhon njësi që nisin në rendin e duhur dhe gjithsesi dështojnë. After=vpn-client.service do të thotë vetëm se, nëse të dy punët nisin, kjo pret që tjetra të niset. Nuk e tërheq VPN-në dhe nuk pret që VPN-ja të përfundojë lidhjen.

Direktivat e kërkesës si Wants= dhe Requires= merren me aktivizimin dhe ndryshojnë në atë që ndodh kur varësia dështon: njëra vazhdon dhe tjetra ndalon. Asnjëra nuk e di se çfarë do të thotë një tunel i lidhur. Një proces VPN mund të jetë aktiv pa adresë të caktuar, ose me adresë të caktuar dhe pa rrugë drejt homologut, dhe të dyja gjendjet e plotësojnë varësinë. Nëse aplikacioni ka nevojë që adresa të ekzistojë, modelojeni atë kusht në mënyrë të qartë në vend që ta trajtoni nisjen e procesit si provë gatishmërie.

Kontrolloni çfarë deklaron në të vërtetë njësia me systemctl cat dhe systemctl show -p After -p Wants -p Requires. Drop-in nga tre drejtori të ndryshme mund të shtojnë direktiva që nuk i keni shkruar kurrë, dhe systemd lexon vetëm njësinë efektive.

Çfarë nuk bën network-online.target

Një njësi e renditur pas network-online.target pret që menaxheri i rrjetit të deklarojë rrjetin si të përdorshëm, gjë që është pikë sinkronizimi gjatë nisjes dhe jo kusht i vazhdueshëm. Nuk thotë asgjë nëse një tunel i caktuar është lart, dhe nuk aktivizohet përsëri kur një VPN rilidhet në mes të pasdites. Trajtimi i tij si monitor rilidhjeje është lexomi i gabuar më i zakonshëm i atij objektivi.

Projekti systemd e dokumenton drejtpërdrejt atë dallim, dhe pasoja praktike është se çdo gjë që ka nevojë për një adresë tuneli duhet ta zotërojë vetë varësinë. Një njësi që pret network-online dhe më pas lidh një adresë tuneli është e saktë vetëm kur tuneli ngrihet i pari rastësisht, dhe kjo është rastësi dhe jo projektim.

Provoni ciklin e jetës që keni zgjedhur në të vërtetë

Provoni një nisje të pastër, një kërkesë pasi shfaqet adresa dhe sjelljen pasi VPN-ja bie dhe kthehet. Këto tre raste ndajnë një dëgjues funksional nga një shërbim funksional.

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

Komanda e parë kap gabimet e skedarit të njësisë përpara një rinisjeje, e dyta tregon njësinë e bashkuar dhe e treta vërteton nëse dëgjuesi ekziston dhe në cilën adresë. Një dëgjues në një adresë wildcard aty ku prisnit një adresë tuneli është pikërisht mbetja që ListenStream bosh duhej të hiqte. Përsëritni komandën e tretë pas një rilidhjeje të VPN-së për të parë nëse adresa u zhvendos.

Zgjidhni ciklin e jetës me qëllim: ose një dëgjues i lidhur lirshëm që pret kthimin e një adrese të qëndrueshme, ose një shërbim që ndalon me tunelin dhe niset përsëri gjatë rikuperimit. Këto janë projektime të ndryshme dhe dështojnë në mënyra të ndryshme. Më pas mbani politikën e aksesit të lidhur me burimet dhe shtigjet që kishit ndërmend, sepse lidhja e një adrese destinacioni nuk kërkon që paketat e pranuara të kenë ardhur përmes një ndërfaqeje të besuar.