Haz que la regla ip sobreviva a una reconexión con systemd-networkd
Una regla ip creada desde el intérprete desaparece en el siguiente evento del enlace. Declara la regla, su tabla y sus rutas en systemd-networkd para que la política se recree.
Añade una regla de política con ip rule y funciona hasta que el enlace desaparece; en ese momento simplemente ya no está. Nada falló ruidosamente: el estado del núcleo cambió y ningún propietario de configuración sabía que la regla debía existir. Esa es toda la diferencia entre una regla que sobrevive y una que no. En un equipo con systemd-networkd, la solución es darle a la regla un propietario en lugar de volver a ejecutar el comando tras cada reconexión.
Una regla solo existe si alguien la posee
La política de enrutamiento del núcleo es estado, no configuración. Vive en el sistema en marcha, y cualquier cosa que derribe la interfaz de la que depende puede llevársela. Un comando del intérprete cambia ese estado y no deja ningún registro de la intención.
Los gestores de red trabajan al revés: leen la configuración, la aplican y la vuelven a aplicar cuando un evento del enlace invalida el estado anterior. Una regla declarada en su configuración se recrea, mientras que una regla añadida a su lado es un objeto ajeno sin propietario.
Esa distinción tiene un nombre en networkd, y merece la pena leerlo antes de habilitar nada. Las reglas ajenas se eliminan por defecto en las versiones recientes, lo que sorprende a quien esperaba que sus entradas manuales persistieran.
Lee la versión antes de confiar en un ajuste
El comportamiento de propiedad se controla con un ajuste de networkd.conf, y ese ajuste no existe en versiones antiguas de systemd. Comprueba la versión instalada antes de diseñar en torno a él, porque un equipo antiguo se comporta de forma distinta a la documentación que estás leyendo.
Dos valores importan. Uno decide si se eliminan las reglas no declaradas en la configuración de networkd, y el otro hace lo mismo con las rutas. Ambos tratan de la propiedad y no del contenido de la política, y ambos adoptan por defecto el comportamiento más estricto en las versiones actuales. Desactivarlos globalmente mantiene viva cada regla ajena, lo que es una decisión mucho más amplia que declarar una política VPN deseada.
systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null
Ese grep te dice qué está definido localmente y cuál es el valor por defecto del proveedor. La ausencia también es información, porque significa que se aplica el valor compilado. Anota el valor por defecto para que la siguiente persona no tenga que redescubrirlo.
Declara la regla y la tabla a la que apunta
Una regla en un archivo .network nombra una tabla, y eso es todo lo que hace un nombre. No crea las rutas dentro de esa tabla ni comprueba que tengan sentido. Declarar la regla sin las rutas produce una política que hace coincidir el tráfico y luego lo descarta.
Declara las rutas en el mismo archivo, con saltos siguientes alcanzables y la tabla correcta. Mantén la prioridad en la regla declarada para que caiga donde esperas en la lista ordenada. Una regla que llega a la tabla equivocada antes de lo previsto cambia más tráfico que el servicio que querías arreglar. Lee el fragmento de abajo como una forma y no como un archivo completo, porque la propiedad de la interfaz y el resto de la conexión aún deben estar presentes.
[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000
[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100
Luego recarga y lee el estado del núcleo en lugar del archivo. Una configuración que se analizó limpiamente puede producir igualmente una regla que no querías, y ambas vistas coinciden solo cuando la declaración estaba completa.
Elige un solo propietario para la interfaz
Dos gestores en un túnel producen una pelea que parece un fallo en ambos. Importar una configuración wg-quick existente en networkd es una migración y no una adición, y ejecutar ambos deja la interfaz y sus reglas bajo dos propietarios.
Haz la migración de una vez: detén la unidad antigua, desactívala, declara la interfaz y sus rutas en networkd y recarga. Comprueba que la unidad antigua no pueda volver al arrancar. Una unidad residual que se reactiva tras un reinicio sobrescribe el estado que acabas de declarar. Conserva el archivo de configuración antiguo hasta que el nuevo haya sobrevivido a una reconexión, y luego retíralo.
La propiedad de la marca merece el mismo cuidado: si una regla coincide con una marca del cortafuegos, algo tiene que poner esa marca. Una regla que hace referencia a una marca que nadie pone es configuración muerta que parece deliberada.
Ensaya los eventos del ciclo de vida
La configuración vale tanto como su comportamiento a lo largo de los eventos. Baja el enlace, súbelo, reinicia el servicio y renueva la dirección. Después de cada uno, lee la lista de reglas y el contenido de la tabla.
sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd
El resultado buscado es la misma política con propietario recreada y el estado obsoleto retirado, algo más duradero que volver a añadir una regla del intérprete tras cada reconexión. Mantén una línea en el registro de cambios que nombre el archivo propietario de la regla y la versión que la admite. Así el siguiente ingeniero puede encontrar la política sin buscar en un historial del intérprete. Una regla que nadie posee es una regla que se volverá a perder.