Partager la session VPN de l’hôte avec un invité VMware
Un adaptateur de tunnel ne rejoint pas un pont, et Windows 10 ne route pas entre sous-réseaux. Un segment hôte uniquement avec NAT porte l’invité à la place.
Votre machine virtuelle n’atteint pas un système interne qui fonctionne parfaitement sur l’hôte, et l’hôte est connecté via un client qui possède la table de routage. Ponter l’adaptateur virtuel vers le tunnel semble évident et échoue pour deux raisons distinctes. Ce qui fonctionne, c’est la traduction sur un segment que les deux machines possèdent. Le coût est réel : chaque invité perd sa propre identité sur le réseau d’entreprise.
Deux raisons pour lesquelles le pont ne peut pas fonctionner
L’adaptateur du client ne porte généralement qu’une adresse, souvent un /32, et le client réécrit les routes de l’hôte pour que le trafic sortant ordinaire préfère le tunnel. Les applications de l’hôte obéissent à cette table et atteignent le système privé. Un invité ponté ne lit jamais la table, car ses trames sortent par un commutateur sous la couche IP.
Mettre l’adaptateur de tunnel dans un pont résoudrait le chemin en théorie, et le pilote ne l’acceptera pas. Windows 10 n’autorise par ailleurs qu’un seul périphérique de pont et refuse le rôle de routage qui laisserait un poste de travail transmettre entre deux sous-réseaux. Ce qui reste, c’est la traduction de source. Faites apparaître le trafic de l’invité comme venant de l’hôte, et les décisions de l’hôte lui-même le portent dans le tunnel sans que l’invité ait besoin d’une route qu’il ne peut pas avoir.
Créez un segment que l’hôte possède
Dans l’éditeur de réseau virtuel, ajoutez un réseau hôte uniquement comme VMnet3 sur un préfixe que vous ne routez nulle part ailleurs, par exemple 172.28.90.0/24. L’hôte prend 172.28.90.1 sur cet adaptateur et l’invité se rattache au même commutateur. Désactivez le DHCP de l’hyperviseur sur ce segment pour qu’un seul service d’adresses le possède.
Vérifiez que Windows voit l’interface avant de construire quoi que ce soit dessus, car toute la conception dépend du fait que cet adaptateur soit ordinaire :
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24Un adaptateur hôte uniquement y apparaît comme n’importe quel adaptateur physique. C’est précisément la différence avec l’adaptateur de tunnel, qui ne peut être rattaché à rien.
Traduisez le préfixe de l’invité
Ouvrez une session élevée et traduisez le préfixe. Vérifiez d’abord ce qui existe déjà, car les environnements d’exécution de conteneurs et les hyperviseurs installent leurs propres traductions et supprimer la mauvaise casse un autre produit.
Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24Configurez ensuite l’invité avec une adresse statique dans ce préfixe, 172.28.90.1 comme passerelle et les adresses de résolution que le tunnel donne à l’hôte. La traduction transmet des paquets et n’apprend rien à l’invité sur DNS, donc un invité laissé sur le routeur local résout les noms publics et échoue sur tous les internes.
Vérifiez le premier saut, puis le coût
Testez la frontière la plus proche avant de tester une application. Une trace qui s’arrête à la passerelle de l’hôte signifie que la traduction n’a pas lieu, tandis qu’une qui s’arrête au-delà de l’hôte signifie que le tunnel est tombé ou que le côté distant a refusé l’adresse traduite.
tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"Comparez avec l’accès propre de l’hôte à la même destination pendant que le tunnel est actif. Si l’hôte réussit et pas l’invité, la faute se situe dans la traduction ou dans le réglage de passerelle de l’invité, pas dans la connexion.
Acceptez ensuite l’échange. Les systèmes d’entreprise ne voient plus qu’une adresse pour chaque invité, donc les certificats d’appareil et les contrôles de posture par appareil ne peuvent pas les distinguer, et certaines politiques l’interdisent purement et simplement. Décidez aussi du comportement de rejet, car le trafic traduit peut retomber sur le chemin internet ordinaire lorsque le tunnel échoue, sauf si vous bloquez ce préfixe au pare-feu de l’hôte.