Pont TAP isolé entre deux cartes via OpenVPN

Deux cartes de développement doivent partager un seul segment Ethernet alors que leurs bancs se trouvent dans des bâtiments différents. Le tunnel existe déjà et transporte déjà de l’Ethernet, donc le travail restant ressemble à trois commandes et ne l’est pas. Ce que l’hôte fait d’une trame pontée, où se place l’adresse propre du PC et quelle frontière le pont ne crée pas sont trois faits distincts, et se tromper sur le second est la raison habituelle pour laquelle un laboratoire fonctionne par intermittence et que son accès d’administration se dégrade en silence. Aucun de ces trois faits n’est visible sur un schéma de topologie.

Le parcours ci-dessous suppose une connexion TAP authentifiée entre deux PC Linux, un port filaire dédié par banc et une interface de gestion qui ne fait pas partie de l’expérience. L’ordre compte : les trames d’abord, les adresses ensuite, la frontière en dernier.

Ce que le pont déplace réellement

Un pont est un commutateur implémenté en logiciel. Il apprend quelle adresse MAC apparaît derrière quel port membre et transmet les trames entre membres sans consulter une table de routage IP. Rien dans cette description n’implique un sous-réseau, une passerelle ou une route par défaut, ce qui explique pourquoi activer le transfert IP ne produit pas ce raccordement et pourquoi un ping peut réussir alors que d’autres trafics échouent encore. Une carte peut joindre sa partenaire sans aucune route par défaut configurée, ce qui surprend ceux qui attendent de la couche deux qu’elle se comporte comme la couche trois.

Chaque PC apporte un port filaire au pont et l’appareil TAP au même pont, si bien qu’une trame d’une carte entre par le port local, est transmise à l’appareil TAP, traverse le tunnel, arrive sur l’appareil TAP de la partenaire et est transmise vers la carte de la partenaire. Le tunnel est un port membre comme un autre, et le pont ne sait pas et ne se soucie pas qu’un VPN se trouve derrière. C’est cette symétrie qui rend l’exemple facile à raisonner : chaque côté dispose d’un port tourné vers le laboratoire et d’un port de tunnel, et aucun côté n’est particulier.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

Les noms identiques sur les deux PC sont des noms locaux, pas des objets partagés. Il existe un seul chemin Ethernet entre les bancs, sans second câble et sans second tunnel fermant une boucle ; un pont qui voit la même MAC arriver sur deux ports transmettra volontiers en rond.

Adressez le pont, pas ses ports membres

L’identité du PC sur le segment du laboratoire appartient à l’appareil pont. Les ports membres restent non numérotés, car un port est un membre de transmission et une adresse dessus créerait un second propriétaire concurrent du même segment. C’est la correction que la plupart des recettes faites à la main ratent : elles adressent l’appareil TAP et le pont, puis se demandent lequel la partenaire atteint réellement.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

La partenaire utilise la même forme avec une autre adresse d’hôte, et les cartes prennent des adresses dans la même plage en utilisant l’adresse du pont du PC comme prochain saut si elles en ont besoin. Utilisez des plages de documentation jusqu’à ce que le plan soit validé, et réservez la plage pour qu’elle n’entre pas en collision avec ce que le bureau route déjà. Avant d’exécuter quoi que ce soit, confirmez que les ports membres ne portent aucune adresse résiduelle, aucun client DHCP et aucune appartenance à un autre pont, et harmonisez l’adressage de l’appareil TAP via ce qui possède la configuration du tunnel pour qu’il ne restaure pas une adresse plus tard.

Pourquoi un port dédié par banc

Un port filaire dédié est ce qui empêche l’expérience de devenir une modification à l’échelle du bureau. L’interface de gestion porte SSH, la route par défaut et la connexion VPN externe, et rien de tout cela n’a sa place sur un pont dont le but est de déplacer des trames de laboratoire.

Raccorder un adaptateur de gestion place le LAN du bureau à une décision de transmission d’une carte de développement, et une carte qui se comporte mal en couche deux est exactement le type d’appareil que vous ne voulez pas sur ce segment. Un adaptateur Wi-Fi est pire : le pontage d’une interface sans fil en mode infrastructure ne se comporte pas comme le pontage d’Ethernet, et l’échec est déroutant plutôt que propre.

Gardez la plage du laboratoire hors de toute étendue DHCP de production. Si les cartes ont plus tard besoin d’un adressage dynamique, un seul attribueur autorisé avec un seul pool est la seule disposition qui reste prévisible ; les routeurs ordinaires de deux sites qui répondent sur le même segment produisent des adresses que personne ne peut expliquer.

La frontière que le pont ne crée pas

Le pontage n’est pas le routage, et ce n’est pas non plus l’isolation. Les trames qui traversent le pont peuvent encore atteindre les crochets de filtrage de l’hôte, selon le chemin bridge-netfilter installé, donc la politique effective doit être inspectée plutôt que supposée. Désactiver le pare-feu parce qu’une trame s’est perdue échange un bug précis contre un bug général.

Le transfert IP entre le pont et chaque interface de gestion ou de liaison montante doit rester désactivé ou être explicitement refusé, et c’est un contrôle distinct de l’appartenance au pont. Une carte qui choisit l’adresse de laboratoire du PC comme passerelle teste exactement cela : si le transit d’administration réussit, la frontière voulue n’a jamais existé.

Deux autres familles méritent une décision explicite. Le plan d’adressage ne rend pas le pont IPv4 uniquement, donc IPv6 et les autres EtherTypes ont besoin de leur propre plan ou filtre. Et un ping réussi ne dit rien sur le fait que les diffusions de découverte, les groupes multicast ou les trames jumbo de la carte traverseront le chemin, car ce sont des classes de trafic différentes avec des valeurs par défaut différentes.

Enfin, le transport et la confidentialité sont deux achats différents. TAP transporte Ethernet ; le service OpenVPN fournit la protection autour. Une superposition VXLAN transporte aussi Ethernet et ne fournit aucune confidentialité en soi, donc substituer l’un à l’autre change les propriétés de sécurité même lorsque le schéma de topologie semble identique.

Persistance et les tests qui la prouvent

Une commande tapée une fois après la connexion n’est pas une configuration. Rendez persistants le pont, l’appartenance des ports et l’adresse d’hôte unique via le gestionnaire de réseau existant du PC, et liez le raccordement à l’apparition de l’appareil TAP pour qu’une reconnexion ne laisse pas un pont avec un membre disparu.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

Testez ensuite ce dont les cartes ont réellement besoin dans les deux sens, reconnectez le tunnel et redémarrez un PC selon le plan de reprise approuvé. Confirmez trois choses ensuite : l’accès d’administration fonctionne toujours indépendamment, aucune adresse de laboratoire en double n’apparaît et aucune interface de production inattendue n’a rejoint le pont. Cette combinaison est la preuve que l’expérience est restée dans son banc.