169.254 à travers un VPN : l’adresse n’a jamais été routable
Une destination link-local est abandonnée avant même d’atteindre le tunnel, si bien qu’ajouter des routes ne fait qu’élargir la panne. Choisissez entre réparer le sous-réseau et établir un pont.
Vous ajoutez la route, le tunnel monte, et le ping vers le site distant échoue toujours avec une perte totale au lieu de renvoyer « réseau inaccessible ». Cette distinction compte, car elle détourne l’attention de votre table de routage pour la porter sur l’adresse elle-même. Une destination 169.254 est link-local, et la portée link-local s’arrête au premier saut par conception, non par mauvaise configuration.
La décision qui s’ensuit est étroite et mérite d’être prise explicitement : réparer le sous-réseau côté serveur, ou étendre le segment de couche 2 pour que l’adresse redevienne localement significative. Tout le reste, y compris l’ajout d’une route plus large, ne fait qu’étendre la même panne à davantage de destinations.
L’adresse n’est pas dépourvue de route, elle est non routable
Les adresses IPv4 link-local s’attribuent d’elles-mêmes quand rien de mieux ne répond, ce qui explique le comportement d’adressage privé automatique sous Windows et le repli équivalent sur les autres systèmes. La plage est utilisée sur chaque lien simultanément, et c’est précisément pour cela qu’elle fonctionne : deux hôtes du même segment peuvent communiquer sans aucune coordination.
Cette même propriété explique pourquoi un routeur ne doit pas transmettre ces paquets d’un réseau à l’autre. Recevoir un paquet destiné à une adresse link-local et le renvoyer par une autre interface créerait une ambiguïté, car le « local » de l’émetteur et le « local » du récepteur désignent des endroits différents. Aucune table ne permettrait de décider lequel des deux l’émetteur visait. Le transfert n’est pas un choix de politique que l’administrateur peut activer ici ; la classe d’adresses l’exclut.
Ainsi, une passerelle qui installe 169.254.1.10 comme joignable à travers le tunnel demande au noyau de faire quelque chose que le format d’adresse interdit. Le paquet est écarté bien avant d’atteindre l’hôte distant, et aucune précision de route ne change ce résultat.
Pourquoi un tunnel rend le problème de portée visible
Une interface TUN transporte des paquets IP entre deux pairs et n’a derrière elle aucun segment partagé. Il n’y a ni diffusion, ni ARP pour le côté distant, ni découverte de voisins susceptible de résoudre une destination link-local en adresse de couche liaison. Même si le transfert était autorisé, le client n’aurait aucun moyen d’apprendre quel pair devrait répondre.
Les symptômes concordent parfaitement une fois qu’on sait quoi chercher. La route figure dans la table, ping signale une perte totale au lieu d’un réseau inaccessible, et la table des voisins affiche une entrée incomplète ou en échec pour la destination. Une capture sur le tunnel montre le paquet qui sort, ce qui pousse à chercher de l’autre côté au lieu de regarder la classe d’adresses.
Sous Windows, un second symptôme d’apparence sans rapport a la même racine : une carte réseau réduite à une adresse link-local n’a pas de passerelle utilisable, si bien que l’identification du réseau ne peut pas classer la connexion et que le profil de pare-feu bascule en public. Le tunnel n’est pas la cause ; l’adresse l’est.
Trancher avec trois questions
Le choix entre réparer le sous-réseau et établir un pont sur le lien repose sur trois conditions, et chacune d’elles peut le régler avant même que vous n’ouvriez un fichier de configuration.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
Dans la plupart des cas, la première question suffit. Un hôte qui affiche une adresse link-local signifie généralement que le DHCP n’a pas répondu, qu’un câble ou un VLAN est mal configuré, ou que quelqu’un a saisi l’adresse à la main. Réparer cela coûte moins cher que n’importe quel travail sur le tunnel, et cela élimine le problème pour tous les futurs clients plutôt que pour celui-ci. Cela laisse aussi au site une étendue DHCP fonctionnelle, ce qui est bien ce que vous vouliez.
Vérifiez le côté serveur avant de supposer quoi que ce soit. Lancez ip addr show et ip route sur l’hôte, puis arp -n ou route print -4 sur le client, pour voir si le préfixe existe réellement ou si une entrée obsolète est la seule à prétendre qu’il existe.
Ce que coûte un pont lorsqu’il est la bonne réponse
Établir un pont entre une carte physique et une carte TAP fait du client distant une partie du domaine de diffusion local. La diffusion et la découverte de voisins fonctionnent alors, et une adresse link-local redevient significative parce que le client est réellement local sur ce lien.
Les coûts sont réels et doivent être annoncés avant que quiconque accepte. Le trafic de diffusion traverse le tunnel, le client est exposé au segment local pour tous les usages et pas seulement pour les services dont il a besoin, et le serveur doit désormais transmettre des trames au lieu de router des paquets. C’est un compromis raisonnable pour un banc d’essai ou un appareil sans chemin de configuration routable, et un mauvais choix par défaut pour l’accès distant.
Lorsque vous établissez un pont, les deux moitiés sont nécessaires : le pont sur le serveur, et une route dans le profil du client lui indiquant quelles destinations se trouvent de l’autre côté. Un pont seul laisse le client deviner, et une route seule ne peut pas corriger une classe d’adresses.