VirtualBox NAT ou pont : où s'arrête le VPN de la VM

Deux questions différentes arrivent ensemble chaque fois qu'une machine virtuelle exécute un client VPN, et leurs réponses diffèrent. La première est de savoir si un tunnel à l'intérieur de l'invité protège l'hôte, et la seconde si un tunnel sur l'hôte couvre l'invité. Le mode d'adaptateur tranche les deux, plus que le logiciel VPN. Un adaptateur NAT fait de l'hôte le point de terminaison visible, tandis qu'un adaptateur pont place l'invité sur le réseau avec sa propre adresse.

Qui termine réellement la session chiffrée

Une session chiffrée appartient à la machine qui la termine, et c'est l'invité lorsque le client s'exécute dans la VM. Seul le trafic qui entre dans l'adaptateur virtuel de l'invité emprunte ce tunnel, et l'hyperviseur ne fait jamais transiter une autre machine par l'invité de lui-même. C'est pourquoi l'invité peut tenir un tunnel fonctionnel pendant que l'hôte navigue à découvert. L'inverse n'est pas symétrique, et cette asymétrie est la partie que la plupart des guides ratent.

Quelle adresse le réseau extérieur voit est la question à laquelle répond le mode d'adaptateur. Une fois cela réglé, la couverture cesse d'être une question de politique et devient mécanique. Tout ce qui suit découle de ces deux faits.

NAT réécrit l'invité jusqu'à ce qu'il ressemble à l'hôte

Avec NAT, l'hyperviseur réécrit chaque paquet de l'invité vers l'adresse de l'hôte avant qu'il n'atteigne le premier commutateur. Ce trafic est ensuite remis à la pile réseau de l'hôte, où il suit sa table de routage, y compris une route par défaut détenue par un tunnel sur l'hôte. Un invité NAT est donc couvert par un tunnel de l'hôte sans aucune configuration, ce qui est l'inverse de ce que suggère le cas invité vers hôte.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Un invité qui exécute son propre client termine ce tunnel dans l'invité, et le trafic chiffré sort ensuite par la même réécriture, de sorte que les applications de l'hôte gardent leur propre chemin et leur propre adresse de sortie. VirtualBox gère aussi la résolution de noms dans ce mode et relaie les requêtes de l'invité par son propre moteur sauf si --natdnshostresolver1 est activé. L'activer confie les recherches de l'invité au résolveur de l'hôte, ce qui corrige la résolution quand la vue de l'hôte est juste et livre tout autant un résolveur qui peut n'exister qu'à l'intérieur d'un tunnel. La VM doit être éteinte avant de changer le réglage, et le réglage appartient à l'adaptateur et non au logiciel de l'invité.

Le pont donne à l'invité son propre bail et sa propre exposition

Le pont fait passer les trames de l'invité sur le segment physique, donc DHCP lui donne un bail et le réseau le traite comme un hôte distinct. Chaque invité ponté peut tenir un tunnel indépendant avec sa propre route par défaut, et la table de l'hôte ne change jamais. Le prix est l'exposition : l'invité répond aux diffusions, apparaît dans les tables de voisins et tombe sous la sécurité des ports du commutateur et l'isolement des clients sans fil. Un tunnel sur l'hôte ne couvre pas non plus cette disposition, car les trames de l'invité ne traversent jamais la pile de l'hôte.

Cette différence avec le cas NAT mérite d'être dite franchement plutôt que laissée en implication. Un invité ponté a besoin de son propre client et de ses propres identifiants dès que son trafic doit passer par un tunnel. Là où l'invité doit rester invisible au réseau local, NAT ou un réseau purement interne avec un routage contrôlé est la meilleure conception.

Pourquoi l'invité ne peut pas être la passerelle de l'hôte

Prêter le tunnel d'un invité à l'hôte n'a aucun commutateur pris en charge dans l'un ou l'autre des deux grands hyperviseurs. L'hôte n'a pas de route vers le tunnel de l'invité ni de règle de traduction pointant vers lui, donc le trafic de l'invité et celui de l'hôte restent des flux séparés avec des propriétaires séparés. Cette direction échoue quel que soit le mode d'adaptateur.

Les substituts praticables sont les redirections et les proxys. Une redirection locale SSH permet à l'hôte de se connecter à sa propre boucle locale pendant que l'invité porte le flux dans le tunnel, ce qui couvre les services TCP sans installer un second client. Faire utiliser le tunnel de l'invité au trafic IP propre de l'hôte à la place exige un routeur dans l'invité, plus une route explicite sur l'hôte et une traduction sur l'hôte. C'est une petite conception réseau et non une case à cocher, et elle demande un plan pour le chemin de retour. Quand l'invité n'existe que pour exécuter le client, mettez le client sur l'hôte et supprimez le saut supplémentaire.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Les résolveurs et les routes ne franchissent pas la frontière

Le DNS suit l'adaptateur qui a reçu l'option, donc un invité n'hérite pas du résolveur du tunnel de l'hôte et un hôte n'apprend jamais le serveur poussé à l'invité. Les valeurs dhcp-option DNS poussées s'appliquent à l'interface qui les a acceptées, et c'est pourquoi un invité ponté sans client ne peut pas résoudre les noms internes. Un invité NAT utilise normalement la gestion DNS de l'hyperviseur à la place, et la différence se voit en une commande par environnement.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Lisez le résolveur et la route dans l'invité avant de supposer que l'un ou l'autre suit l'hôte. Ajoutez le résolveur du tunnel à l'adaptateur propre de l'invité quand les noms internes doivent y être résolus, puis vérifiez avec un nom qui n'existe que derrière le tunnel. Notez le mode d'adaptateur, le propriétaire du tunnel et la source du résolveur pour chaque VM, car ces trois faits répondent à presque toute question ultérieure. Les autres hyperviseurs renomment les modes et laissent le principe intact.