L’invité en pont VMware a perdu son réseau après OpenVPN

Un invité qui était en pont et joignable il y a une heure expire maintenant sur tout, et personne n’a modifié ses paramètres. Sur l’hôte, Internet fonctionne toujours à travers le tunnel. Les deux faits ensemble éloignent la piste du VPN et pointent vers l’hyperviseur, car l’hôte et l’invité n’empruntent plus le même chemin. Un seul nouvel adaptateur virtuel suffit à le provoquer.

L’invité n’a pas changé, le pont si

L’installation du client OpenVPN sous Windows ajoute un adaptateur réseau virtuel auquel le service se lie lorsqu’un tunnel monte. Pour le système d’exploitation, il ressemble à une interface ordinaire avec un état de lien et, souvent, ses propres adresses. Cela suffit à VMware pour le traiter comme candidat au pont.

VMnet0 est réglé sur Automatique par défaut, ce qui signifie que l’hyperviseur choisit une carte de l’hôte à chaque pontage. Un adaptateur virtuel fraîchement installé rejoint ce pool et, s’il est choisi, chaque trame émise par l’invité part vers un périphérique de tunnel plutôt que vers le port physique du commutateur.

Épingler le pont ou router l’invité

La première branche est la bonne lorsque l’invité doit être un pair sur le LAN physique : cessez de laisser le pont choisir et nommez l’adaptateur explicitement. La seconde branche s’applique lorsque l’invité doit utiliser le tunnel d’entreprise, auquel cas un pont n’a jamais été la bonne conception, car un invité en pont n’hérite pas de la route VPN de l’hôte.

Tranchez cela d’abord, car les deux réponses mènent à un travail différent. Inverser l’ordre produit un pont correctement épinglé relié à un invité qui n’aurait jamais dû être en pont.

Pour la première branche, ouvrez l’éditeur de réseau virtuel sur l’hôte, sélectionnez VMnet0 et remplacez Automatique par l’adaptateur physique. Si plusieurs adaptateurs existent, utilisez la liste des paramètres automatiques et décochez tout ce qui ne doit jamais porter le trafic de l’invité : le périphérique TAP ou Wintun d’OpenVPN, ainsi que les adaptateurs Hyper-V, WSL, Docker et loopback. Gardez cochées à la fois la carte physique filaire et la carte sans fil sur un portable, sinon l’invité perd son pont la prochaine fois que l’utilisateur l’accueille dans sa station d’accueil.

Trois conditions qui tranchent le choix

Qu’un pont soit même approprié dépend de la fonction de l’invité. Si l’invité doit apparaître comme un hôte à part entière sur le LAN, avec sa propre adresse et sa propre joignabilité entrante, le pont est le bon modèle et l’épinglage est toute la correction. Si l’invité n’a besoin que d’un accès sortant, un réseau hôte uniquement ou NAT est plus simple et insensible aux changements d’adaptateur.

Si l’invité doit utiliser le même tunnel que l’hôte, ni le mode pont ni un adaptateur épinglé n’aident, car le trafic de l’invité n’entre jamais dans la décision de routage de l’hôte. Ce cas exige un chemin routé ou traduit sur l’hôte, et le choix de l’adaptateur devient sans objet.

VMware Player n’a pas d’éditeur de réseau dans son interface, donc un hôte qui ne fait tourner que Player a besoin de l’éditeur autonome ou d’une installation Workstation pour atteindre ces réglages. Cette contrainte décide parfois de l’approche à elle seule.

Lire le résultat depuis l’intérieur de l’invité

Redémarrez la carte réseau virtuelle, ou redémarrez l’invité, pour qu’il redemande un bail. Lisez ensuite ce qu’il a réellement reçu, et non ce que l’hôte croit avoir configuré.

ipconfig /all
ip addr
ip route

Lisez deux champs dans cette sortie et ignorez le reste pour l’instant. La passerelle devrait être le routeur du LAN, et la description de l’adaptateur devrait nommer le périphérique Ethernet VMware plutôt qu’un tunnel. Une adresse auto-attribuée dans 169.254.0.0/16 signifie qu’aucun serveur DHCP n’a répondu, et c’est exactement l’allure d’un pont sur un adaptateur de tunnel vue depuis l’invité.

Une distinction de plus mérite d’être faite avant de changer quoi que ce soit d’autre. Un invité qui atteint le routeur mais pas Internet a un pont qui fonctionne et un problème en amont. Un invité qui reçoit une adresse dans la plage du tunnel est encore rattaché au mauvais périphérique. Désactiver l’adaptateur TAP ne règle aucun des deux cas, car le service OpenVPN en a besoin.