Cette adresse de tunnel est un pair, pas un sous-réseau que l’on parcourt

Votre client se connecte et affiche une paire d’adresses, ou une seule adresse portant un 255.255.255.255 masque, et la première réaction est que le serveur a distribué quelque chose de cassé. Rien n’est cassé : une interface tunnelisée est une liaison point à point, et le masque décrit l’extrémité distante de cette liaison unique, pas une plage de voisins. Lire la paire comme locale et pair explique le masque bizarre, la route d’hôte unique à côté et la table de voisins absente. Ce que la même lecture n’excuse pas, c’est un plan d’adressage qui chevauche le réseau du bureau.

Pourquoi le masque semble faux sur une liaison tunnelisée

Sur une interface Ethernet, une adresse et un masque affirment deux choses : cet hôte possède l’adresse, et tout ce qui se trouve dans le préfixe est un voisin direct. Le noyau dérive une route sur la liaison de ces deux faits, puis résout les adresses de liaison pour les voisins qu’il croit présents. Une interface point à point conserve la propriété et abandonne les voisins, donc la seconde adresse de la ligne du client est l’extrémité distante et non un autre hôte sur un segment partagé. Il n’y a pas d’adressage matériel, pas de trafic de résolution et pas de domaine de diffusion à rejoindre, ce qui explique pourquoi l’interface se comporte comme un tuyau avec exactement une destination.

C’est aussi pourquoi une route d’hôte à côté d’un masque large est normale ici et non un symptôme. L’accessibilité sur cette liaison signifie une seule adresse, et le noyau écrit précisément cela. Lisez les deux adresses ensemble avant de décider que la configuration est fausse, car chacune prise seule ressemble à une erreur.

Deux topologies, deux formes d’adresse

L’ancienne topologie point à point donne à chaque client un petit bloc et utilise les deux adresses du milieu, si bien que le masque ressemble à un fragment de réseau plutôt qu’à un pool. La topologie de sous-réseau distribue une adresse du pool avec le masque du pool et nomme l’adresse de tunnel du serveur le pair. Les deux produisent une liaison valide, et elles ne diffèrent que par les adresses qui apparaissent dans le profil et par le masque qu’un utilisateur remettra probablement en question.

Quelle que soit la ligne qui correspond à votre client, lisez d’abord le pair, car il nomme l’extrémité distante et explique donc le masque. Un profil copié entre des serveurs qui utilisent des topologies différentes montrera la mauvaise forme pour son nouveau foyer, et cet écart est facilement pris pour une panne du serveur.

Quand le pool et le réseau du bureau revendiquent les mêmes bits

Comme la liaison est routée, le pool a besoin d’un préfixe qui n’apparaisse nulle part parmi les réseaux que le serveur peut atteindre. Partagez-en un et le client détient une seule route pour une plage qui désigne deux endroits, et la route installée le plus récemment décide lequel l’emporte. La panne se manifeste sur le client alors que la décision derrière appartient au plan d’adressage. Ce que les utilisateurs signalent, c’est la disparition du routeur local à la montée du tunnel, ou le fait que seuls certains hôtes du bureau répondent.

Les préfixes qui se ressemblent seulement sont un autre cas, et comparer des octets à l’œil n’est pas une comparaison de préfixes. Écrivez les deux et comptez les bits masqués : 192.168.4.0/24 contre 192.168.6.0/24 concordent jusqu’au bit 22 et divergent au bit 23, car le troisième octet se lit 00000100 contre 00000110, donc ces deux réseaux sont réellement séparés. Placez 10.8.0.0/24 à côté d’un autre 10.8.0.0/24 et les 24 bits masqués concordent, ce qui signifie qu’une route ne peut pas exprimer les deux endroits. La longueur du masque décide où la comparaison s’arrête, et le réseau installé en second est celui qui perd.

Ce qu’une liaison routée ne peut pas livrer

La diffusion et le multicast ne traversent pas une liaison routée, et plusieurs fonctions familières reposent sur eux. Les listes de parcours, les annonces de noms et la découverte de services supposent tous un segment partagé, donc un serveur de fichiers peut répondre à chaque requête par adresse et pourtant n’apparaître jamais dans une liste. La résolution de noms qui dépend de la diffusion locale de la liaison échoue pour la même raison, et aucune modification de profil ne change ce que le tunnel peut transporter. Savoir si cela compte est une question d’exigences, non de routage.

Un client qui a vraiment besoin de ces livraisons exige une interface pontée, qui transporte des trames Ethernet et conserve donc le domaine de diffusion. Le prix est une liaison plus bruyante, la perte de l’adressage propre décrit plus haut, et une surface de panne bien plus grande dès que des boucles apparaissent. Justifiez l’exigence avant de changer, et préférez un service de noms qui fonctionne sur des liaisons routées quand l’exigence ne porte que sur les noms.

Lire l’interface avant de modifier le profil

Demandez au noyau ce qu’il a installé, non ce que le profil semble dire. La sortie des adresses montre le pair qui explique le masque, et la sortie des routes montre si un chemin vers lui existe. Exécuter les deux contre le périphérique de tunnel prend un moment et tranche la question.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Si ces trois concordent, le profil fait ce pour quoi il a été configuré, et le problème restant se trouve ailleurs. Ne changez la topologie que pour une raison qui nomme une capacité manquante, car un masque inconnu n’en est pas une.