FreeBind enfront d’After=: lligar un sòcol de systemd a una adreça VPN

En arrencar, una unitat de sòcol que lliga una adreça VPN fixa pot fallar abans que el túnel l’hi hagi assignat, i el servei que hi ha al darrere no s’inicia mai. Dos commutadors semblen solucions i resolen meitats diferents d’aquest problema. FreeBind permet que systemd creï l’oïdor mentre l’adreça encara és absent. After= només ordena tasques, així que canvia quan comencen les coses sense fer que l’adreça arribi abans.

Dos problemes diferents, dos commutadors diferents

El primer problema és un error de lligam: el nucli rebutja una escolta en una adreça que l’amfitrió no posseeix, així que la unitat de sòcol falla immediatament i el servei no s’activa mai. El segon problema és un error de disponibilitat: l’adreça existeix finalment, però alguna cosa intenta fer-la servir abans que el túnel transporti trànsit. FreeBind resol el primer i no fa res pel segon. Les directrius d’ordre no resolen cap dels dos directament, perquè només decideixen què s’inicia i en quina seqüència. Anomenar l’error que realment teniu és tota la decisió.

Confirmeu quin dels dos teniu al registre, no a la descripció del servei. Un error de lligam anomena una adreça i informa que no es pot assignar. Un error de disponibilitat sol aparèixer més tard, com un temps d’espera esgotat o una connexió rebutjada vista des de l’altre costat, amb una unitat de sòcol perfectament sana als registres.

FreeBind: l’oïdor existeix abans que l’adreça

FreeBind diu al nucli que permeti un lligam a una adreça no local, de manera que systemd pot crear el sòcol d’escolta en arrencar i lliurar-lo a l’aplicació sempre que aquesta s’iniciï. Aquest és el sentit de l’activació per sòcol i la raó per la qual el sòcol pot sobreviure al servei que hi ha al darrere.

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

L’assignació buida esborra les entrades d’escolta heretades de la unitat del proveïdor abans que s’afegeixi la nova, cosa que evita que un oïdor wildcard romanent respongui a totes les interfícies. Substituïu l’adreça i el port pels vostres i verifiqueu la unitat efectiva, no només el fitxer drop-in. Feu servir un drop-in amb el nom de la unitat en lloc d’editar un fitxer del paquet al lloc, perquè la propera actualització del paquet sobreescriurà l’edició i no deixarà cap rastre de la intenció. Després apliqueu-lo amb el procediment de recàrrega i reinici que la unitat de sòcol espera.

La referència de sòcols de systemd documenta el comportament IPv4 i IPv6 darrere d’aquesta opció, i el detall important és que s’aplica al lligam i no a l’encaminament. Res no hi assigna una adreça ni inicia una VPN. FreeBind és un permís concedit a l’oïdor, no un substitut de la interfície.

After= i Wants=: l’ordre no és disponibilitat

Ordre i requeriment són eixos separats, i confondre’ls produeix unitats que s’inicien en l’ordre correcte i tot i així fallen. After=vpn-client.service només vol dir que, si tots dos treballs s’inicien, aquest espera que l’altre s’hagi iniciat. No arrossega la VPN ni espera que la VPN acabi de connectar.

Les directrius de requeriment com Wants= i Requires= gestionen l’activació i difereixen en què passa quan la dependència falla: una continua, l’altra s’atura. Cap de les dues sap què significa un túnel connectat. Un procés VPN pot estar actiu sense cap adreça assignada, o amb una adreça assignada i sense ruta fins a l’igual, i tots dos estats satisfan la dependència. Si l’aplicació necessita que l’adreça existeixi, modela aquesta condició explícitament en lloc de tractar l’inici del procés com a prova de disponibilitat.

Comproveu què declara realment la unitat amb systemctl cat i systemctl show -p After -p Wants -p Requires. Els drop-in de tres directoris diferents poden afegir directrius que no vau escriure mai, i la unitat efectiva és l’única cosa que systemd llegeix.

Què no fa network-online.target

Una unitat ordenada després de network-online.target espera que el gestor de xarxa declari la xarxa utilitzable, cosa que és un punt de sincronització d’arrencada i no una condició contínua. No diu res sobre si un túnel concret està aixecat, i no tornarà a disparar-se quan una VPN es reconnecti a mitja tarda. Tractar-lo com un monitor de reconnexió és la mala lectura més habitual d’aquest objectiu.

El projecte systemd documenta aquesta distinció directament, i la conseqüència pràctica és que qualsevol cosa que necessiti una adreça de túnel ha de posseir la dependència per si mateixa. Una unitat que espera network-online i després lliga una adreça de túnel només és correcta quan el túnel s’aixeca primer per casualitat, cosa que és una coincidència i no un disseny.

Proveu el cicle de vida que heu triat realment

Proveu una arrencada neta, una petició després que aparegui l’adreça i el comportament després que la VPN caigui i torni. Aquests tres casos separen un oïdor funcional d’un servei funcional.

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

La primera ordre detecta errors del fitxer d’unitat abans d’un reinici, la segona mostra la unitat fusionada i la tercera demostra si l’oïdor existeix i en quina adreça. Un oïdor en una adreça wildcard on esperàveu una adreça de túnel és exactament la resta que el ListenStream buit havia d’eliminar. Repetiu la tercera ordre després d’una reconnexió de la VPN per veure si l’adreça s’ha mogut.

Trieu el cicle de vida deliberadament: o un oïdor lligat lliurement que espera el retorn d’una adreça estable, o un servei que s’atura amb el túnel i torna a iniciar-se en recuperar-se. Són dissenys diferents i fallen de maneres diferents. Després manteniu la política d’accés lligada a les fonts i els camins que volíeu, perquè lligar una adreça de destinació no exigeix que els paquets acceptats hagin arribat per una interfície de confiança.