O nome de host da gateway Pi atualiza as rotas estáticas sozinho?

Um nome DNS para a sua gateway Pi nunca reescreve um próximo salto já instalado. Veja o que o kernel guarda e quem tem de atualizar a rota.

Apontar uma rota estática para um nome de gateway parece que deveria sobreviver a uma mudança de endereço, e não sobrevive. O nome vive no DNS, enquanto a rota fica na tabela de roteamento do cliente como um próximo salto numérico. Quando o Pi muda para outro endereço, cada consumidor que já instalou o salto antigo continua a enviar tráfego para o mesmo número. Nenhum resolvedor está ligado à tabela de encaminhamento, por isso nada reescreve essa entrada por você.

A resposta DNS e a rota são objetos diferentes

Digamos que o seu Pi responde a vpn-gw.lan e encaminha 10.44.0.0/16 para um túnel. Os clientes em 192.168.30.0/24 chegam-lhe através de uma rota estática. Quando o endereço do Pi passou de 192.168.30.4 para 192.168.30.11, o registo seguiu dentro do seu TTL e as rotas não.

As duas vistas discordam de uma forma fácil de perder, porque ambas parecem plausíveis quando as consulta em 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 linha decide para onde vão os pacotes. A segunda linha responde a uma pergunta que o kernel nunca fez. Um registo com vários registos A também não se torna uma política de failover, porque cada endereço continua a ter de ser um próximo salto utilizável nesse segmento.

O que sobrevive na tabela depois de o comando terminar

Uma rota Linux regista duas coisas que importam aqui: o próximo salto como endereço de protocolo e a interface de saída como número de índice. Os atributos de rota rtnetlink nomeiam esse primeiro campo RTA_GATEWAY, e ele contém bytes. Assim que a entrada está no lugar, não lhe é anexado nenhum TTL e nenhuma pesquisa em segundo plano a atualiza.

É por isso que ip route add 10.44.0.0/16 via vpn-gw.lan pode parecer funcionar. A ferramenta resolve o nome enquanto o comando corre, escreve o endereço resultante e esquece o nome por completo. Execute ip route show 10.44.0.0/16 depois e recebe um endereço literal de volta.

Vale a pena conhecer esse comportamento antes de culpar o túnel.

Ferramentas que resolvem um nome por você, e quando

Alguns routers e firewalls aceitam realmente nomes de host num campo de rota ou de gateway. O que importa é quando ocorre a resolução. Se o dispositivo só resolve o nome enquanto aplica a configuração, a entrada guardada é tão estática como um endereço escrito, e uma mudança de endereço posterior exige outra aplicação. O facto de o campo aceitar um nome não lhe diz nada sobre a atualização.

As instalações geridas tendem a dividir o trabalho. Uma reserva DHCP ou um aluguer estático mantém o Pi num único endereço, e o registo DNS segue simplesmente o aluguer. Nada tem de seguir um alvo móvel porque o alvo não se move.

Um atualizador monitorizado é o outro padrão legítimo, e precisa de um responsável.

Fixe o endereço ou execute você mesmo o atualizador

Para uma LAN pequena, uma reserva no servidor DHCP é a solução mais barata. Escolha um endereço fora do conjunto dinâmico, ligue-o ao endereço MAC do Pi e confirme-o com ip -4 addr show dev eth0 após a próxima renovação do aluguer. Depois aponte o próximo salto dos clientes para esse endereço uma vez. Agora tem uma gateway estável e um registo que a descreve, e é essa a ordem em que a relação realmente funciona.

Se o Pi tiver mesmo de se mudar, mantenha a reparação da rota num único lugar em vez de editar cada cliente à mão. Um script curto que resolve, compara e substitui basta para tornar o passo repetível:

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 é o teste de aceitação, porque imprime a gateway que o kernel vai realmente usar. Se o endereço impresso ainda for o antigo, o script correu no espaço de nomes de rede errado ou não tinha permissão, e o lado DNS é irrelevante.

Verifique também o caminho de volta. O Pi tem de saber como chegar à sub-rede dos clientes, e a sua firewall tem de permitir o tráfego do túnel. Uma rota predefinida acrescentada para tapar o desajuste costuma esconder a falha real e quebrar outra coisa uma semana depois.

Artigos relacionados