Pourquoi un hôte du LAN émet un ARP pour l’adresse d’un client OpenVPN

Les problèmes d’atteignabilité entre un hôte du LAN et un client VPN remontent souvent au plan d’adressage lui-même. Donnez à cet hôte une interface sur 10.0.100.0/22 et il considère chaque adresse de 10.0.100.0 à 10.0.103.255 comme directement connectée, y compris un pool de clients discrètement placé en 10.0.101.0/24. La réponse ne passe jamais par un routeur, car du point de vue de l’hôte aucun routeur n’intervient. Le paquet est adressé à un voisin et réclamé sur le fil.

Ce mécanisme explique toute une famille de rapports : le tunnel est monté, le serveur dispose d’une route et l’hôte du LAN ne joint toujours pas le client.

Le /22 qui avale le /24

Lisez le préfixe comme une plage, pas comme une chaîne. Un /22 contient 1024 adresses, et 10.0.100.0/22 couvre 10.0.100.0 à 10.0.103.255, donc un pool en 10.0.101.0/24 se situe entièrement à l’intérieur. L’erreur survit à la relecture parce que les premiers octets du pool diffèrent des premiers octets du LAN et que seul le troisième octet révèle le recouvrement. Écrivez les deux plages en chiffres avant de les déclarer distinctes.

Le même recouvrement peut apparaître en sens inverse. Un pool qui semble libre parce que rien ne l’utilise actuellement peut tout de même tomber dans un préfixe annoncé par un routeur de site, et le plan d’adressage est le seul document qui le montre.

Liaison directe signifie ARP, pas routage

Quand un hôte doté d’une interface /22 envoie vers 10.0.101.25, le noyau compare la destination au préfixe de l’interface et trouve une correspondance. Le paquet devient une résolution de voisin plutôt qu’un paquet routé, et sur Ethernet la résolution de voisin est une requête ARP pour cette adresse. Si l’adresse appartient à un client VPN derrière une passerelle routée, aucun hôte du LAN ne la possède, donc la requête reste sans réponse et les paquets sont abandonnés. Le tunnel n’est pas en cause, et le client ne voit jamais le trafic.

C’est pourquoi la panne paraît asymétrique et parfois intermittente. L’hôte VPN peut souvent joindre le LAN parce que ses propres routes pointent dans la bonne direction, tandis que l’hôte du LAN ne peut pas répondre, et tout cache d’entrée ARP périmée fait scintiller le symptôme.

TUN, TAP et ce que chacun transporte

Un périphérique TUN transporte des paquets IP, et un périphérique TAP transporte des trames Ethernet. Une liaison TUN routée n’a pas besoin de transporter ARP pour assurer l’atteignabilité IP, et c’est précisément pourquoi la requête sans réponse ci-dessus est attendue et non défaillante. TAP avec un pont délibéré peut étendre le domaine de diffusion et faire fonctionner ARP, mais cela change ce que le client peut voir, exige des extrémités prenant en charge le même tramage et constitue une refonte du modèle réseau plutôt qu’une réparation d’un préfixe qui se chevauche. Faire passer un déploiement routé en TAP pour guérir une erreur de plan d’adressage échange un petit problème contre un plus gros.

Notez où la requête ARP est apparue et quel système l’a émise avant de tirer des conclusions. L’émetteur vous dit ce qu’il croit au sujet de la destination, pas ce que fait le tunnel.

Concevez un pool qui ne peut pas se chevaucher

Choisissez un pool hors de chaque préfixe connecté et de chaque préfixe de site annoncé, puis ajoutez les routes qui le rendent joignable dans les deux sens. Une plage comme 10.8.0.0/24 dans une partie inutilisée du plan est facile à raisonner, et un LAN qui doit l’atteindre reçoit une route statique pointant vers le serveur VPN. Modifiez ensemble l’allocation, les routes annoncées, les adresses source autorisées et les règles de pare-feu, car elles décrivent une conception et non quatre réglages.

Le NAT source sur le serveur peut masquer le pool derrière une adresse routable depuis le LAN, et c’est un outil de migration légitime. Il réécrit aussi la source, si bien que le LAN perd la capacité d’attribuer les connexions à des clients individuels et d’appliquer des règles par client.

Pour la recette, utilisez l’adresse réellement attribuée au vrai client et une vraie requête applicative depuis un hôte du LAN, puis confirmez que la réponse suit la passerelle prévue plutôt que le fil.