Executar a VPN no host ou dentro da VM? Guía de decisión

Construír o túnel dentro do convidado e construílo no host cambian ambos o enderezo que informa un navegador, e aí remata o parecido. Un túnel propiedade do convidado garda as súas claves, a súa ruta predeterminada e o seu resolutor dentro do núcleo do convidado, mentres que o host reenvía paquetes cifrados a un único enderezo remoto. Un túnel propiedade do host é a imaxe especular: o cliente do host mantén a sesión e aplica rutas e política, e o convidado toma prestado o que sae. Escolla o propietario equivocado e cada síntoma posterior enviarao á máquina equivocada. Dous comandos resolven a cuestión en aproximadamente un minuto, e o resto desta guía é que facer coa resposta.

Decida o propietario antes de tocar o cliente

A regra trata de onde se produce o texto cifrado, non de que máquina mostra unha icona de VPN. Se o produce o convidado, o convidado necesita unha ruta funcional ao servidor VPN e nada máis do host. Se o produce o host, o convidado necesita que o camiño polo host sobreviva a calquera política que o cliente do host impoña ao tráfico local.

Tres preguntas adoitan escoller a colocación por vostede. Debe o tráfico do convidado sobrevivir a un cliente corporativo no host? Entón o túnel vai dentro do convidado. Necesitan varios convidados unha soa credencial e unha soa dirección de saída? Entón vai no host, co reenvío configurado a propósito. Debe o tráfico do convidado quedar totalmente fóra da VPN do host? Entón un túnel no convidado é a única disposición que llo dá por construción.

Anote a resposta nunha liña xunto ao nome da VM: guest-owned ou host-owned. Nun laboratorio de seis máquinas esa nota aforra máis tempo que calquera paso de abaixo, porque lle impide diagnosticar un túnel que nunca estivo na máquina na que iniciou sesión.

WSL1 e WSL2 son casos opostos

WSL1 non é unha máquina virtual, así que a cuestión da colocación evapórase na maior parte. Os seus binarios de Linux execútanse contra a pila de rede de Windows a través dunha capa de tradución, e un cliente VPN de Linux non ten interfaces independentes que configurar. A disposición que funciona é un túnel do lado de Windows, coa distribución usando o resultado sen posuír nada.

WSL2 é o contrario. Executa un núcleo real nunha VM auxiliar lixeira detrás dun conmutador virtual de Hyper-V, e o seu espazo de enderezos tradúcese por NAT mediante un adaptador do lado do host. Por iso un cliente de Linux dentro da distribución compórtase como nunha máquina Linux física: crea tun0 ou wg0, instala as súas propias rutas e funciona. O fallo vive no lado do host. Cando un cliente VPN de Windows se conecta cunha política que bloquea o tráfico nas redes locais, trata a subrede WSL2 como unha rede local non fiable e corta o camiño NAT. Entón a distribución perde DNS e acceso de saída mentres o seu propio túnel segue san: wg show informa dun handshake, ip route parece correcto e curl colga.

Que corrección pode usar depende da compilación de Windows. A máis antiga é unha excepción no cliente do host para a subrede WSL, engadida nos axustes de rede local ou de túnel dividido do cliente. A máis nova, en compilacións de Windows 11 que a admiten, é a rede espellada: poña networkingMode=mirrored na sección [wsl2] de %UserProfile%\.wslconfig, execute wsl --shutdown, e a distribución compartirá as interfaces do host en lugar dunha subrede NAT privada. O modo espellado tamén cambia o comportamento de localhost e dos portos entrantes, así que tráteo como unha migración e non como un interruptor.

NAT, ponte e que pode ver o host

Baixo NAT, os paquetes do túnel do convidado diríxense ao enderezo público do servidor VPN e saen polo adaptador do host como UDP ou TCP cifrado. O host ve un só fluxo e o seu reconto de bytes, nada sobre os destinos que hai dentro. Baixo un adaptador en ponte, o convidado ten a súa propia identidade de capa 2 na LAN física, toma o seu propio arrendamento DHCP e parece ante calquera política baseada en MAC un segundo dispositivo. Ningún dos dous modos deixa que o host lea a carga do túnel; o convidado en ponte é simplemente moito máis visible para a rede que o rodea.

Tamén hai un chan para o illamento. Un convidado non se pode esconder da máquina que posúe a súa memoria, e quen controla o host pode ler claves da RAM do convidado. O que lle dá un túnel no convidado é unha fronteira de encamiñamento e unha fronteira de malware, non protección fronte á persoa que sostén o portátil. Paga a pena ter abertos os modos de adaptador documentados mentres escolle, xa que o modo cambia tanto o que ve o host como o que ve a LAN.

Guía: ubíqueo, configúreo, demóstreeo

Execute estas catro comprobacións en orde nun shell de convidado novo, e detéñase na primeira que non concorde co propietario que anotou.

1. ip route get 1.1.1.1 que devolve tun0 ou wg0 significa propiedade do convidado, e eth0 cun seguinte salto privado significa propiedade do host.
2. resolvectl query example.com, ou lea /etc/resolv.conf onde o convidado non executa ningún servizo resolutor. Un túnel que transporta tráfico pero non DNS é o estado a medio configurar máis habitual.
3. Compare as saídas: curl -4 -s https://ifconfig.me no convidado fronte a curl.exe -4 -s https://ifconfig.me no host. Enderezos distintos significan que o convidado posúe o túnel, e un host na VPN cun convidado que mostra o provedor da casa é o caso en que non se herdou nada.
4. Repita ambos con -6. Un túnel só de v4 filtra v6 a menos que o cliente o bloquee ou o encamiñe, e moitos clientes deixan v6 na interface física por defecto.

Para un deseño de porta de enlace no host, onde varios convidados comparten un túnel, o host ten que reenviar e traducir. Nun host Linux son tres pezas, e o convidado volve en silencio á súa ruta simple cando falta calquera 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

No lado de WireGuard, a AllowedIPs do par do host debe incluír a subrede dos convidados, por exemplo 192.168.122.0/24, ou os paquetes de volta nunca chegan e a configuración parece un problema de cortafuegos. Un host Windows logra o mesmo resultado con Conexión compartida a Internet ou unha regra NAT no conmutador Hyper-V, e necesita a mesma comprobación do camiño de volta.

Cando o deseño segue aberto, esta táboa cobre as disposicións máis frecuentes:

Dous túneles, dous convidados e os conflitos entre eles

Cando necesita dúas saídas á vez, o patrón que aguanta é un túnel por convidado. Cada VM mantén a súa propia ruta predeterminada e o seu resolutor, o host queda na rede ordinaria, e os dous túneles nunca discuten pola mesma táboa de encamiñamento. Pór dous convidados en ponte tampouco xunta as súas rutas: a rede virtual fornece un camiño, e a cada cliente aínda hai que dicirlle que este tráfico local pode evitar o túnel.

Executar un túnel do host e un do convidado á vez é lexítimo, e o aniñamento deliberado ás veces é exactamente o que quere, co convidado saíndo polo seu propio túnel e ese túnel saíndo polo do host. O que o converte nunha caída é que ninguén anotou que extremo debe alcanzarse por que capa. Manteña unha lista de dúas columnas con destino e propietario, e un conflito de rutas convértese nunha consulta en lugar dunha tarde de descubrimento.

Verifique, e logo deixe a recuperación ao propietario

Probe desde dentro do convidado cun proceso de aplicación novo: tráfico, resolución de nomes, ambas familias de enderezos e que ocorre cando o túnel cae. A icona de VPN do host non di nada sobre a cobertura do convidado, e esa é a confirmación falsa máis habitual en toda esta área.

A recuperación tamén pertence ao propietario. Un túnel propiedade do convidado restáurase co cliente propio do convidado e as rutas que escribiu. Un deseño propiedade do host restáurase coa secuencia de arranque do host, e as regras de reenvío non sobreviven a un reinicio a menos que unha unidade ou unha tarefa de inicio as volva aplicar. Unha instantánea restaurada é un despregamento, non un desfacer, porque devolve credenciais vellas e rutas vellas xunto co disco. Antes de dar o traballo por rematado, confirme que o propietario segue coincidindo coa liña que anotou, que DNS e ambas familias de enderezos se resolven dentro do convidado, que un túnel morto deixa unha rede utilizábel en lugar dun burato negro, e que un reinicio ou unha restauración de instantánea reproduce o mesmo estado.