Contenidors Windows i VPN: per què falla la xarxa local
Un contenidor Windows fa servir la taula d'encaminament de l'amfitrió, així que una VPN que bloqueja la subxarxa local s'endú amb ella el prefix del contenidor. El mode Linux pren un altre camí.
En un sol portàtil, amb un sol client VPN connectat, els contenidors Linux continuen comunicant-se entre ells i els contenidors Windows s'aturen. La imatge no és la variable; el camí que fan els paquets fins a l'amfitrió sí que ho és. Els contenidors Windows a la xarxa predeterminada manlleva la taula d'encaminament i la traducció de l'amfitrió, de manera que una política que canvia l'encaminament de l'amfitrió també els canvia a ells. Confirmeu-ho amb una consulta de rutes abans de reinstal·lar res.
On entren els paquets d'un contenidor Windows a l'amfitrió
Un contenidor a la xarxa predeterminada nat obté una adreça d'un prefix del servei Host Networking Service, normalment en algun lloc dins de 172.16.0.0/12, i arriba a l'amfitrió mitjançant un adaptador virtual. L'amfitrió posseeix la ruta d'aquest prefix i tradueix el trànsit cap a l'adaptador que sigui actiu. No hi ha cap màquina virtual separada al mig d'aquest camí.
Aquest disseny és el que fa mecànica la fallada. Quan el contenidor envia un paquet, l'amfitrió fa una consulta de ruta per al prefix del contenidor. La ruta que guanyi és on va el paquet, i el contenidor no hi té cap opinió.
Què canvia el client VPN en aquest camí
Un client corporatiu sovint instal·la un conjunt ampli de rutes i un filtre que denega l'accés a la subxarxa local mentre el túnel és actiu. La intenció és defensiva: una xarxa local compromesa no ha d'arribar a una màquina protegida. L'efecte secundari és que la ruta de l'amfitrió cap al prefix del contenidor ja no és la xarxa NAT local.
En canvi, la consulta coincideix amb el túnel i el paquet es lliura a la porta d'enllaç, que mai no ha sentit a parlar d'aquella adreça de contenidor. El ping falla, l'aplicació es queda sense resposta i el contenidor sembla trencat mentre la icona de la VPN brilla. Mireu la taula de l'amfitrió mentre esteu connectats i la ruta en competència és 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 |
Per què els contenidors Linux es comporten diferent
El motor Linux executa els contenidors dins d'una màquina virtual lleugera, i les connexions sortints d'aquesta màquina les obre un proxy del costat de l'amfitrió en nom del contenidor. L'amfitrió inicia el sòcol, així que la regla de la VPN sobre el prefix del contenidor no s'hi aplica de la mateixa manera, i la càrrega de treball continua arribant a la xarxa.
Aquesta diferència també explica per què les receptes de Linux no es poden traslladar. Un contenidor Linux que necessita el seu propi túnel rep un dispositiu TUN més la capacitat NET_ADMIN. Els contenidors Windows no exposen cap interfície com a dispositiu, així que aquest patró no té equivalent en aquell costat.
Demostreu la ruta i després trieu un disseny
Recolliu proves de l'amfitrió, no del contenidor, perquè és l'amfitrió qui fa la consulta:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Executeu la sortida de rutes una vegada abans que la VPN es connecti i una vegada després. Si a la segona sortida el prefix del contenidor apunta a l'adaptador del túnel, el diagnòstic és complet i reiniciar els contenidors no ajudarà.
La primera opció és una decisió de política: pregunteu al propietari de la xarxa si es pot permetre l'accés a la LAN local per a aquest dispositiu. Diversos clients corporatius ho ofereixen com a paràmetre, però debilita una frontera deliberada. Demaneu-ho com una excepció documentada amb un propietari i una data de revisió. Un commutador per dispositiu que ningú no revisa és com una política defensiva desapareix en silenci.
On la política s'ha de mantenir, moveu la càrrega de treball en lloc de lluitar contra la ruta. Una xarxa transparent amb una subxarxa i una porta d'enllaç explícites posa els contenidors a l'enllaç local, una càrrega de treball Linux s'executa darrere del proxy de la màquina virtual, i una màquina virtual separada amb el seu propi client conserva la seva pròpia política. Trieu-ne una deliberadament i proveu-la des de dins del contenidor, perquè és aquí on s'origina la petició de l'usuari.