VPN invité sur ESXi : routage ou pontage, décidez avant le groupe de ports
Un TUN routé exige des routes de retour ; un TAP ponté exige une portée de couche 2 et une politique de groupe de ports plus large. Fixez le rôle avant d'élargir le mode promiscuous.
Routez les paquets ou étendez le domaine Ethernet : la modification du groupe de ports découle de ce choix. Vue depuis une application dotée d'une adresse privée, les résultats peuvent sembler identiques, alors que les exigences de l'hyperviseur n'ont rien en commun. C'est pourquoi le groupe de ports est élargi d'abord et la question de conception tranchée ensuite, généralement après une tempête de broadcast. Passez ces contrôles dans l'ordre et arrêtez-vous tant que l'exigence reste floue, car aucun réglage de groupe de ports ne corrige une conception qui n'a jamais été choisie.
La décision revient au propriétaire du service ; la configuration de l'hyperviseur doit la mettre en œuvre, non la déterminer par accident.
Vérifiez ce dont l'extrémité distante a réellement besoin
Listez les services que les clients distants doivent atteindre et les protocoles qu'ils utilisent. Si la liste se limite à quelques services TCP sur des préfixes connus, le routage suffit. Si quelque chose a vraiment besoin d'une adjacence de couche 2 — découverte dépendante du broadcast, protocoles non IP, appareil qui refuse une passerelle — le routage ne peut pas l'imiter et il faut le dire tôt. Soyez honnête sur les entrées non IP de cette liste, car c'est là qu'une conception routée échoue silencieusement une semaine plus tard.
Vérifiez ensuite le pool de clients. Une conception routée exige une plage d'adresses et une route de retour explicite de l'autre côté ; une conception pontée exige que le domaine Ethernet étendu possède l'attribution d'adresses et l'isolation. Quel que soit votre choix, quelqu'un en dehors de cette VM doit l'accepter.
Ce que chaque conception exige du réseau virtuel
Les deux conceptions diffèrent par ce que le réseau virtuel doit tolérer, et le tableau est le moyen le plus court de le voir :
| Conception | Rôle côté invité | Ce que le réseau virtuel doit absorber | Mode de défaillance en cas de mauvais choix |
|---|---|---|---|
| TUN routé | Routeur entre préfixes séparés | Un pool de clients routé plus des chemins de retour de l'autre côté | Les clients atteignent la passerelle et n'atteignent jamais le service derrière elle |
| TAP ponté | Pont de couche 2 pour les clients qui rejoignent | Identités Ethernet supplémentaires, trafic de broadcast et règles VLAN | Le vSwitch abandonne des trames, ou la conception exige un mode promiscuous que personne n'a approuvé |
Le routage laisse le domaine de broadcast où il est et offre un endroit naturel pour limiter les services qui traversent la passerelle. Le pontage déplace la frontière : les clients deviennent participants du domaine Ethernet étendu, et l'attribution d'adresses, l'isolation et toute politique de couche 2 s'appliquent désormais à eux. Écrivez la ligne choisie dans le journal des changements. Une phrase comme « TUN routé, pool de clients 10.90.0.0/24, route de retour sur le cœur » empêche l'ingénieur suivant de rouvrir le débat sur la conception à partir des réglages du groupe de ports.
Qui doit pouvoir voir les trames de qui
Posez une question au propriétaire de la plateforme avant de toucher au groupe de ports : la conception exige-t-elle que cette VM reçoive des trames adressées à d'autres participants ? Si la réponse est non, rien dans cette section ne s'applique, car un TUN routé n'a jamais besoin de cette visibilité. Si la réponse est oui, le guide Broadcom du mode promiscuous est la lecture qui compte : il expose combien plus du vSwitch la VM peut voir et recommande de confiner cette politique à un seul groupe de ports.
Traitez cela comme une vérification d'exigence, pas comme un permis. Activez le réglage pour un rattachement dédié lorsque le besoin de pontage est écrit, et laissez-le désactivé partout ailleurs. Un trunk VLAN large copié depuis un autre exemple de pont est la partie que personne ne pense à retirer, et une conception à VLAN unique doit le rester.
Notez quel groupe de ports a changé et pourquoi, au même endroit que la ligne de conception. C'est ce couple qui rend le prochain audit possible.
Gardez les objets de l'invité explicites
Sous Linux, l'appartenance au pont et la propriété d'adresse sont des objets distincts, et les confondre produit l'état confus de semi-fonctionnement. Attribuez les adresses à l'interface du pont ou au tunnel routé, pas aux deux côtés du même chemin, et gardez les ports membres exempts de configuration IP.
Évitez de placer un sous-réseau indépendamment sur un TUN routé et sur une interface Ethernet sans rapport. Cette configuration produit deux chemins vers le même préfixe, des réponses asymétriques et un fil de support sur le flapping qui ne mentionne aucun des deux chemins. Si l'invité héberge aussi des conteneurs ou un hyperviseur local, vérifiez qu'ils ne pontent pas déjà vers le même uplink. Deux ponts sur une seule NIC sont une conception, pas un accident que vous voulez découvrir pendant une fenêtre de changement.
Confirmez par un chemin de paquet, pas par un ping
Vérifiez le chemin réel, pas seulement l'accessibilité. Depuis un client, confirmez quelle adresse source arrive au service distant, puis que la réponse revient par le même chemin. Sur l'invité, contrôlez les compteurs de transfert pour le flux précis, et sur le groupe de ports confirmez qu'aucune visibilité supplémentaire n'a été activée au-delà de ce qu'exige la conception choisie.
Enfin, testez le sens de défaillance. Arrêtez le tunnel ou détachez le client et vérifiez que le trafic ne retombe pas silencieusement sur un chemin routé que vous croyiez inutilisé, car cette retombée est la façon dont une conception pontée devient silencieusement un routeur involontaire.