Faire tourner le VPN sur l’hôte ou dans la VM ? Guide de décision

Construire le tunnel dans l’invité et le construire sur l’hôte changent tous deux l’adresse qu’un navigateur rapporte, et c’est là que la ressemblance s’arrête. Un tunnel possédé par l’invité garde ses clés, sa route par défaut et son résolveur dans le noyau de l’invité, tandis que l’hôte transmet des paquets chiffrés vers une seule adresse distante. Un tunnel possédé par l’hôte est l’image inverse : le client de l’hôte tient la session et applique routes et politique, et l’invité emprunte ce qui sort. Choisissez le mauvais propriétaire et chaque symptôme ultérieur vous envoie à la mauvaise machine. Deux commandes tranchent la question en une minute environ, et le reste de ce guide est ce qu’il faut faire de la réponse.

Décidez le propriétaire avant de toucher au client

La règle porte sur l’endroit où le texte chiffré est produit, pas sur la machine qui affiche une icône VPN. Si l’invité le produit, l’invité a besoin d’une route fonctionnelle vers le serveur VPN et de rien d’autre de l’hôte. Si l’hôte le produit, l’invité a besoin que son chemin par l’hôte survive à toute politique que le client de l’hôte impose au trafic local.

Trois questions choisissent généralement le placement pour vous. Le trafic de l’invité doit-il survivre à un client d’entreprise sur l’hôte ? Alors le tunnel va dans l’invité. Plusieurs invités ont-ils besoin d’un seul identifiant et d’une seule adresse de sortie ? Alors il va sur l’hôte, avec le transfert configuré exprès. Le trafic de l’invité doit-il rester entièrement hors du VPN de l’hôte ? Alors un tunnel dans l’invité est la seule disposition qui vous le donne par construction.

Notez la réponse sur une ligne à côté du nom de la VM : guest-owned ou host-owned. Dans un laboratoire de six machines, cette note fait gagner plus de temps que n’importe quelle étape ci-dessous, car elle vous empêche de diagnostiquer un tunnel qui n’était jamais dans la machine à laquelle vous êtes connecté.

WSL1 et WSL2 sont des cas opposés

WSL1 n’est pas une machine virtuelle, la question du placement s’évapore donc largement. Ses binaires Linux s’exécutent contre la pile réseau de Windows via une couche de traduction, et un client VPN Linux n’a pas d’interfaces indépendantes à configurer. La disposition qui fonctionne est un tunnel côté Windows, la distribution utilisant le résultat sans rien posséder.

WSL2 est l’inverse. Il exécute un vrai noyau dans une VM utilitaire légère derrière un commutateur virtuel Hyper-V, et son espace d’adressage est traduit en NAT via un adaptateur côté hôte. Un client Linux dans la distribution se comporte donc comme sur une machine Linux physique : il crée tun0 ou wg0, installe ses propres routes et fonctionne. La défaillance vit côté hôte. Quand un client VPN Windows se connecte avec une politique qui bloque le trafic sur les réseaux locaux, il traite le sous-réseau WSL2 comme un réseau local non fiable et coupe le chemin NAT. La distribution perd alors DNS et accès sortant alors que son propre tunnel est encore sain : wg show signale une poignée de main, ip route semble correct, et curl reste bloqué.

Quel correctif vous pouvez utiliser dépend de la version de Windows. Le plus ancien est une exception dans le client de l’hôte pour le sous-réseau WSL, ajoutée dans les réglages de réseau local ou de tunnel divisé du client. Le plus récent, sur les versions de Windows 11 qui le prennent en charge, est la mise en réseau en miroir : placez networkingMode=mirrored dans la section [wsl2] de %UserProfile%\.wslconfig, exécutez wsl --shutdown, et la distribution partage les interfaces de l’hôte au lieu d’un sous-réseau NAT privé. Le mode miroir change aussi le comportement de localhost et des ports entrants, alors traitez-le comme une migration et non comme un interrupteur.

NAT, pont et ce que l’hôte peut voir

Sous NAT, les paquets du tunnel de l’invité sont adressés à l’adresse publique du serveur VPN et sortent par l’adaptateur de l’hôte en UDP ou TCP chiffré. L’hôte voit un seul flux et son nombre d’octets, rien sur les destinations à l’intérieur. Sous un adaptateur en pont, l’invité a sa propre identité de couche 2 sur le LAN physique, prend son propre bail DHCP et ressemble à toute politique basée sur MAC à un second appareil. Aucun des deux modes ne laisse l’hôte lire la charge du tunnel ; l’invité en pont est simplement bien plus visible pour le réseau qui l’entoure.

L’isolement a aussi un plancher. Un invité ne peut pas se cacher de la machine qui possède sa mémoire, et qui contrôle l’hôte peut lire des clés dans la RAM de l’invité. Ce qu’un tunnel dans l’invité vous donne, c’est une frontière de routage et une frontière anti-malware, pas une protection contre la personne qui tient l’ordinateur portable. Les modes d’adaptateur documentés valent la peine d’être ouverts pendant que vous choisissez, car le mode change à la fois ce que l’hôte voit et ce que le LAN voit.

Guide : placez, configurez, prouvez

Exécutez ces quatre contrôles dans l’ordre dans un shell d’invité neuf, et arrêtez-vous au premier qui contredit le propriétaire que vous avez noté.

1. ip route get 1.1.1.1 renvoyant tun0 ou wg0 signifie propriété de l’invité, et eth0 avec un saut suivant privé signifie propriété de l’hôte.
2. resolvectl query example.com, ou lisez /etc/resolv.conf là où l’invité n’exécute aucun service de résolveur. Un tunnel qui transporte du trafic mais pas de DNS est l’état à moitié configuré le plus courant.
3. Comparez les sorties : curl -4 -s https://ifconfig.me dans l’invité contre curl.exe -4 -s https://ifconfig.me sur l’hôte. Des adresses différentes signifient que l’invité possède le tunnel, et un hôte sur le VPN avec un invité affichant le fournisseur d’accès domestique est le cas où rien n’a été hérité.
4. Répétez les deux avec -6. Un tunnel v4 seul fuit le v6 sauf si le client le bloque ou le route, et beaucoup de clients laissent le v6 sur l’interface physique par défaut.

Pour une conception en passerelle sur l’hôte, où plusieurs invités partagent un tunnel, l’hôte doit transmettre et traduire. Sur un hôte Linux, cela fait trois pièces, et l’invité retombe silencieusement sur sa route simple quand l’une d’elles manque :

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Côté WireGuard, la AllowedIPs du pair hôte doit inclure le sous-réseau des invités, par exemple 192.168.122.0/24, sinon les paquets de retour n’arrivent jamais et la configuration ressemble à un problème de pare-feu. Un hôte Windows obtient le même résultat avec le partage de connexion Internet ou une règle NAT sur le commutateur Hyper-V, et a besoin du même contrôle du chemin de retour.

Quand la disposition est encore ouverte, ce tableau couvre les arrangements les plus fréquents :

Deux tunnels, deux invités et les conflits entre eux

Quand vous avez besoin de deux sorties à la fois, le modèle qui tient est un tunnel par invité. Chaque VM garde sa propre route par défaut et son résolveur, l’hôte reste sur le réseau ordinaire, et les deux tunnels ne se disputent jamais la même table de routage. Relier deux invités par un pont ne met pas non plus leurs routes en commun : le réseau virtuel fournit un chemin, et il faut encore dire à chaque client que ce trafic local peut contourner le tunnel.

Faire tourner un tunnel d’hôte et un tunnel d’invité ensemble est légitime, et l’imbrication délibérée est parfois exactement ce que vous voulez, l’invité sortant par son propre tunnel et ce tunnel sortant par celui de l’hôte. Ce qui le transforme en panne, c’est que personne n’a noté quel point de terminaison doit être atteint par quelle couche. Tenez une liste à deux colonnes avec destination et propriétaire, et un conflit de routes devient une recherche au lieu d’un après-midi de découverte.

Vérifiez, puis gardez la restauration chez le propriétaire

Testez depuis l’intérieur de l’invité avec un nouveau processus applicatif : trafic, résolution de noms, les deux familles d’adresses et ce qui se passe quand le tunnel tombe. L’icône VPN de l’hôte ne dit rien de la couverture de l’invité, et c’est la fausse confirmation la plus courante dans tout ce domaine.

La restauration appartient aussi au propriétaire. Un tunnel possédé par l’invité est restauré par le client propre de l’invité et les routes qu’il a écrites. Une conception possédée par l’hôte est restaurée par la séquence de démarrage de l’hôte, et les règles de transfert ne survivent pas à un redémarrage sauf si une unité ou une tâche de démarrage les réapplique. Un instantané restauré est un déploiement, pas une annulation, car il ramène d’anciens identifiants et d’anciennes routes avec le disque. Avant de déclarer le travail terminé, confirmez que le propriétaire correspond toujours à la ligne que vous avez notée, que DNS et les deux familles d’adresses se résolvent dans l’invité, qu’un tunnel mort laisse un réseau utilisable au lieu d’un trou noir, et qu’un redémarrage ou une restauration d’instantané reproduit le même état.