¿Actualiza por su cuenta el nombre de host de la puerta Pi las rutas estáticas?

Un nombre DNS para tu puerta Pi nunca reescribe un siguiente salto ya instalado. Mira qué guarda el núcleo y quién tiene que actualizar la ruta.

Apuntar una ruta estática a un nombre de puerta parece que debería sobrevivir a un cambio de dirección, y no lo hace. El nombre vive en DNS, mientras que la ruta se queda en la tabla de enrutamiento del cliente como un siguiente salto numérico. Cuando la Pi se muda a otra dirección, cada consumidor que ya instaló el salto antiguo sigue enviando tráfico al mismo número. Ningún resolutor está conectado a la tabla de reenvío, así que nada reescribe esa entrada por ti.

La respuesta DNS y la ruta son objetos distintos

Digamos que tu Pi responde a vpn-gw.lan y reenvía 10.44.0.0/16 hacia un túnel. Los clientes de 192.168.30.0/24 llegan a ella mediante una ruta estática. Cuando la dirección de la Pi pasó de 192.168.30.4 a 192.168.30.11, el registro siguió dentro de su TTL y las rutas no.

Las dos vistas discrepan de una forma fácil de pasar por alto, porque ambas parecen plausibles cuando las consultas por separado:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Solo la primera línea decide adónde van los paquetes. La segunda línea responde a una pregunta que el núcleo nunca hizo. Un registro con varios registros A tampoco se convierte en una política de conmutación por error, ya que cada dirección todavía tiene que ser un siguiente salto viable en ese segmento.

Qué sobrevive en la tabla después de que el comando termina

Una ruta de Linux registra dos cosas que importan aquí: el siguiente salto como dirección de protocolo y la interfaz de salida como número de índice. Los atributos de ruta de rtnetlink nombran ese primer campo RTA_GATEWAY, y contiene bytes. Una vez que la entrada está en su sitio, no se le adjunta ningún TTL y ninguna búsqueda en segundo plano la refresca.

Por eso ip route add 10.44.0.0/16 via vpn-gw.lan puede parecer que funciona. La herramienta resuelve el nombre mientras se ejecuta el comando, escribe la dirección resultante y olvida el nombre por completo. Ejecuta ip route show 10.44.0.0/16 después y obtendrás una dirección literal.

Vale la pena conocer ese comportamiento antes de culpar al túnel.

Herramientas que resuelven un nombre por ti, y cuándo

Algunos routers y cortafuegos sí aceptan nombres de host en un campo de ruta o de puerta. Lo que importa es cuándo ocurre la resolución. Si el dispositivo resuelve el nombre solo mientras aplicas la configuración, la entrada guardada es tan estática como una dirección escrita, y un cambio de dirección posterior necesita otra aplicación. Que el campo acepte un nombre no te dice nada sobre la actualización.

Los entornos gestionados suelen repartir el trabajo. Una reserva DHCP o un arrendamiento estático mantiene la Pi en una dirección, y el registro DNS simplemente sigue al arrendamiento. Nada tiene que seguir a un objetivo móvil porque el objetivo no se mueve.

Un actualizador monitorizado es el otro patrón legítimo, y necesita un responsable.

Fija la dirección o ejecuta tú mismo el actualizador

Para una LAN pequeña, una reserva en el servidor DHCP es la solución más barata. Elige una dirección fuera del grupo dinámico, vincúlala a la dirección MAC de la Pi y confírmala con ip -4 addr show dev eth0 tras la siguiente renovación del arrendamiento. Luego apunta el siguiente salto de los clientes a esa dirección una vez. Ahora tienes una puerta estable y un registro que la describe, que es el orden en el que la relación funciona en realidad.

Si la Pi tiene que moverse de verdad, mantén la reparación de la ruta en un solo lugar en vez de editar cada cliente a mano. Un script corto que resuelva, compare y reemplace basta para hacer el paso repetible:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

El último comando es la prueba de aceptación, porque imprime la puerta que el núcleo usará realmente. Si la dirección impresa sigue siendo la antigua, el script se ejecutó en un espacio de nombres de red equivocado o carecía de permiso, y el lado DNS es irrelevante.

Comprueba también la ruta de vuelta. La Pi tiene que saber cómo llegar a la subred de los clientes, y su cortafuegos tiene que permitir el tráfico del túnel. Una ruta por defecto añadida para tapar el desajuste suele ocultar el hueco real y romper otra cosa una semana después.

Artículos relacionados