FreeBind laban sa After=: pagbigkis ng socket ng systemd sa address ng VPN

Sa pag-boot, ang unit ng socket na nagbibigkis ng nakapirming address ng VPN ay maaaring mabigo bago pa ito italaga ng tunnel, at ang serbisyo sa likod nito ay hindi kailanman nagsisimula. Dalawang switch ang mukhang pag-aayos at nilulutas ang magkaibang kalahati ng problemang iyon. Pinapayagan ng FreeBind ang systemd na gawin ang tagapakinig habang wala pa ang address. Ang After= ay nag-aayos lamang ng mga gawain, kaya binabago nito kung kailan nagsisimula ang mga bagay nang hindi pinapaaga ang pagdating ng address.

Dalawang magkaibang problema, dalawang magkaibang switch

Ang unang problema ay pagkabigo sa pagbigkis: tinatanggihan ng kernel ang pakikinig sa address na hindi pag-aari ng host, kaya agad na nabigo ang unit ng socket at hindi kailanman na-activate ang serbisyo. Ang ikalawang problema ay pagkabigo sa kahandaan: umiiral din ang address sa huli, ngunit may bagay na sumusubok na gamitin ito bago magdala ng trapiko ang tunnel. Tinutugunan ng FreeBind ang una at walang ginagawa para sa pangalawa. Hindi direktang tinutugunan ng mga direktiba sa pagkakasunod-sunod ang alinman, dahil nagpapasya lamang sila kung ano ang nagsisimula sa anong pagkakasunod-sunod. Ang pagpangalan sa pagkabigong talagang mayroon ka ay ang buong desisyon.

Tiyakin kung alin sa dalawa ang mayroon ka mula sa journal, hindi mula sa paglalarawan ng serbisyo. Ang pagkabigo sa pagbigkis ay nagsasabi ng address at nag-uulat na hindi ito maaaring italaga. Ang pagkabigo sa kahandaan ay karaniwang lumilitaw mamaya, bilang pag-timeout o tinanggihang koneksyon na nakita mula sa kabilang panig, habang may ganap na malusog na unit ng socket sa mga log.

FreeBind: umiiral ang tagapakinig bago ang address

Sinasabi ng FreeBind sa kernel na payagan ang pagbigkis sa isang address na hindi lokal, kaya makakagawa ang systemd ng socket na nakikinig sa pag-boot at maibibigay ito sa aplikasyon tuwing nagsisimula ang aplikasyon. Iyon ang layunin ng socket activation, at ang dahilan kung bakit ang socket ay maaaring mabuhay nang mas matagal kaysa sa serbisyo sa likod nito.

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

Binubura ng walang laman na pagtatalaga ang mga entry sa pakikinig na namana mula sa unit ng vendor bago idagdag ang bago, na pumipigil sa natirang wildcard na tagapakinig na sumagot sa bawat interface. Palitan ang address at port ng sarili mo at i-verify ang epektibong unit, hindi lamang ang drop-in na file. Gumamit ng drop-in sa ilalim ng pangalan ng unit sa halip na i-edit ang file ng package sa lugar nito, dahil oobertsirahan ng susunod na pag-update ng package ang edit at walang matitirang bakas ng intensyon. Pagkatapos ay ilapat ito sa pamamagitan ng pamamaraan ng reload at restart na inaasahan ng unit ng socket.

Ang sanggunian ng socket ng systemd ay nagdodokumento ng pag-uugali ng IPv4 at IPv6 sa likod ng opsyon na ito, at ang mahalagang detalye ay nalalapat ito sa pagbigkis at hindi sa routing. Walang anuman dito na nagtatalaga ng address o nagpapasimula ng VPN. Ang FreeBind ay pahintulot na ibinibigay sa tagapakinig, hindi kapalit ng interface.

After= at Wants=: ang pagkakasunod-sunod ay hindi kahandaan

Ang pagkakasunod-sunod at pangangailangan ay magkaibang mga aksis, at ang paghahalo sa kanila ay lumilikha ng mga unit na nagsisimula sa tamang pagkakasunod-sunod at nabibigo pa rin. Ang After=vpn-client.service ay nangangahulugan lamang na kung parehong gawain ay sinimulan, ito ay naghihintay na masimulan ang isa. Hindi nito hinihila ang VPN at hindi ito naghihintay na matapos ng VPN ang pagkonekta.

Ang mga direktiba ng pangangailangan tulad ng Wants= at Requires= ay humahawak ng activation, at nagkakaiba sila sa nangyayari kapag nabigo ang dependency: ang isa ay nagpapatuloy at ang isa ay humihinto. Wala sa kanila ang nakakaalam kung ano ang kahulugan ng konektadong tunnel. Ang proseso ng VPN ay maaaring aktibo nang walang itinalagang address, o may itinalagang address at walang ruta patungo sa kapares, at parehong estado ay tumutugon sa dependency. Kung kailangan ng aplikasyon na umiral ang address, imodelo ang kondisyong iyon nang tahasan sa halip na ituring ang pagsisimula ng proseso bilang patunay ng kahandaan.

Suriin kung ano talaga ang idinideklara ng unit gamit ang systemctl cat at systemctl show -p After -p Wants -p Requires. Ang mga drop-in mula sa tatlong magkaibang direktoryo ay maaaring magdagdag ng mga direktibang hindi mo kailanman isinulat, at ang epektibong unit lamang ang binabasa ng systemd.

Ano ang hindi ginagawa ng network-online.target

Ang unit na inayos pagkatapos ng network-online.target ay naghihintay na ideklara ng tagapamahala ng network na magagamit ang network, na isang punto ng pag-synchronize sa pag-boot at hindi isang tuloy-tuloy na kondisyon. Wala itong sinasabi tungkol sa kung nakaangat ang isang partikular na tunnel, at hindi ito muling magti-trigger kapag muling kumonekta ang VPN sa kalagitnaan ng hapon. Ang ituring ito bilang monitor ng muling pagkonekta ay ang pinakakaraniwang maling pagbasa ng target na iyon.

Direktang idinodokumento ng proyekto ng systemd ang pagkakaibang iyon, at ang praktikal na bunga ay ang anumang nangangailangan ng address ng tunnel ay dapat magmay-ari mismo ng dependency. Ang unit na naghihintay sa network-online at pagkatapos ay nagbibigkis ng address ng tunnel ay tama lamang kapag nagkataong nauna ang tunnel, at iyon ay pagkakataon at hindi disenyo.

Subukan ang lifecycle na talagang pinili mo

Subukan ang malinis na pag-boot, isang kahilingan pagkatapos lumitaw ang address, at ang pag-uugali pagkatapos bumagsak at bumalik ang VPN. Ang tatlong kaso ay naghihiwalay ng gumaganang tagapakinig mula sa gumaganang serbisyo.

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

Ang unang utos ay humuhuli ng mga error sa file ng unit bago ang restart, ang pangalawa ay nagpapakita ng pinagsamang unit, at ang pangatlo ay nagpapatunay kung umiiral ang tagapakinig at sa aling address. Ang tagapakinig sa isang wildcard na address kung saan inaasahan mo ang address ng tunnel ay eksaktong natira na dapat alisin ng walang laman na ListenStream. Ulitin ang pangatlong utos pagkatapos ng muling pagkonekta ng VPN upang makita kung gumalaw ang address.

Piliin ang lifecycle nang sadya: alinman sa isang malayang nakabigkis na tagapakinig na naghihintay ng pagbabalik ng matatag na address, o isang serbisyong humihinto kasama ng tunnel at nagsisimulang muli sa pagbawi. Ang mga ito ay magkaibang disenyo at nabibigo sila sa magkaibang paraan. Pagkatapos ay panatilihing nakatali ang patakaran sa pag-access sa mga pinagmulan at landas na nilayon mo, dahil ang pagbigkis ng address ng destinasyon ay hindi nangangailangan na ang mga tinanggap na packet ay dumating sa pamamagitan ng pinagkakatiwalaang interface.