FreeBind fronte a After=: ligar un socket de systemd a un enderezo VPN

Ao arrincar, unha unidade de socket que liga un enderezo VPN fixo pode fallar antes de que o túnel llo asignase, e o servizo que hai detrás nunca arrinca. Dous interruptores parecen solucións e resolven metades distintas dese problema. FreeBind permite que systemd cree o oínte mentres o enderezo aínda falta. After= só ordena tarefas, así que cambia cando comezan as cousas sen facer que o enderezo chegue antes.

Dous problemas distintos, dous interruptores distintos

O primeiro problema é un fallo de ligazón: o núcleo rexeita escoitar nun enderezo que o host non posúe, así que a unidade de socket falla de inmediato e o servizo nunca se activa. O segundo problema é un fallo de dispoñibilidade: o enderezo existe ao final, pero algo tenta usalo antes de que o túnel transporte tráfico. FreeBind aborda o primeiro e non fai nada polo segundo. As directivas de orde non abordan ningún directamente, porque só deciden que comeza e en que secuencia. Nomear o fallo que realmente ten é toda a decisión.

Confirme cal dos dous ten no rexistro, non na descrición do servizo. Un fallo de ligazón nomea un enderezo e informa de que non se pode asignar. Un fallo de dispoñibilidade adoita aparecer máis tarde, como un tempo de espera esgotado ou unha conexión rexeitada vista desde o outro lado, cunha unidade de socket perfectamente san nos rexistros.

FreeBind: o oínte existe antes que o enderezo

FreeBind indica ao núcleo que permita unha ligazón a un enderezo non local, de xeito que systemd pode crear o socket de escoita ao arrincar e entregalo á aplicación sempre que esta se inicie. Ese é o sentido da activación por socket e a razón pola que o socket pode sobrevivir ao servizo que hai detrás.

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

A asignación baleira borra as entradas de escoita herdadas da unidade do provedor antes de engadir a nova, o que evita que un oínte comodín sobrante responda en todas as interfaces. Substitúa o enderezo e o porto polos seus e verifique a unidade efectiva, non só o ficheiro drop-in. Use un drop-in co nome da unidade en lugar de editar un ficheiro do paquete no seu sitio, porque a seguinte actualización do paquete sobrescribirá a edición e non deixará rastro da intención. Despois aplíqueo mediante o procedemento de recarga e reinicio que a unidade de socket espera.

A referencia de sockets de systemd documenta o comportamento IPv4 e IPv6 detrás desa opción, e o detalle importante é que se aplica á ligazón e non ao encamiñamento. Nada nela asigna un enderezo nin inicia unha VPN. FreeBind é un permiso concedido ao oínte, non un substituto da interface.

After= e Wants=: a orde non é dispoñibilidade

Orde e requisito son eixos separados, e confundilos produce unidades que arrincan na orde correcta e aínda así fallan. After=vpn-client.service só significa que, se ambas as tarefas se inician, esta espera a que a outra se inicie. Non arrastra a VPN e non espera a que a VPN remate de conectarse.

As directivas de requisito como Wants= e Requires= xestionan a activación e difiren en que ocorre cando a dependencia falla: unha continúa e a outra detense. Ningunha das dúas sabe que significa un túnel conectado. Un proceso VPN pode estar activo sen enderezo asignado, ou con enderezo asignado e sen ruta cara ao par, e ambos os estados satisfán a dependencia. Se a aplicación necesita que o enderezo exista, modele esa condición de forma explícita en lugar de tratar o arrinque do proceso como proba de dispoñibilidade.

Comprobe que declara realmente a unidade con systemctl cat e systemctl show -p After -p Wants -p Requires. Os drop-in de tres directorios distintos poden engadir directivas que vostede nunca escribiu, e a unidade efectiva é o único que systemd le.

Que non fai network-online.target

Unha unidade ordenada despois de network-online.target espera a que o xestor de rede declare a rede utilizábel, o que é un punto de sincronización do arrinque e non unha condición continua. Non di nada sobre se un túnel concreto está activo, e non se disparará de novo cando unha VPN se reconecte a media tarde. Tratalo como un monitor de reconexión é a mala lectura máis común dese obxectivo.

O proxecto systemd documenta esa distinción directamente, e a consecuencia práctica é que todo o que necesite un enderezo de túnel debe posuír a dependencia por si mesmo. Unha unidade que espera network-online e despois liga un enderezo de túnel só é correcta cando o túnel resulta subir primeiro, o que é unha casualidade e non un deseño.

Probe o ciclo de vida que realmente escolleu

Probe un arrinque limpo, unha petición despois de que apareza o enderezo e o comportamento despois de que a VPN caia e volva. Eses tres casos separan un oínte funcional dun servizo funcional.

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

O primeiro comando detecta erros do ficheiro de unidade antes dun reinicio, o segundo mostra a unidade fusionada e o terceiro demostra se o oínte existe e en que enderezo. Un oínte nun enderezo comodín onde esperaba un enderezo de túnel é exactamente o resto que o ListenStream baleiro debía eliminar. Repita o terceiro comando tras unha reconexión da VPN para ver se o enderezo se moveu.

Escolla o ciclo de vida a propósito: ou un oínte ligado libremente que espera o regreso dun enderezo estable, ou un servizo que se detén co túnel e arrinca de novo ao recuperarse. Son deseños distintos e fallan de xeitos distintos. Despois manteña a política de acceso ligada ás fontes e rutas que pretendía, porque ligar un enderezo de destino non esixe que os paquetes aceptados chegasen por unha interface de confianza.