NAT ou rede de VM en ponte: cal transporta o tráfico VPN?
Os invitados NAT toman o túnel do host prestado só se o cliente tuneliza por ruta; os invitados en ponte encamiñan por si mesmos. Proba o invitado e despois escolle o modo que corresponda.
A ponte e NAT non son dúas formas de conectar o mesmo invitado á túa VPN; deciden quen é dono dos paquetes do invitado antes de que haxa un túnel polo medio. En modo NAT o hipervisor reescribe o tráfico do invitado e emíteo desde código do lado do host, así que o invitado vai pola ruta que o host lle dea a ese código. En modo ponte o invitado obtén a súa propia identidade de capa de enlace no segmento físico e escolle a súa propia porta de enlace predeterminada, o que fai que o túnel do host lle resulte irrelevante, agás que o router da LAN sexa o que tuneliza. Deixei de tratar a VM como se estivese na VPN e empecei a tratala como unha pregunta sobre cara a onde apunta a ruta predeterminada dese invitado. A proba de abaixo leva uns minutos por modo e resólveo sen conxecturas.
NAT mantén o invitado detrás do código do hipervisor, onde rexen as rutas do host
En VirtualBox un invitado NAT está en 10.0.2.0/24 cunha porta de enlace virtual en 10.0.2.2, un proxy DNS en 10.0.2.3 e ningunha ruta propia cara á rede física. Os paquetes saíntes son tomados polo motor NAT, reescritos para que a orixe sexa o host e pasados á pila IP do host. A partir de aí o tráfico do invitado é un fluxo do host, e a busca de ruta é por destino: un cliente de túnel completo que instala 0.0.0.0/1 e 128.0.0.0/1 no host captúrao sen saber sequera que existe unha VM. O capítulo de Oracle sobre redes de VirtualBox lista estes valores por defecto se queres confirmar os enderezos na túa compilación.
A rede predeterminada de libvirt chega ao mesmo sitio desde 192.168.122.0/24, onde dnsmasq reparte concesións e o host fai masquerade da subrede, así que os paquetes do invitado volven chegar á decisión de encamiñamento do host. A excepción é un cliente que escolle o tráfico por proceso en lugar de por ruta. Se a lista de túnel dividido contén o teu navegador e nada máis, o motor NAT non está nesa lista, e o invitado sae da máquina sen túnel mentres o navegador do host segue parecendo cuberto. Mesma subrede, resultado oposto.
A ponte dálle ao invitado o seu propio sitio na LAN física
A un invitado en ponte dáselles unha NIC virtual conectada a un adaptador real, recibe o seu propio enderezo MAC e toma unha concesión DHCP da rede física. A súa porta de enlace predeterminada é o router da LAN, non o hipervisor, e as súas tramas saen ao cable por ese adaptador. As rutas do túnel do host viven na táboa do host e nunca se consultan, porque as tramas do invitado nunca entran na pila IP do host.
Iso corta en ambos os sentidos. mDNS e a exploración SMB comezan a funcionar porque o invitado ve o tráfico de difusión da LAN, e o invitado vólvese accesible desde outras máquinas do mesmo segmento sen un cortafuegos do host polo medio. A ponte tampouco é unha forma de empurrar un invitado por un túnel existente: conectar unha VM á interface WireGuard ou OpenVPN do host non é algo que VirtualBox ou libvirt fagan por ti. Se un invitado en ponte ten que ir por un túnel, o túnel debe terminar nalgún punto desa LAN.
A proba que remata a discusión
Executa as mesmas comprobacións en ambos os modos e anota as respostas:
- No host,
curl -s https://ifconfig.medá o enderezo v4 público. - No invitado, o mesmo comando, máis
ip routeen Linux ouGet-NetRoute -DestinationPrefix 0.0.0.0/0en Windows para a porta de enlace predeterminada. - Identidade do resolutor:
resolvectl statusoucat /etc/resolv.confno invitado, para ver se apunta a 10.0.2.3 ou a un servidor da LAN. - Familia de enderezos:
ip -6 addr show scope globale unha petición v6, porque un túnel v4 non di nada sobre un enderezo v6 global que o invitado poida ter.
Enderezos públicos coincidentes significan que o invitado está na ruta do host. Un enderezo de invitado que coincide coa saída habitual da LAN significa que non. O paso que a xente se salta é o control: baixa o túnel do host e repite a petición do invitado. Se o invitado segue navegando, nunca dependeu do túnel do host, diga o que diga o nome do modo. En modo NAT o invitado debería perder internet co túnel do host baixado, agás que o cliente estea configurado para permitir tráfico sen túnel, o cal merece saberse por si só.
Dous sinais menten. Un ping correcto demostra alcanzabilidade, non ruta de saída. E o DNS pode ser respondido polo proxy 10.0.2.3 a través do resolutor do host mentres TCP toma outra ruta, que é como se consegue unha páxina que carga e un inicio de sesión que nunca remata.
Que modo encaixa co traballo
O modo é unha decisión de encamiñamento, así que escólleo polo requisito e non polo costume:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
A primeira fila é onde pilla a xente: NAT máis un cliente de túnel completo no host si cobre un invitado, pero só mentres o cliente tuneliza por ruta e o enlace ascendente do host é ese túnel. Move o cliente a unha lista de permitidos só para o navegador e a cobertura desaparece sen ningún erro en ningures. A cuarta fila é o erro inverso: un invitado en ponte por comodidade que comeza a responder SMB ou SSH na LAN da oficina sen que ninguén o note.
Fallos que se achacan á VPN
En Windows a tradución NAT execútase dentro do proceso da VM de VirtualBox, así que un cliente por aplicación necesita esa imaxe exacta na súa lista en lugar dunha regra xeral para máquinas virtuais. Cando unha actualización do cliente reconstrúe a súa lista de procesos, os invitados NAT perden a cobertura primeiro, e o informe soa a unha VM que alcanza a LAN pero non internet mentres o host está ben.
A ponte sobre Wi-Fi é o outro clásico. Os puntos de acceso raramente reenvían tramas cunha MAC de orixe allea, así que unha ponte sobre wlan0 ou falla de todo ou funciona ata que o illamento de clientes do AP empeza a descartala. VirtualBox seguirá ofrecendo o adaptador inalámbrico na súa lista. Se o host está en Wi-Fi e o invitado ten que ir en ponte, planifica probalo en lugar de supoñelo.
O MTU é o terceiro. Un invitado en ponte conserva o MTU de 1500 bytes da LAN, e se executa o seu propio cliente WireGuard a 1420, os handshakes TLS grandes atascan mentres as peticións pequenas funcionan. Baixo NAT o MTU do túnel do host é problema do host, pero o invitado segue crendo en 1500, e o UDP co bit non fragmentar activado pérdese igual.
Anota o modo e volve comprobar tras calquera cambio de adaptador
Anota o modo, a interface do host que usa a ponte, a porta de enlace predeterminada do invitado, o seu resolutor e os seus enderezos de saída v4 e v6. Ese rexistro é o que abarata o seguinte fallo: cando un portátil pasa do dock ao Wi-Fi, un invitado en ponte segue a ponte cara a outro adaptador físico e pode renovar a concesión noutra subrede, mentres un invitado NAT conserva o seu enderezo 10.0.2.x e herda en silencio outro enlace ascendente.
Antes de pechar o ticket, confirma cada un destes puntos:
- O enderezo de saída do invitado difire do do host, así que non está no túnel do host.
- O resolutor é o proxy 10.0.2.3 ou un servidor da LAN, e sabes cal respondeu.
- Non existe ningún enderezo v6 global no invitado se o deseño do túnel é só v4.
- Co túnel do host baixado, o invitado deixa de navegar, ou agora sabes que nunca dependeu del.
- O invitado non ve tráfico de difusión da LAN que non lle incumbe.