Le nom d’hôte de la passerelle Pi met-il à jour les routes statiques tout seul ?

Un nom DNS pour votre passerelle Pi ne réécrit jamais un saut suivant déjà installé. Voyez ce que le noyau stocke et qui doit mettre à jour la route.

Pointer une route statique vers un nom de passerelle donne l’impression qu’elle devrait survivre à un changement d’adresse, et ce n’est pas le cas. Le nom vit dans le DNS, tandis que la route reste dans la table de routage du client sous forme de saut suivant numérique. Quand la Pi déménage vers une autre adresse, chaque consommateur qui a déjà installé l’ancien saut continue d’envoyer le trafic vers le même numéro. Aucun résolveur n’est relié à la table de transfert, donc rien ne réécrit cette entrée pour vous.

La réponse DNS et la route sont des objets différents

Disons que votre Pi répond à vpn-gw.lan et transfère 10.44.0.0/16 dans un tunnel. Les clients de 192.168.30.0/24 l’atteignent via une route statique. Quand l’adresse de la Pi est passée de 192.168.30.4 à 192.168.30.11, l’enregistrement a suivi dans son TTL et les routes non.

Les deux vues se contredisent d’une manière facile à manquer, car toutes deux semblent plausibles quand on les interroge séparément :

$ 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

Seule la première ligne décide où vont les paquets. La deuxième répond à une question que le noyau n’a jamais posée. Un enregistrement avec plusieurs enregistrements A ne devient pas non plus une politique de bascule, car chaque adresse doit encore être un saut suivant utilisable sur ce segment.

Ce qui reste dans la table une fois la commande terminée

Une route Linux enregistre deux choses qui comptent ici : le saut suivant comme adresse de protocole, et l’interface de sortie comme numéro d’index. Les attributs de route rtnetlink nomment ce premier champ RTA_GATEWAY, et il contient des octets. Une fois l’entrée en place, aucun TTL n’y est attaché et aucune recherche en arrière-plan ne la rafraîchit.

C’est pourquoi ip route add 10.44.0.0/16 via vpn-gw.lan peut sembler fonctionner. L’outil résout le nom pendant l’exécution de la commande, écrit l’adresse obtenue et oublie complètement le nom. Lancez ip route show 10.44.0.0/16 ensuite et vous récupérez une adresse littérale.

Ce comportement vaut la peine d’être connu avant de blâmer le tunnel.

Les outils qui résolvent un nom pour vous, et quand

Certains routeurs et pare-feu acceptent bel et bien des noms d’hôte dans un champ de route ou de passerelle. Ce qui compte, c’est le moment où la résolution a lieu. Si l’appareil ne résout le nom que pendant que vous appliquez la configuration, l’entrée stockée est aussi statique qu’une adresse tapée, et un changement d’adresse ultérieur exige une autre application. Le fait que le champ accepte un nom ne vous dit rien sur le rafraîchissement.

Les installations gérées ont tendance à répartir le travail. Une réservation DHCP ou un bail statique garde la Pi sur une seule adresse, et l’enregistrement DNS suit simplement le bail. Rien n’a à suivre une cible mobile, car la cible ne bouge pas.

Un actualiseur surveillé est l’autre modèle légitime, et il a besoin d’un responsable.

Épinglez l’adresse ou lancez vous-même l’actualiseur

Pour un petit réseau local, une réservation sur le serveur DHCP est la solution la moins chère. Choisissez une adresse hors du pool dynamique, liez-la à l’adresse MAC de la Pi, et confirmez-la avec ip -4 addr show dev eth0 après le prochain renouvellement du bail. Ensuite pointez une fois le saut suivant des clients vers cette adresse. Vous avez maintenant une passerelle stable et un enregistrement qui la décrit, ce qui est l’ordre dans lequel la relation fonctionne réellement.

Si la Pi doit vraiment bouger, gardez la réparation de la route à un seul endroit au lieu de modifier chaque client à la main. Un court script qui résout, compare et remplace suffit à rendre l’étape reproductible :

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

La dernière commande est le test d’acceptation, car elle affiche la passerelle que le noyau utilisera réellement. Si l’adresse affichée est encore l’ancienne, le script s’est exécuté dans le mauvais espace de noms réseau ou manquait d’autorisation, et le côté DNS est sans importance.

Vérifiez aussi le chemin de retour. La Pi doit savoir comment atteindre le sous-réseau des clients, et son pare-feu doit autoriser le trafic du tunnel. Une route par défaut ajoutée pour masquer l’écart cache généralement le vrai manque et casse autre chose une semaine plus tard.

Articles similaires