FreeBind kontraŭ After=: ligi systemd-soketon al VPN-adreso

Ĉe lanĉo, soket-unuo kiu ligas fiksan VPN-adreson povas malsukcesi antaŭ ol la tunelo atribuis ĝin, kaj la servo malantaŭ ĝi neniam ekfunkcias. Du ŝaltiloj aspektas kiel solvoj kaj solvas malsamajn duonojn de tiu problemo. FreeBind lasas al systemd krei la aŭskultanton dum la adreso ankoraŭ mankas. After= nur ordigas taskojn, do ĝi ŝanĝas kiam aferoj komenciĝas sen igi la adreson alveni pli frue.

Du malsamaj problemoj, du malsamaj ŝaltiloj

La unua problemo estas liga malsukceso: la kerno rifuzas aŭskultadon sur adreso kiun la gastiganto ne posedas, do la soket-unuo tuj malsukcesas kaj la servo neniam aktiviĝas. La dua problemo estas preteca malsukceso: la adreso fine ekzistas, sed io provas uzi ĝin antaŭ ol la tunelo portas trafikon. FreeBind traktas la unuan kaj faras nenion pri la dua. Ordigaj direktivoj traktas nek unu rekte, ĉar ili nur decidas kio komenciĝas en kiu sinsekvo. Nomigi la malsukceson kiun vi vere havas estas la tuta decido.

Konfirmu kiun el la du vi havas el la ĵurnalo, ne el la priskribo de la servo. Liga malsukceso nomas adreson kaj raportas ke ĝi ne povas esti atribuata. Preteca malsukceso kutime aperas poste, kiel tempolimo aŭ rifuzita konekto vidata de la alia flanko, kun tute sana soket-unuo en la protokoloj.

FreeBind: la aŭskultanto ekzistas antaŭ la adreso

FreeBind diras al la kerno permesi ligon al neloka adreso, por ke systemd povu krei la aŭskultantan soketon ĉe lanĉo kaj transdoni ĝin al la aplikaĵo kiam ajn la aplikaĵo komenciĝas. Tio estas la senco de soketa aktivigo kaj la kialo kial la soketo povas postvivi la servon malantaŭ ĝi.

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

La malplena atribuo forigas la aŭskultajn enskribojn hereditajn de la vendista unuo antaŭ ol aldoni la novan, kio malhelpas restintan sovaĝkartan aŭskultanton respondi sur ĉiu interfaco. Anstataŭigu la adreson kaj la pordon per viaj propraj kaj kontrolu la efektivan union, ne nur la drop-in-dosieron. Uzu drop-in sub la nomo de la unuo anstataŭ redakti pakaĵan dosieron surloke, ĉar la sekva pakaĵa ĝisdatigo anstataŭigos la redakton kaj ne lasos spuron de la intenco. Poste apliku ĝin per la reŝarga kaj restartiga proceduro kiun la soket-unuo atendas.

La systemd-soketa referenco dokumentas la konduton IPv4 kaj IPv6 malantaŭ tiu opcio, kaj la grava detalo estas ke ĝi rilatas al la ligo, ne al la enkursigo. Nenio en ĝi atribuas adreson aŭ lanĉas VPN. FreeBind estas permeso donita al la aŭskultanto, ne anstataŭo por la interfaco.

After= kaj Wants=: ordo ne estas preteco

Ordo kaj postulo estas apartaj aksoj, kaj konfuzi ilin produktas unuojn kiuj komenciĝas en la ĝusta ordo kaj tamen malsukcesas. After=vpn-client.service signifas nur ke, se ambaŭ taskoj komenciĝas, ĉi tiu atendas ke la alia komenciĝu. Ĝi ne tiras la VPN-on kaj ne atendas ke la VPN finu konektiĝi.

Postulaj direktivoj kiel Wants= kaj Requires= okupiĝas pri aktivigo kaj malsamas en tio kio okazas kiam la dependeco malsukcesas: unu daŭrigas, la alia haltas. Neniu el ili scias kion signifas konektita tunelo. VPN-proceso povas esti aktiva sen atribuita adreso, aŭ kun atribuita adreso kaj sen itinero al la partnero, kaj ambaŭ statoj kontentigas la dependecon. Se la aplikaĵo bezonas ke la adreso ekzistu, modelu tiun kondiĉon eksplicite anstataŭ trakti procesan lanĉon kiel pruvon de preteco.

Kontrolu kion la unuo efektive deklaras per systemctl cat kaj systemctl show -p After -p Wants -p Requires. Drop-in el tri malsamaj dosierujoj povas aldoni direktivojn kiujn vi neniam skribis, kaj systemd legas nur la efektivan union.

Kion network-online.target ne faras

Unuo ordigita post network-online.target atendas ke la retadministranto deklaru la reton uzebla, kio estas sinkroniga punkto ĉe lanĉo kaj ne daŭra kondiĉo. Ĝi diras nenion pri tio ĉu specifa tunelo estas supre, kaj ĝi ne ree ekfunkcios kiam VPN rekonektiĝos meze de posttagmezo. Trakti ĝin kiel rekonektan monitoron estas la plej ofta mislegado de tiu celo.

La systemd-projekto dokumentas tiun distingon rekte, kaj la praktika sekvo estas ke ĉio bezonanta tunelan adreson devas mem posedi la dependecon. Unuo kiu atendas network-online kaj poste ligas tunelan adreson estas ĝusta nur kiam la tunelo hazarde supreniĝas unue, kio estas hazardo kaj ne dezajno.

Testu la vivciklon kiun vi vere elektis

Testu puran lanĉon, peton post kiam la adreso aperas, kaj la konduton post kiam la VPN falas kaj revenas. Tiuj tri kazoj apartigas funkciantan aŭskultanton de funkcianta servo.

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

La unua komando kaptas erarojn de la unuodosiero antaŭ restartigo, la dua montras la kunfanditan union, kaj la tria pruvas ĉu la aŭskultanto ekzistas kaj sur kiu adreso. Aŭskultanto sur sovaĝkarta adreso tie kie vi atendis tunelan adreson estas ĝuste la restaĵo kiun la malplena ListenStream devis forigi. Ripetu la trian komandon post VPN-rekonekto por vidi ĉu la adreso moviĝis.

Elektu la vivciklon konscie: aŭ libere ligitan aŭskultanton kiu atendas la revenon de stabila adreso, aŭ servon kiu haltas kun la tunelo kaj rekomenciĝas ĉe resaniĝo. Tiuj estas malsamaj dezajnoj kaj ili malsukcesas laŭ malsamaj manieroj. Poste tenu la alirpolitikon ligita al la fontoj kaj vojoj kiujn vi intencis, ĉar ligado de cela adreso ne postulas ke akceptitaj pakaĵoj alvenis tra fidinda interfaco.