Le trafic de Windows Sandbox ne suit pas le VPN de l’hôte par défaut

Vous démarrez Windows Sandbox, y ouvrez un navigateur, et la page se charge depuis votre connexion habituelle alors que l’hôte était sur le VPN une minute plus tôt. Rien n’est cassé. Le bac à sable reçoit un adaptateur réseau virtuel relié au commutateur par défaut de l’hôte, et le fait que le tunnel de l’hôte couvre ce chemin est une propriété du client VPN, pas de Windows.

Ce que le bac à sable reçoit réellement

Le bac à sable est une machine virtuelle légère dotée de son propre adaptateur réseau. Cet adaptateur se connecte via le commutateur par défaut Hyper-V de l’hôte, qui traduit le trafic du bac à sable vers l’interface Ethernet virtuelle de l’hôte avant qu’il ne quitte la machine. Ce détail explique presque tous les symptômes signalés à ce sujet.

Le bac à sable n’est donc pas un processus sur votre bureau. C’est un point de terminaison réseau distinct dont les paquets sont relayés par l’hôte, et le pare-feu de l’hôte et le client VPN voient chacun ce relais à leur manière. Une règle écrite pour un processus de navigateur ne correspond pas automatiquement à une trame traduite par un commutateur virtuel.

Deux exigences qui n’en font qu’une en apparence

Atteindre une ressource privée et forcer chaque requête du bac à sable à passer par le tunnel sont deux objectifs différents. Le premier exige une route et une résolution de noms qui fonctionnent pour le point de terminaison du bac à sable. Le second exige une application qui survive à une reconnexion et à une panne. Ni l’un ni l’autre ne découle de l’autre, et un contrôle qui satisfait l’un ne dit rien du second.

Un contrôle de l’adresse publique ne répond pleinement à aucune des deux questions. Voir la sortie du VPN depuis le bac à sable montre qu’une partie du trafic a emprunté le tunnel. Il ne dit rien sur la résolution des noms privés, ni sur ce qui arrive à une requête qui démarre pendant que le tunnel est coupé.

Notez laquelle des deux vous est nécessaire avant de tester quoi que ce soit, car les deux exigences mènent à des conceptions différentes et une seule peut être vérifiée avec un navigateur.

Vérifiez depuis l’intérieur du bac à sable

La seule observation significative vient de la session du bac à sable lui-même, pas de l’hôte. Ouvrez-y PowerShell et regardez l’adaptateur, la résolution de noms et le chemin vers une adresse de documentation:

ipconfig /all
Resolve-DnsName files.corp.example
Test-NetConnection 198.51.100.7 -Port 443
Get-NetRoute -DestinationPrefix 0.0.0.0/0

La liste des adaptateurs vous donne l’adresse et la passerelle attribuées au bac à sable. Une passerelle différente de celle de l’hôte est normale pour le commutateur par défaut, comparez donc la sortie plutôt que la passerelle. Le test de résolution indique si un nom privé reçoit une réponse, et c’est là que les configurations split-horizon divergent généralement de l’hôte. La ligne de route indique quelle passerelle le bac à sable considère comme propriétaire de la route par défaut.

Répétez les mêmes trois contrôles avec le tunnel connecté puis déconnecté. Un résultat qui ne change pas entre ces deux états prouve que le tunnel n’est pas du tout sur le chemin du bac à sable, quelle que soit l’adresse affichée par le contrôle public.

Désactivez le réseau quand le bac à sable n’en a pas besoin

Pour une inspection hors ligne, un fichier de configuration personnalisé peut supprimer entièrement le réseau. Le réglage est un seul élément du document de configuration:

<Configuration>
  <Networking>Disable</Networking>
</Configuration>

La référence de configuration du bac à sable documente cet élément et avertit que le réseau activé peut exposer des réseaux internes à des applications auxquelles vous ne faites pas confiance. Cet avertissement est toute la raison de le définir explicitement plutôt que d’accepter la valeur par défaut.

Le commutateur ne sélectionne toutefois pas une interface VPN. C’est une décision binaire sur l’existence d’un réseau, pas un moyen de lier le bac à sable à un tunnel particulier. Une exigence qui nomme une sortie ne peut être satisfaite par un commutateur qui décide seulement s’il y en a une.

Concevez la frontière avant d’accorder quoi que ce soit

Si l’exigence est une isolation stricte, choisissez une conception réseau de machine virtuelle capable de l’imposer, et utilisez la politique prise en charge du produit VPN pour le trafic relayé ou le trafic des machines virtuelles. Deviner le comportement du client de l’hôte n’est pas une conception, et un seul contrôle réussi n’est pas une mise en œuvre.

Ne donnez pas à un bac à sable non fiable un profil VPN d’entreprise ou des identifiants privés pour faire passer un test. Cela échange la frontière que vous cherchiez à établir contre un résultat vert, et l’identifiant survit au test.

Consignez le mode réseau, la sortie observée et le comportement de reconnexion dans les notes de déploiement. Quand une mise à jour du client change la façon dont le trafic relayé est traité, ce sont ces notes qui disent que l’exigence n’a jamais vraiment été satisfaite.