Actualiza por si só o nome de host da pasarela Pi as rutas estáticas?

Un nome DNS para a túa pasarela Pi nunca reescribe un seguinte salto instalado. Mira o que garda o núcleo e quen ten que actualizar a ruta.

Apunta unha ruta estática a un nome de pasarela parece que debería sobrevivir a un cambio de enderezo, e non o fai. O nome vive no DNS, mentres que a ruta queda na táboa de encamiñamento do cliente como un seguinte salto numérico. Cando a Pi se muda a outro enderezo, cada consumidor que xa instalou o salto vello segue enviando tráfico ao mesmo número. Ningún resolutor está conectado á táboa de reenvío, así que nada reescribe esa entrada por ti.

A resposta DNS e a ruta son obxectos distintos

Digamos que a túa Pi responde a vpn-gw.lan e reenvía 10.44.0.0/16 cara a un túnel. Os clientes de 192.168.30.0/24 chegan a ela mediante unha ruta estática. Cando o enderezo da Pi pasou de 192.168.30.4 a 192.168.30.11, o rexistro seguiu dentro do seu TTL e as rutas non.

As dúas vistas discrepan dunha forma fácil de pasar por alto, porque ambas parecen plausibles cando as 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

Só a primeira liña decide onde van os paquetes. A segunda liña responde a unha pregunta que o núcleo nunca fixo. Un rexistro con varios rexistros A tampouco se converte nunha política de conmutación por erro, xa que cada enderezo aínda ten que ser un seguinte salto viable nese segmento.

Que sobrevive na táboa despois de que o comando remata

Unha ruta de Linux rexistra dúas cousas que importan aquí: o seguinte salto como enderezo de protocolo e a interface de saída como número de índice. Os atributos de ruta de rtnetlink nomean ese primeiro campo RTA_GATEWAY, e contén bytes. Unha vez que a entrada está no seu sitio, non se lle engade ningún TTL e ningunha busca en segundo plano a refresca.

Por iso ip route add 10.44.0.0/16 via vpn-gw.lan pode parecer que funciona. A ferramenta resolve o nome mentres se executa o comando, escribe o enderezo resultante e esquece o nome por completo. Executa ip route show 10.44.0.0/16 despois e obterás un enderezo literal.

Vale a pena coñecer ese comportamento antes de culpar o túnel.

Ferramentas que che resolven un nome, e cando

Algúns routers e cortafuegos si aceptan nomes de host nun campo de ruta ou de pasarela. O que importa é cando ocorre a resolución. Se o dispositivo resolve o nome só mentres aplicas a configuración, a entrada gardada é tan estática como un enderezo escrito, e un cambio de enderezo posterior necesita outra aplicación. Que o campo acepte un nome non che di nada sobre a actualización.

Os ambientes xestionados adoitan repartir o traballo. Unha reserva DHCP ou un arrendamento estático mantén a Pi nun enderezo, e o rexistro DNS simplemente segue o arrendamento. Nada ten que seguir un obxectivo móbil porque o obxectivo non se move.

Un actualizador monitorizado é o outro patrón lexítimo, e necesita un responsable.

Fixa o enderezo ou executa ti mesmo o actualizador

Para unha LAN pequena, unha reserva no servidor DHCP é a solución máis barata. Escolle un enderezo fóra do grupo dinámico, lígao ao enderezo MAC da Pi e confírmao con ip -4 addr show dev eth0 tras a seguinte renovación do arrendamento. Despois apunta o seguinte salto dos clientes a ese enderezo unha vez. Agora tes unha pasarela estable e un rexistro que a describe, que é a orde na que a relación funciona en realidade.

Se a Pi ten que moverse de verdade, mantén a reparación da ruta nun só lugar en vez de editar cada cliente a man. Un script curto que resolva, compare e substitúa abonda para facer o 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

O último comando é a proba de aceptación, porque imprime a pasarela que o núcleo usará realmente. Se o enderezo impreso segue sendo o vello, o script executouse nun espazo de nomes de rede incorrecto ou carecía de permiso, e o lado DNS é irrelevante.

Comproba tamén a ruta de volta. A Pi ten que saber como chegar á subrede dos clientes, e o seu cortafuegos ten que permitir o tráfico do túnel. Unha ruta por defecto engadida para tapar o desaxuste adoita ocultar o oco real e romper outra cousa unha semana despois.

Artigos relacionados