El trànsit dels contenidors Docker evita la VPN de l'amfitrió: com comprovar-ho
Una VPN de l'amfitrió només cobreix l'espai de noms de l'amfitrió. Feu servir aquestes comprovacions per saber si el trànsit dels contenidors del pont entra al túnel o surt directament.
El navegador de l'amfitrió mostra l'adreça de sortida de la VPN, el contenidor informa de la vostra connexió de casa i algú ho anomena fuita. No s'ha filtrat res. Un túnel de l'amfitrió és un conjunt d'interfícies, rutes i regles que pertanyen a l'espai de noms de xarxa de l'amfitrió, i un contenidor en un pont és un altre espai de noms amb la seva pròpia ruta per defecte. He estat en un stack de Compose on el client VPN portava setmanes connectat i no hi havia entrat mai ni un paquet de contenidor.
Comproveu l'espai de noms abans que la icona de la safata
Els espais de noms són tot l'argument. Quan Docker engega un contenidor en una xarxa de pont, crea un espai de noms de xarxa, hi connecta un extrem d'una parella veth i dóna a aquest espai de noms una adreça i una ruta per defecte. La interfície del túnel, digui's com es digui, viu a l'espai de noms de l'amfitrió. El trànsit dins del contenidor no la pot veure, i cap paràmetre del client ho canvia des de fora.
Dos moviments admesos us treuen de l'aïllament. --network host col·loca el contenidor dins de l'espai de noms de l'amfitrió, de manera que hereta les rutes de l'amfitrió i, per tant, el túnel. --network container:vpn comparteix l'espai de noms d'un altre contenidor, i així és com la majoria de dissenys sidecar envien una càrrega de treball a través d'un contenidor VPN. Tots dos són opcions explícites; normalment només una d'elles és el que volia dir la persona que desplega.
El mode amfitrió no és una actualització gratuïta. El contenidor deixa de tenir adreça pròpia, la publicació de ports deixa d'aplicar-se i un procés que hi tingui NET_ADMIN pot reescriure l'encaminament de l'amfitrió. Acceptar-ho pot ser la decisió correcta. Suposar que ja està activat és com la gent passa una vetllada depurant un túnel que mai no era al camí.
Seguiu el paquet fora del pont
Un contenidor del pont envia el seu paquet a la seva porta d'enllaç per defecte, que és la interfície del pont a l'amfitrió. L'amfitrió reenvia el paquet i, en la configuració per defecte, tradueix l'adreça d'origen per la seva abans que el paquet surti. Aquest pas de traducció és el que derrota la política en silenci.
Quan el paquet arriba al punt final del túnel ja porta l'adreça de l'amfitrió. Qualsevol regla, ruta de política o decisió de túnel dividit basada en l'adreça original del contenidor deixa de coincidir, i dos contenidors destinats a sortir per sortides diferents no es poden distingir només per l'origen. Si necessiteu encaminament per contenidor, la decisió ha de passar abans de la traducció o dins d'un espai de noms que controleu.
Docker manté aquestes regles ell mateix, amb el backend de firewall amb què s'hagi configurat el dimoni. Les regles escrites a mà fora del ganxo admès per al trànsit reenviat, DOCKER-USER, es poden reordenar o eliminar quan el dimoni es reinicia o l'amfitrió s'actualitza. La documentació de Docker sobre filtratge de paquets mostra l'ordre de les cadenes; el punt pràctic és que cada regla necessita un propietari i un camí de recàrrega que hàgiu provat de debò.
Proveu els dos sistemes per separat
L'evidència d'un espai de noms no diu res sobre l'altre. Una petició executada dins del contenidor VPN demostra que el túnel funciona per a aquell contenidor. No és evidència sobre l'amfitrió, i la mateixa ordre executada des d'un contenidor amb --network host no és evidència sobre el pont.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Després repetiu la prova dins del contenidor real de l'aplicació i no en una imatge semblant. L'aplicació pot portar una ruta extra, una variable d'entorn de proxy o un resolutor diferent, i cada una d'aquestes coses canvia la resposta. Comproveu la resolució de noms i la segona família d'adreces cada vegada: els contenidors en ponts definits per l'usuari resolen a través del resolutor integrat de Docker a 127.0.0.11, i una ruta per defecte IPv6 al pont pot treure trànsit mentre esteu ocupats provant un túnel només IPv4.
Llegiu el patró abans de tocar credencials
Quan l'amfitrió funciona i el contenidor no, la causa és estructural gairebé sempre, i rotar claus o reinstal·lar el client fa perdre una tarda. Ordeneu primer el símptoma i la solució normalment es nomena sola.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
La fila del solapament mereix una frase pròpia. Un perfil VPN que empeny una ruta per a 172.17.0.0/16, o per a una 10.0.0.0/8 que casualment conté el prefix del vostre pont, fa que el túnel reivindiqui la subxarxa dels contenidors, i les respostes a les adreces traduïdes aniran en la direcció equivocada o desapareixeran. Renumerar la xarxa de Docker sol ser més net que acumular excepcions.
Feu explícita la cobertura i després trenqueu-la expressament
Dos dissenys aguanten una revisió. Compartiu l'espai de noms del contenidor VPN i cada càrrega coberta fa servir un sol túnel amb una sola frontera de reinici, cosa que és simple fins que un servei necessita una sortida diferent o el seu propi camí DNS. O bé encamineu la xarxa dels contenidors cap a una passarel·la VPN a l'amfitrió: reenviament activat, el prefix del pont apuntat al túnel, el trànsit de retorn gestionat explícitament. Això compra control per xarxa i us costa un conjunt de regles a mantenir durant les actualitzacions del dimoni i del client.
De qualsevol manera, la prova que importa és el cas de fallada. Atureu el túnel amb una petició de contenidor en vol i mireu on va el paquet. Si torna al camí directe, la cobertura no s'havia aplicat mai, perquè un kill switch del client governa el trànsit propi del client i no els paquets reenviats des d'un pont. Reinicieu després el dimoni i l'amfitrió i confirmeu el resultat una segona vegada; aquest és el moment en què les regles escrites a mà desapareixen.
Abans de donar-ho per fet, confirmeu quatre coses: la interfície del túnel és al mateix espai de noms que el trànsit, la prova del contenidor s'ha executat dins del contenidor real, s'han comprovat la resolució de noms i les dues famílies d'adreces, i la prova de fallada del túnel encara falla tancada. Després anoteu el backend de firewall, la versió del client i el propietari de cada regla. Aquest registre és el que evita que la propera actualització deixi una barreja no documentada de suposicions antigues.