Pourquoi deux sites avec le même sous-réseau ne forment pas un seul LAN

Deux bureaux utilisent tous deux 192.168.77.0/24, et quelqu’un propose un tunnel pour qu’ils forment un seul réseau. La formule paraît simple et cache trois conceptions différentes : deux LAN indépendants qui entrent en collision, un segment Ethernet délibérément étendu sur un WAN, et un montage proxy ARP qui répond pour des adresses distantes. Laquelle vous avez décide de ce qu’un hôte fait du paquet, et la réponse est visible avant que la passerelle VPN n’intervienne.

L’hôte décide avant le routeur

Un hôte dont l’adresse est 192.168.77.10/24 compare la destination à son propre préfixe. Tout ce qui se trouve dans ce préfixe est sur le lien direct, donc l’hôte résout directement l’adresse de couche liaison de la destination. Tout ce qui est en dehors part vers la passerelle par défaut.

Cette décision se prend dans la pile de l’hôte, pas dans le tunnel. Une route ajoutée sur la passerelle ne peut pas sauver un paquet que l’hôte n’y envoie jamais.

Ainsi, quand 192.168.77.20 n’existe qu’au site distant, l’hôte local le demande par ARP et n’obtient aucune réponse. La poignée de main VPN peut être parfaitement saine alors que cela échoue. La panne ressemble à un hôte mort plutôt qu’à un problème de routage. Reconnaître cette signature épargne une heure de débogage du tunnel.

ARP est une question de lien local

ARP demande qui possède une adresse sur ce lien, et la réponse doit venir de quelque chose qui entend la diffusion. Un routeur à l’autre bout d’un tunnel IPsec ne l’entend pas, sauf si la conception fait des deux sites un seul domaine de diffusion.

Deux appareils avec la même adresse aggravent la chose : même une résolution réussie ne dit pas lequel a répondu.

L’adressage en double n’est pas un bogue de routage et aucune route ne le corrige. Soit les sites sont renumérotés dans des préfixes distincts, soit ils deviennent délibérément un seul domaine de couche liaison.

Un segment étendu transporte des trames, pas des routes

Un tunnel transportant de l’Ethernet et raccordé à des ponts fait des deux sites une partie d’un seul domaine de couche liaison. Les diffusions ARP atteignent l’autre côté, et chaque pont apprend quelles adresses MAC se trouvent où. La documentation du pont Linux décrit cette frontière de transfert fondée sur les MAC.

Ici, la passerelle distante ne route pas du tout entre deux sous-réseaux identiques. Les trames traversent une couche sous-jacente qui route l’IP de son côté, tandis que les ponts prolongent la conversation Ethernet.

Le prix est un rayon d’impact plus grand. L’inondation vers des destinations inconnues, les boucles, l’attribution DHCP et l’adressage unique demandent tous un plan qui couvre les deux sites. Quand le WAN tombe, les hôtes perdent du trafic qu’ils considèrent comme local. Le filtrage sur le pont et les règles VLAN peuvent limiter ce qui passe, mais le transport ne promet toujours pas que chaque trame de contrôle de lien local arrive.

Le proxy ARP est une troisième conception

Un routeur peut répondre à l’ARP pour une adresse distante puis router vers elle. Cela fait apparaître l’hôte distant sur le lien direct pour l’émetteur sans étendre un domaine de diffusion.

C’est un outil plus étroit que le pontage : il dépend du transfert, des routes de retour et d’un propriétaire clair pour chaque adresse.

Il ne rend pas non plus routables des protocoles arbitraires autres qu’IP, et il ne reproduit pas un domaine de diffusion Ethernet. Utilisez-le quand l’exigence est exactement cette substitution, pas comme raccourci pour une renumérotation reportée.

Choisissez selon l’exigence, puis vérifiez

Pour l’accès applicatif ordinaire entre bureaux, des préfixes distincts et des routes explicites donnent une frontière plus claire. Pontez quand l’exigence est réellement une adjacence de couche liaison. Renumérotez quand la seule raison du préfixe partagé est que personne ne l’a encore fait.

Confirmez la conception que vous avez réellement en demandant à un hôte ce qu’il fait de la destination:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Un résultat sur le lien direct avec une entrée de voisin en échec indique un chemin de couche liaison manquant. Un résultat via nomme la passerelle et déplace la question vers le routage. Sur un pont, consultez la base de transfert pour voir si la MAC a été apprise à travers le tunnel. Chaque sortie resserre la question de conception au lieu de la relancer.