VPN routé ou LAN ponté pour une liaison entre agence et laboratoire

Il y a deux façons de faire joindre un laboratoire domestique à une agence, et la différence n’est pas un réglage. Vous pouvez router entre des préfixes distincts, pour que chaque site conserve son propre domaine de diffusion, ou ponter les deux LAN en un seul, pour que les diffusions et le trafic de découverte se comportent comme si tout le monde était dans la même pièce. Le routage est la conception qui survit au contact d’un vrai réseau. Le pontage est la conception qui rend la première semaine facile et la première panne intéressante. La comparaison ci-dessous porte sur ce que chacun apporte et ce qu’il coûte, puis sur la façon de rendre la version routée testable.

Deux façons de connecter, un compromis évident

Une liaison routée traite le laboratoire domestique comme un réseau distant avec son propre adressage. L’agence demande le préfixe du laboratoire, le tunnel transporte ces paquets, et la passerelle du laboratoire répond depuis son propre sous-réseau. Rien ne change dans la table ARP de l’agence, et aucune partie de l’étendue DHCP du laboratoire n’atteint l’agence.

Une liaison pontée étend un seul domaine de couche 2 sur les deux sites. Les protocoles de découverte fonctionnent, les appareils apparaissent automatiquement, et chaque diffusion, chaque requête ARP et chaque paquet multicast est désormais un candidat au passage du tunnel, soit une grande quantité de trafic portée par des protocoles conçus pour un segment local et non pour un WAN avec une autre MTU et un temps aller-retour variable.

Ce que le routage vous apporte

Le premier avantage est le rayon d’impact. Une boucle, un serveur DHCP indésirable ou un déluge de diffusions reste dans le site qui l’a produit, parce qu’un routeur ne transmet pas les diffusions. Le second est la clarté de l’adressage : le préfixe de l’agence et celui du laboratoire sont distincts, donc la destination d’un paquet vous dit quel site doit répondre, et une règle de pare-feu peut dire « agence vers sous-réseau du laboratoire » plutôt que « n’importe où vers n’importe où ».

Le troisième est qu’il correspond à ce que le tunnel transporte réellement. Une politique IPsec est une paire de préfixes, et le chemin de transmission de chaque côté est du routage IP ordinaire avec le transfert activé sur la passerelle :

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Ce que vous abandonnez, c’est la découverte par diffusion. C’est une perte réelle, et elle doit être remplacée délibérément plutôt que contournée en pontant tout.

Ce que le pontage coûte

Le pontage doit transporter des trames de couche 2 dans un tunnel, ce qui suppose une encapsulation comme GRE ou VXLAN sur IPsec plutôt qu’un simple tunnel à base de politique. Une fois cela en place, les deux sites partagent un domaine de panne. L’arbre couvrant voit le tunnel comme un lien, le trafic de diffusion consomme la bande passante du tunnel, et tout appareil qui suppose un segment à faible latence se comporte mal d’une manière difficile à attribuer depuis l’une ou l’autre extrémité.

Il supprime aussi le contrôle d’adressage qui vous garde honnête. Avec un préfixe plat, une adresse en double n’est pas une erreur de routage mais deux hôtes qui se volent tranquillement leur trafic, et les préfixes qui se chevauchent entre une agence et un laboratoire sont courants dans les montages de laboratoire domestique, donc le pontage ne résout pas ce conflit ; il le répartit.

L’argument de sécurité est celui qui tranche généralement. Un pont étend le segment sur lequel opèrent les protocoles de lien local, donc un appareil de l’agence peut parler à des appareils du laboratoire qui n’auraient jamais dû être joignables de l’extérieur. Si le laboratoire a un hyperviseur, une console de stockage et une interface d’administration sur le même réseau plat, c’est désormais un seul segment, agence comprise.

Des noms sans diffusion

La raison pour laquelle les gens pontent est généralement la découverte : une imprimante, un lecteur multimédia ou un hôte du laboratoire qui n’apparaît jamais dans une liste. La réponse routée est un service de noms. Publiez les hôtes du laboratoire dans une zone que le résolveur de l’agence peut atteindre, puis laissez les utilisateurs se connecter par nom au lieu de balayer le réseau. C’est plus de travail au départ et bien moins de travail à chaque changement futur.

La découverte multicast est le cas plus difficile, et elle mérite de la précision. Des protocoles comme mDNS utilisent le multicast de lien local, que les routeurs ne transmettent pas par défaut, donc un hôte du laboratoire absent d’une liste de découverte peut rester joignable à son adresse documentée. Si un service précis exige vraiment le multicast, planifiez ce seul protocole, avec un réflecteur ou une règle de transmission ciblée, plutôt que de ponter tout le LAN comme réparation générale.

Un réflecteur n’est pas non plus une victoire gratuite. Il importe le même trafic bavard que vous cherchiez à éviter, un service à la fois, et il a besoin d’un propriétaire qui remarquera quand un appareil commence à annoncer plus qu’avant. Choisissez-le service par service, et écrivez pourquoi. Notez quel service en avait besoin et ce qu’il annonce, car une mise à jour de firmware peut changer cette liste sans prévenir personne.

Rendez la conception routée testable

Choisissez une cible, par exemple une interface web du laboratoire sur son propre sous-réseau de serveurs, et prouvez-la dans les deux sens. Depuis un hôte de l’agence, confirmez l’adresse et le service à l’écoute en local, puis connectez-vous par le tunnel et recommencez. Un tunnel qui est monté prouve que les passerelles sont d’accord ; il ne prouve rien sur le pare-feu de l’hôte ni sur la route de retour.

La passerelle normale du laboratoire a besoin d’une route de retour vers le préfixe de l’agence, sauf si la conception traduit délibérément la source, et le pare-feu du serveur lui-même doit accepter la plage distante autorisée. Ni l’un ni l’autre n’est configuré par un tunnel qui fonctionne. Les notes de transmission de strongSwan décrivent le chemin des paquets qui doit fonctionner de chaque côté.

Testez ensuite aussi une destination refusée. Un utilisateur de l’agence qui a besoin d’une application n’a pas besoin de la console de l’hyperviseur, et la seule façon de savoir que la politique est réelle est d’essayer précisément ce qu’elle doit refuser. Notez les préfixes, la dépendance au résolveur et les résultats des tests, et un changement futur dans l’un ou l’autre site peut être examiné en quelques minutes au lieu d’être reconstruit de mémoire.