O tráfego do Windows Sandbox não segue a VPN do anfitrião por padrão
A sandbox chega à rede por um adaptador virtual no comutador predefinido. Se o seu túnel a cobre é uma propriedade do cliente, por isso verifique por dentro.
Inicia o Windows Sandbox, abre lá um navegador e a página carrega pela sua ligação normal, embora o anfitrião estivesse na VPN um minuto antes. Nada está avariado. A sandbox recebe um adaptador de rede virtual ligado ao comutador predefinido do anfitrião, e se o túnel do anfitrião cobre esse caminho é uma propriedade do cliente VPN, não do Windows.
O que a sandbox recebe realmente
A sandbox é uma máquina virtual leve com o seu próprio adaptador de rede. Esse adaptador liga-se através do comutador predefinido do Hyper-V do anfitrião, que traduz o tráfego da sandbox para a interface Ethernet virtual do anfitrião antes de sair da máquina. Este detalhe explica quase todos os sintomas que as pessoas relatam sobre isto.
Portanto a sandbox não é um processo no seu ambiente de trabalho. É um ponto final de rede separado cujos pacotes são reencaminhados pelo anfitrião, e a firewall do anfitrião e o cliente VPN veem esse reencaminhamento cada um à sua maneira. Uma regra escrita para um processo de navegador não corresponde automaticamente a uma trama traduzida de um comutador virtual.
Dois requisitos que parecem um
Chegar a um recurso privado e forçar cada pedido da sandbox a passar pelo túnel são objetivos diferentes. O primeiro precisa de uma rota e de uma resolução de nomes que funcionem para o ponto final da sandbox. O segundo precisa de uma imposição que sobreviva a uma reconexão e a uma falha. Nenhum decorre do outro, e uma verificação que satisfaz um não diz nada sobre o segundo.
Uma verificação do endereço público não responde completamente a nenhuma das duas perguntas. Ver a saída da VPN de dentro da sandbox mostra que parte do tráfego usou o túnel. Não diz nada sobre se os nomes privados são resolvidos, nem sobre o que acontece a um pedido que começa enquanto o túnel está em baixo.
Anote qual dos dois precisa antes de testar seja o que for, porque os dois requisitos levam a desenhos diferentes e só um pode ser verificado com um navegador.
Verifique de dentro da sandbox
A única observação significativa vem da sessão da própria sandbox, não do anfitrião. Abra lá o PowerShell e veja o adaptador, a resolução de nomes e o caminho até um endereço de documentação:
ipconfig /all Resolve-DnsName files.corp.example Test-NetConnection 198.51.100.7 -Port 443 Get-NetRoute -DestinationPrefix 0.0.0.0/0
A lista de adaptadores mostra o endereço e a gateway que a sandbox recebeu. Uma gateway diferente da do anfitrião é normal no comutador predefinido, por isso compare a saída em vez da gateway. O teste de resolução indica se um nome privado é respondido de todo, e é aqui que as configurações split-horizon costumam divergir do anfitrião. A linha da rota mostra qual gateway a sandbox considera dona da rota predefinida.
Repita as mesmas três verificações com o túnel ligado e desligado. Um resultado que não muda entre esses dois estados é prova de que o túnel não está de todo no caminho da sandbox, seja qual for o endereço que a verificação pública mostrou.
Desative a rede quando a sandbox não precisar dela
Para uma inspeção offline, um ficheiro de configuração personalizado pode remover a rede por completo. A definição é um único elemento no documento de configuração:
<Configuration> <Networking>Disable</Networking> </Configuration>
A referência de configuração da sandbox documenta este elemento e avisa que a rede ativada pode expor redes internas a aplicações em que não confia. Esse aviso é a razão completa para a definir explicitamente em vez de aceitar o valor predefinido.
O comutador, no entanto, não seleciona uma interface VPN. É uma decisão binária sobre haver rede, não uma forma de ligar a sandbox a um túnel específico. Um requisito que nomeia uma saída não pode ser satisfeito por um comutador que só decide se existe uma.
Desenhe a fronteira antes de conceder seja o que for
Se o requisito for isolamento estrito, escolha um desenho de rede de máquina virtual que o possa impor, e use a política suportada do produto VPN para tráfego reencaminhado ou de máquinas virtuais. Adivinhar o comportamento do cliente do anfitrião não é um desenho, e uma única verificação bem-sucedida não é uma implementação.
Não dê a uma sandbox não fidedigna um perfil VPN corporativo ou credenciais privadas para um teste passar. Isso troca a fronteira que estava a tentar estabelecer por um resultado verde, e a credencial sobrevive ao teste.
Registe o modo de rede, a saída observada e o comportamento de reconexão nas notas de implementação. Quando uma atualização do cliente mudar a forma como o tráfego reencaminhado é tratado, são essas notas que dizem que o requisito nunca foi realmente cumprido.