NAT ou réseau de VM en pont : lequel transporte le trafic VPN ?

Le pont et le NAT ne sont pas deux façons de rattacher le même invité à votre VPN ; ils décident à qui appartiennent les paquets de l'invité avant qu'un tunnel n'entre en jeu. En mode NAT, l'hyperviseur réécrit le trafic de l'invité et l'émet depuis du code côté hôte, si bien que l'invité suit la route que l'hôte donne à ce code. En mode pont, l'invité obtient sa propre identité de couche liaison sur le segment physique et choisit sa propre passerelle par défaut, ce qui rend le tunnel de l'hôte sans importance pour lui, sauf si c'est le routeur du LAN qui tunnelise. J'ai cessé de considérer la VM comme étant sur le VPN et j'ai commencé à le traiter comme une question : où pointe la route par défaut de cet invité. Le test ci-dessous prend quelques minutes par mode et tranche sans supposition.

Le NAT garde l'invité derrière le code de l'hyperviseur, là où s'appliquent les routes de l'hôte

Dans VirtualBox, un invité NAT se trouve sur 10.0.2.0/24 avec une passerelle virtuelle à 10.0.2.2, un proxy DNS à 10.0.2.3 et aucune route propre vers le réseau physique. Les paquets sortants sont pris par le moteur NAT, réécrits pour que la source soit l'hôte, puis remis à la pile IP de l'hôte. À partir de là, le trafic de l'invité est un flux de l'hôte, et la recherche de route se fait par destination : un client en tunnel complet qui installe 0.0.0.0/1 et 128.0.0.0/1 sur l'hôte le capture sans jamais savoir qu'une VM existe. Le chapitre d'Oracle sur le réseau de VirtualBox liste ces valeurs par défaut si vous voulez confirmer les adresses sur votre installation.

Le réseau par défaut de libvirt arrive au même endroit depuis 192.168.122.0/24, où dnsmasq distribue les baux et où l'hôte masque le sous-réseau, si bien que les paquets de l'invité reviennent à la décision de routage de l'hôte. L'exception est un client qui choisit le trafic par processus plutôt que par route. Si la liste de tunnel divisé ne contient que votre navigateur et rien d'autre, le moteur NAT n'est pas sur cette liste, et l'invité quitte la machine sans tunnel pendant que le navigateur de l'hôte semble toujours couvert. Même sous-réseau, résultat opposé.

Le pont donne à l'invité sa propre place sur le LAN physique

Un invité en pont reçoit une carte réseau virtuelle attachée à un adaptateur réel, obtient sa propre adresse MAC et prend un bail DHCP sur le réseau physique. Sa passerelle par défaut est le routeur du LAN, pas l'hyperviseur, et ses trames partent sur le fil via cet adaptateur. Les routes du tunnel de l'hôte vivent dans la table de l'hôte et ne sont jamais consultées, car les trames de l'invité n'entrent jamais dans la pile IP de l'hôte.

Cela coupe dans les deux sens. mDNS et la navigation SMB se mettent à fonctionner parce que l'invité voit le trafic de diffusion du LAN, et l'invité devient joignable depuis d'autres machines du même segment sans pare-feu de l'hôte entre les deux. Le pont n'est pas non plus un moyen de pousser un invité à travers un tunnel existant : attacher une VM à l'interface WireGuard ou OpenVPN de l'hôte n'est pas quelque chose que VirtualBox ou libvirt fait pour vous. Si un invité en pont doit passer par un tunnel, le tunnel doit se terminer quelque part sur ce LAN.

Le test qui met fin au débat

Lancez les mêmes vérifications dans les deux modes et notez les réponses :

• Sur l'hôte, curl -s https://ifconfig.me donne l'adresse v4 publique.
• Dans l'invité, la même commande, plus ip route sous Linux ou Get-NetRoute -DestinationPrefix 0.0.0.0/0 sous Windows pour la passerelle par défaut.
• Identité du résolveur : resolvectl status ou cat /etc/resolv.conf dans l'invité, pour voir s'il pointe vers 10.0.2.3 ou vers un serveur du LAN.
• Famille d'adresses : ip -6 addr show scope global et une requête v6, car un tunnel v4 ne dit rien d'une adresse v6 globale que l'invité pourrait détenir.

Des adresses publiques identiques signifient que l'invité est sur le chemin de l'hôte. Une adresse d'invité qui correspond à la sortie ordinaire du LAN signifie que non. L'étape que les gens sautent, c'est le témoin : coupez le tunnel de l'hôte et répétez la requête de l'invité. Si l'invité continue de naviguer, il n'a jamais dépendu du tunnel de l'hôte, quoi que suggère le nom du mode. En mode NAT, l'invité devrait perdre internet une fois le tunnel de l'hôte coupé, sauf si le client est configuré pour autoriser le trafic hors tunnel, ce qui vaut la peine d'être su en soi.

Deux signaux mentent. Un ping réussi prouve l'accessibilité, pas le chemin de sortie. Et le DNS peut être répondu par le proxy 10.0.2.3 via le résolveur de l'hôte pendant que TCP prend une autre route, ce qui donne une page qui se charge et une connexion qui ne se termine jamais.

Quel mode convient au travail

Le mode est une décision de routage, alors choisissez-le selon le besoin et non par habitude :

La première ligne est là où les gens se font prendre : NAT plus un client hôte en tunnel complet couvre bien un invité, mais seulement tant que le client tunnelise par route et que la liaison montante de l'hôte est ce tunnel. Déplacez le client vers une liste d'autorisation limitée au navigateur et la couverture disparaît sans aucune erreur nulle part. La quatrième ligne est l'erreur inverse : un invité mis en pont par commodité qui se met discrètement à répondre en SMB ou SSH sur le LAN du bureau.

Les pannes qu'on impute au VPN

Sous Windows, la traduction NAT s'exécute dans le processus de la VM VirtualBox, donc un client par application a besoin de cette image exacte dans sa liste plutôt que d'une règle générale pour les machines virtuelles. Quand une mise à jour du client reconstruit sa liste de processus, les invités NAT perdent la couverture en premier, et le rapport ressemble à une VM qui atteint le LAN mais pas internet alors que l'hôte va bien.

Le pont vers le Wi-Fi est l'autre classique. Les points d'accès transmettent rarement des trames portant une MAC source étrangère, si bien qu'un pont sur wlan0 échoue complètement ou fonctionne jusqu'à ce que l'isolation des clients du point d'accès le fasse tomber. VirtualBox proposera quand même l'adaptateur sans fil dans sa liste. Si l'hôte est en Wi-Fi et que l'invité doit être en pont, prévoyez de le tester au lieu de le supposer.

Le MTU est le troisième. Un invité en pont conserve le MTU de 1500 octets du LAN, et s'il fait tourner son propre client WireGuard à 1420, les grandes poignées de main TLS se bloquent tandis que les petites requêtes passent. Sous NAT, le MTU du tunnel de l'hôte est le problème de l'hôte, mais l'invité croit toujours à 1500, et l'UDP avec le bit don't-fragment activé disparaît de la même façon.

Notez le mode, puis revérifiez après tout changement d'adaptateur

Notez le mode, l'interface de l'hôte utilisée par le pont, la passerelle par défaut de l'invité, son résolveur et ses adresses de sortie v4 et v6. C'est cet enregistrement qui rend la panne suivante bon marché : quand un portable passe de la station d'accueil au Wi-Fi, un invité en pont suit le pont vers un autre adaptateur physique et peut reprendre un bail dans un autre sous-réseau, tandis qu'un invité NAT garde son adresse 10.0.2.x et hérite silencieusement d'une autre liaison montante.

Avant de clôturer le ticket, confirmez chacun de ces points :

• L'adresse de sortie de l'invité diffère de celle de l'hôte, il n'est donc pas sur le tunnel de l'hôte.
• Le résolveur est le proxy 10.0.2.3 ou un serveur du LAN, et vous savez lequel a répondu.
• Aucune adresse v6 globale n'existe dans l'invité si la conception du tunnel est uniquement v4.
• Tunnel de l'hôte coupé, l'invité cesse de naviguer, ou vous savez maintenant qu'il n'en a jamais dépendu.
• L'invité ne voit pas de trafic de diffusion du LAN qui ne le concerne pas.