Les sites pontés ont encore besoin d’une décision de sortie internet locale

L’extension VLAN s’est déroulée sans accroc : les hôtes des deux sites se voient, les partages de fichiers fonctionnent et les imprimantes répondent. Puis quelqu’un du plus petit site remarque que chaque téléchargement utilise la ligne internet de l’autre site, et le ticket arrive comme une plainte de bande passante. Le pont a fait exactement ce qu’on lui demandait. Il transportait des trames entre deux bâtiments et n’a jamais eu d’avis sur le routeur que ces trames devaient utiliser pour internet.

Le pont transporte des trames, pas des décisions

Une extension de couche 2 fait ressembler deux emplacements à un seul domaine de diffusion, si bien que les requêtes ARP, les diffusions DHCP et le trafic du même sous-réseau traversent tous le tunnel. C’est tout le service qu’il rend. Rien dans le pont n’inspecte une adresse de destination, ne la compare au lien montant d’un site ni n’oriente le trafic vers la sortie la plus proche. Chaque client prend toujours sa propre décision locale ou distante avec l’adresse et le masque avec lesquels il a été configuré.

Placez deux routeurs sur ce sous-réseau partagé et les deux deviennent des passerelles plausibles, que l’un ou l’autre soit proche ou non du client qui l’utilise.

Comment un client choisit sa passerelle

La décision IPv4 décrite dans RFC 1122 est simple. Une destination à l’intérieur du sous-réseau connecté du client est atteinte directement, avec ARP, et une destination à l’extérieur passe par la passerelle par défaut configurée. C’est pourquoi le trafic du même sous-réseau entre les sites peut traverser le pont sans aucune intervention de routeur, et pourquoi le trafic internet dépend entièrement de l’adresse de passerelle que le client a reçue. Les deux comportements sont indépendants, et un partage de fichiers qui fonctionne ne prouve que le premier.

Si un client du petit site a été configuré avec le routeur du grand site, ses trames internet traversent d’abord le tunnel et sortent par là.

Changer la route par défaut de l’appliance VPN elle-même ne déplace pas la passerelle de ce client, car le client n’utilise pas du tout l’appliance comme routeur. L’appliance a aussi besoin d’une route distincte vers son homologue distant pour que le tunnel qui transporte ces trames reste actif, et confondre les deux est la façon dont une extension de pont fait tomber son propre transport.

Laissez DHCP exprimer la sortie voulue

L’option 3 d’une réponse DHCP fournit une liste d’adresses de routeur sur le sous-réseau du client, par ordre de préférence, et les clients prennent normalement la première qui répond. Le mécanisme est bon ; la propriété est là où les conceptions dérapent. Notez ce qu’un bail réel livre sur chaque site plutôt que de supposer que le serveur DHCP le plus proche attribuera la passerelle la plus proche.

Exploitez un répartiteur coordonné, ou deux explicitement configurés pour la même politique, et donnez un propriétaire à la politique. Un second répartiteur indépendant ajouté sur le site distant ne crée pas de localité, il crée deux autorités pour le même domaine de diffusion.

N’attribuez pas une seule adresse de passerelle à deux routeurs actifs indépendamment juste pour que les réglages des deux sites semblent identiques. Une adresse virtuelle partagée sur un segment ponté est une conception de redondance de premier saut avec ses propres exigences, et une version artisanale produit des conflits ARP qui ressemblent à des pertes de paquets intermittentes. Si l’application n’a pas réellement besoin d’un segment de couche 2 partagé, des préfixes routés séparés avec des passerelles par défaut locales sont plus simples à exploiter et plus faciles à expliquer lors d’un incident.

Testez les quatre choses séparément

Demandez quatre observations, pas une. Prenez un nouveau bail DHCP sur chaque site et notez le routeur et le masque reçus. Atteignez un service du même sous-réseau sur l’autre site et confirmez que le chemin est le pont et non un détour routé. Récupérez quelque chose depuis l’internet public sur chaque site et confirmez quel lien montant l’a transporté. Puis coupez le tunnel et voyez ce qui casse, car un site qui perd toute connectivité quand le pont tombe en panne dépendait de la passerelle distante sans que personne ne le remarque.

Ces quatre résultats vous disent si vous avez un pont intersites, une sortie locale ou un retour accidentel, et les collecter prend dix minutes.

Le principe de conception n’est pas glamour : le pontage décide de l’accessibilité, DHCP décide de la passerelle, et la table de routage de l’appliance décide du chemin propre du tunnel. Gardez les trois dans des conversations séparées, car un seul changement qui tente de corriger les trois en casse généralement deux.