Executar a VPN no host ou dentro da VM? Guia de decisão

Construir o túnel dentro do convidado e construí-lo no host mudam ambos o endereço que o navegador informa, e é aí que a semelhança acaba. Um túnel pertencente ao convidado guarda as suas chaves, a sua rota predefinida e o seu resolvedor dentro do núcleo do convidado, enquanto o host encaminha pacotes cifrados para um único endereço remoto. Um túnel pertencente ao host é a imagem espelhada: o cliente do host detém a sessão e aplica rotas e política, e o convidado toma emprestado o que sai. Escolha o proprietário errado e cada sintoma posterior o envia para a máquina errada. Dois comandos resolvem a questão em cerca de um minuto, e o resto deste guia é o que fazer com a resposta.

Decida o proprietário antes de tocar no cliente

A regra é sobre onde o texto cifrado é produzido, não sobre qual máquina mostra um ícone de VPN. Se o convidado o produz, o convidado precisa de uma rota funcional até ao servidor VPN e de nada mais do host. Se o host o produz, o convidado precisa de que o caminho pelo host sobreviva a qualquer política que o cliente do host imponha ao tráfego local.

Três perguntas costumam escolher a colocação por si. O tráfego do convidado tem de sobreviver a um cliente corporativo no host? Então o túnel é dentro do convidado. Vários convidados precisam de uma única credencial e de um único endereço de saída? Então é no host, com o encaminhamento configurado de propósito. O tráfego do convidado deve ficar totalmente fora da VPN do host? Então um túnel no convidado é a única disposição que lhe dá isso por construção.

Anote a resposta numa linha ao lado do nome da VM: guest-owned ou host-owned. Num laboratório de seis máquinas essa nota poupa mais tempo do que qualquer passo abaixo, porque o impede de diagnosticar um túnel que nunca esteve na máquina em que iniciou sessão.

WSL1 e WSL2 são casos opostos

O WSL1 não é uma máquina virtual, pelo que a questão da colocação se evapora em grande parte. Os seus binários Linux correm contra a pilha de rede do Windows através de uma camada de tradução, e um cliente VPN Linux não tem interfaces independentes para configurar. A disposição que funciona é um túnel do lado do Windows, com a distribuição a usar o resultado sem possuir nada.

O WSL2 é o contrário. Executa um núcleo real numa VM auxiliar leve atrás de um comutador virtual Hyper-V, e o seu espaço de endereços é traduzido por NAT através de um adaptador do lado do host. Por isso um cliente Linux dentro da distribuição comporta-se como numa máquina Linux física: cria tun0 ou wg0, instala as suas próprias rotas e funciona. A falha vive do lado do host. Quando um cliente VPN Windows se liga com uma política que bloqueia o tráfego nas redes locais, trata a sub-rede WSL2 como uma rede local não fidedigna e corta o caminho NAT. A distribuição perde então DNS e acesso de saída enquanto o seu próprio túnel ainda está saudável: wg show relata um handshake, ip route parece correto, e curl fica pendurado.

Que correção pode usar depende da compilação do Windows. A mais antiga é uma exceção no cliente do host para a sub-rede WSL, adicionada nas definições de rede local ou de túnel dividido do cliente. A mais recente, em compilações do Windows 11 que a suportam, é a rede espelhada: coloque networkingMode=mirrored na secção [wsl2] de %UserProfile%\.wslconfig, execute wsl --shutdown, e a distribuição partilha as interfaces do host em vez de uma sub-rede NAT privada. O modo espelhado também altera o comportamento do localhost e das portas de entrada, por isso trate-o como uma migração e não como um interruptor.

NAT, ponte e o que o host consegue ver

Sob NAT, os pacotes do túnel do convidado são endereçados ao endereço público do servidor VPN e saem pelo adaptador do host como UDP ou TCP cifrado. O host vê um único fluxo e a sua contagem de bytes, nada sobre os destinos lá dentro. Sob um adaptador em ponte, o convidado tem a sua própria identidade de camada 2 na LAN física, obtém o seu próprio aluguer DHCP e parece, para qualquer política baseada em MAC, um segundo dispositivo. Nenhum dos modos deixa o host ler a carga do túnel; o convidado em ponte é simplesmente muito mais visível para a rede à sua volta.

O isolamento também tem um piso. Um convidado não se pode esconder da máquina que possui a sua memória, e quem controla o host pode ler chaves da RAM do convidado. O que um túnel no convidado lhe dá é uma fronteira de encaminhamento e uma fronteira de malware, não proteção contra a pessoa que segura o portátil. Vale a pena ter os modos de adaptador documentados abertos enquanto escolhe, já que o modo altera tanto o que o host vê como o que a LAN vê.

Guia: coloque-o, configure-o, prove-o

Execute estas quatro verificações por ordem numa shell de convidado nova, e pare na primeira que não concordar com o proprietário que anotou.

1. ip route get 1.1.1.1 a devolver tun0 ou wg0 significa propriedade do convidado, e eth0 com um salto seguinte privado significa propriedade do host.
2. resolvectl query example.com, ou leia /etc/resolv.conf onde o convidado não executa nenhum serviço de resolvedor. Um túnel que transporta tráfego mas não DNS é o estado a meio configurar mais comum.
3. Compare as saídas: curl -4 -s https://ifconfig.me no convidado contra curl.exe -4 -s https://ifconfig.me no host. Endereços diferentes significam que o convidado possui o túnel, e um host na VPN com um convidado a mostrar o ISP de casa é o caso em que nada foi herdado.
4. Repita ambos com -6. Um túnel só de v4 deixa escapar v6 a menos que o cliente o bloqueie ou encaminhe, e muitos clientes deixam v6 na interface física por omissão.

Para um desenho de porta de ligação no host, em que vários convidados partilham um túnel, o host tem de encaminhar e traduzir. Num host Linux são três peças, e o convidado recai silenciosamente na sua rota simples quando falta qualquer uma delas:

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

Do lado do WireGuard, a AllowedIPs do par do host tem de incluir a sub-rede dos convidados, por exemplo 192.168.122.0/24, senão os pacotes de retorno nunca chegam e a configuração parece um problema de firewall. Um host Windows obtém o mesmo resultado com Partilha de Ligação à Internet ou uma regra NAT no comutador Hyper-V, e precisa da mesma verificação do caminho de retorno.

Quando o esquema ainda está aberto, esta tabela cobre as disposições mais frequentes:

Dois túneis, dois convidados e os conflitos entre eles

Quando precisa de duas saídas ao mesmo tempo, o padrão que aguenta é um túnel por convidado. Cada VM mantém a sua própria rota predefinida e o seu resolvedor, o host fica na rede comum, e os dois túneis nunca discutem pela mesma tabela de encaminhamento. Ligar dois convidados em ponte também não junta as suas rotas: a rede virtual fornece um caminho, e a cada cliente ainda tem de ser dito que este tráfego local pode contornar o túnel.

Executar um túnel do host e um túnel do convidado em conjunto é legítimo, e o aninhamento deliberado é por vezes exatamente o que quer, com o convidado a sair pelo seu próprio túnel e esse túnel a sair pelo do host. O que o transforma numa falha é que ninguém anotou qual ponto final deve ser alcançado por que camada. Mantenha uma lista de duas colunas com destino e proprietário, e um conflito de rotas torna-se uma consulta em vez de uma tarde de descoberta.

Verifique e depois deixe a recuperação com o proprietário

Teste de dentro do convidado com um processo de aplicação novo: tráfego, resolução de nomes, ambas as famílias de endereços e o que acontece quando o túnel cai. O ícone de VPN do host não diz nada sobre a cobertura do convidado, e essa é a confirmação falsa mais comum em toda esta área.

A recuperação também pertence ao proprietário. Um túnel pertencente ao convidado é restaurado pelo cliente próprio do convidado e pelas rotas que escreveu. Um desenho pertencente ao host é restaurado pela sequência de arranque do host, e as regras de encaminhamento não sobrevivem a um reinício a menos que uma unidade ou uma tarefa de arranque as volte a aplicar. Um instantâneo restaurado é uma implementação, não um desfazer, porque devolve credenciais antigas e rotas antigas juntamente com o disco. Antes de declarar o trabalho concluído, confirme que o proprietário ainda corresponde à linha que anotou, que o DNS e ambas as famílias de endereços se resolvem dentro do convidado, que um túnel morto deixa uma rede utilizável em vez de um buraco negro, e que um reinício ou uma restauração de instantâneo reproduz o mesmo estado.