Colectores de Windows e VPN: por que falla a rede local
Un colector de Windows usa a táboa de rutas do equipo anfitrión, así que unha VPN que bloquea a subrede local leva consigo o prefixo do colector. O modo Linux toma outro camiño.
Nun só portátil, cun só cliente VPN conectado, os colectores de Linux seguen falando entre si e os de Windows detéñense. A imaxe non é a variable; o camiño que toman os paquetes cara ao equipo anfitrión si o é. Os colectores de Windows na rede predeterminada collen prestada a táboa de rutas e a tradución do equipo anfitrión, así que unha política que cambia o enrutamento do equipo anfitrión tamén os cambia a eles. Confírmeo cunha consulta de rutas antes de reinstalar calquera cousa.
Onde entran os paquetes dun colector de Windows no equipo anfitrión
Un colector na rede predeterminada nat obtén un enderezo dun prefixo do servizo Host Networking Service, normalmente nalgún punto dentro de 172.16.0.0/12, e chega ao equipo anfitrión mediante un adaptador virtual. O equipo anfitrión é dono da ruta dese prefixo e traduce o tráfico cara ao adaptador que estea activo. Non hai ningunha máquina virtual separada no medio dese camiño.
Ese deseño é o que fai mecánico o fallo. Cando o colector envía un paquete, o equipo anfitrión realiza unha consulta de ruta para o prefixo do colector. A ruta que gañe é onde vai o paquete, e o colector non ten opinión sobre iso.
Que cambia o cliente VPN nese camiño
Un cliente corporativo adoita instalar un amplo conxunto de rutas e un filtro que denega o acceso á subrede local mentres o túnel está activo. A intención é defensiva: unha rede local comprometida non debería chegar a unha máquina protexida. O efecto secundario é que a ruta do equipo anfitrión cara ao prefixo do colector xa non é a rede NAT local.
No canto diso, a consulta coincide co túnel e o paquete entrégase á porta de enlace, que nunca oíu falar dese enderezo de colector. O ping falla, a aplicación esgota o tempo e o colector parece roto mentres a icona da VPN brilla. Mire a táboa do equipo anfitrión mentres está conectado e a ruta competidora queda visible.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Por que os colectores de Linux se comportan doutro xeito
O motor de Linux executa os colectores dentro dunha máquina virtual lixeira, e as conexións saíntes desa máquina ábreas un proxy do lado do equipo anfitrión en nome do colector. O equipo anfitrión inicia o socket, así que a regra da VPN sobre o prefixo do colector non se lle aplica do mesmo xeito, e a carga de traballo segue chegando á rede.
Esa diferenza tamén explica por que as receitas de Linux non se trasladan. A un colector de Linux que necesita o seu propio túnel dáselle un dispositivo TUN máis a capacidade NET_ADMIN. Os colectores de Windows non expoñen ningunha interface como dispositivo, así que ese patrón non ten equivalente nese lado.
Demostre a ruta e despois escolla un deseño
Recompile probas do equipo anfitrión, non do colector, porque é o equipo anfitrión quen fai a consulta:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Execute a saída de rutas unha vez antes de que se conecte a VPN e unha vez despois. Se na segunda saída o prefixo do colector apunta ao adaptador do túnel, o diagnóstico está completo e reiniciar os colectores non axudará.
A primeira opción é unha decisión de política: pregunte ao propietario da rede se se pode permitir o acceso á LAN local para este dispositivo. Varios clientes corporativos ofréceno como axuste, pero debilita unha fronteira deliberada. Pídao como unha excepción documentada cun propietario e unha data de revisión. Un interruptor por dispositivo ao que ninguén volve é a forma en que unha política defensiva desaparece en silencio.
Onde a política debe manterse, mova a carga de traballo en lugar de pelexar coa ruta. Unha rede transparente cunha subrede e unha porta de enlace explícitas pon os colectores na ligazón local, unha carga de traballo Linux execútase detrás do proxy da máquina virtual, e unha máquina virtual separada co seu propio cliente conserva a súa propia política. Escolla unha a propósito e probea desde dentro do colector, porque é aí onde se orixina a petición do usuario.