Per què un contenidor de Docker no pot arribar als amfitrions darrere la VPN

Un contenidor que no pot arribar enlloc darrere la VPN corporativa sol viure en un espai de noms de xarxa diferent del túnel. Les rutes, els servidors DNS i les marques del tallafoc del client de l’amfitrió pertanyen a la seva pila; un contenidor de xarxa de pont té la seva. Aquest sol fet explica la majoria d’informes que arriben a un equip de plataforma, i també és la raó per la qual «la VPN està trencada» i «Docker evita la VPN» poden ser totes dues incorrectes alhora. Dues configuracions molt diferents s’amaguen darrere d’un símptoma, així que identifiqueu quina teniu abans de canviar cap paràmetre.

Esbrineu quin espai de noms posseeix el túnel

A Docker Desktop per a macOS o Windows, els contenidors s’executen dins d’una màquina virtual Linux. Un client VPN instal·lat a l’escriptori crea un túnel al sistema operatiu de l’escriptori, i la màquina virtual no el veu mai. Cap configuració del contenidor ho arregla, perquè la interfície que necessitaria el contenidor no existeix en absolut al seu espai de noms de xarxa.

En un amfitrió Linux el túnel viu a l’espai de noms de l’amfitrió, i els contenidors de pont normalment hi arriben a través de la taula d’encaminament de l’amfitrió amb NAT d’origen aplicat a la sortida. Quan aquest camí falla, la causa sol ser la política de reenviament, el filtratge de camí invers o una subxarxa superposada més que una ruta absent. Confirmeu en quin dels dos mons sou abans de llegir més:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

La diferència entre aquestes dues taules d’encaminament és tot el problema en una pantalla. Si la vista de l’amfitrió conté la interfície del túnel i la vista del pont no, esteu veient aïllament d’espais de noms, i tota la resta és una elecció sobre com creuar-lo.

La xarxa de l’amfitrió és una prova, no un disseny

Executar un contenidor amb la xarxa de l’amfitrió, que Docker documenta com a compartir l’espai de noms de xarxa de l’amfitrió, fa que hereti directament la interfície del túnel i les seves rutes. Si la mateixa petició llavors té èxit, la teoria de les rutes queda confirmada i la fallada és aïllament d’espais de noms, no credencials, DNS o una regla d’accés.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Mantingueu-ho com a diagnòstic. La xarxa de l’amfitrió renuncia a la publicació de ports i a la major part de l’aïllament que volíeu d’un contenidor, i a Docker Desktop «host» significa la màquina virtual, no l’escriptori, així que un èxit o un fracàs allà us pot enganyar si oblideu a quin amfitrió us adreçàveu.

Un dispositiu tun i els privilegis que comporta

Un client VPN dins del contenidor necessita un dispositiu de túnel i permís per configurar-lo. La drecera habitual és --privileged, que atorga tots els dispositius i relaxa la política de seguretat a tot el contenidor. Això és molt més del que demana aquesta feina, i costa de justificar en una revisió.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

La forma més estreta assigna l’únic node de dispositiu i només afegeix la capacitat d’administració de xarxa. Carregueu primer el mòdul a l’amfitrió perquè el node existeixi. Si el contenidor arrenca i el client informa que no pot obrir el dispositiu de túnel, reviseu l’assignació abans de sospitar del perfil, perquè aquest error sol ser literal.

Aquest disseny també significa que el client s’executa per contenidor. És la resposta correcta quan cada càrrega de treball necessita el seu propi túnel, i la incorrecta quan només volíeu que el túnel de l’amfitrió fos visible, que és el que l’equip de plataforma probablement suposava que feu.

El NAT del pont canvia la font que veu la VPN

Amb el pont predeterminat, el trànsit de sortida del contenidor es tradueix a l’adreça de l’amfitrió. Darrere una VPN, el costat corporatiu veu per tant l’adreça del túnel de l’amfitrió i no la del contenidor, les regles d’accés per origen es comporten com si l’amfitrió hagués fet la petició, i dos contenidors esdevenen indistingibles per al servidor VPN.

macvlan o ipvlan dona al contenidor una adreça LAN en lloc seu, cosa que ajuda al descobriment a la LAN i fa que el contenidor sembli un igual al segment. També evita completament el túnel de l’amfitrió, així que aquest contenidor no arribarà als prefixos només-VPN tret que la VPN també sigui accessible des d’aquella LAN.

Totes dues formes són legítimes; responen a requisits diferents. Si el requisit és «aquest contenidor ha d’arribar a un servei només-VPN», trieu entre encaminar a través de l’amfitrió i acabar el túnel dins del contenidor. Escriviu aquesta elecció abans del desplegament, no després de la primera petició fallida. Trieu el que trieu, anoteu l’adreça d’origen que veurà l’extrem remot, perquè és el que mostraran les seves regles d’accés i els seus registres. Un disseny que no pot declarar aquesta adreça no està acabat.

El DNS segueix el dimoni, no el túnel

Un contenidor obté la seva configuració de resolució en arrencar, copiada del dimoni o de la imatge. Les adreces que la VPN envia després de connectar-se arriben massa tard per a aquesta còpia, i s’envien al resolutor de l’amfitrió i no al contenidor.

Definiu el resolutor explícitament per al servei, o apunteu-lo a un resolutor intern accessible a través del túnel. Un contenidor que resol un nom privat a una adreça pública sol fer servir un resolutor públic, no pateix una ruta trencada, i la correcció pertoca al fitxer compose o a la configuració del dimoni.

El mateix raonament s’aplica a la qüestió de l’adreça de sortida. Si cada contenidor ha d’aparèixer des d’una adreça VPN diferent, un sol túnel d’amfitrió no ho pot lliurar perquè el NAT els col·lapsa en una sola font. Les formes viables són un client a l’espai de noms de cada contenidor o un sidecar que posseeix el túnel i comparteix la seva pila, i totes dues canvien com s’adreça l’aplicació.

Llista de comprovació abans de tancar el tiquet: identifiqueu l’espai de noms que posseeix el túnel, demostreu el camí amb la xarxa de l’amfitrió, assigneu només el dispositiu tun que necessiteu, recordeu l’adreça d’origen després del NAT, definiu el resolutor explícitament i tracteu les adreces de sortida per contenidor com una decisió d’arquitectura i no com una bandera.