Per què un contenidor macvlan no pot respondre a un client VPN

Imagineu un amfitrió Linux que acaba un VPN i també executa un contenidor en una xarxa macvlan. La LAN és 192.168.60.0/24, el contenidor té 192.168.60.210 i els clients VPN arriben des de 10.95.0.0/24. El client arriba al servei, la resposta no torna mai i totes les regles de tallafoc de l’amfitrió semblen correctes. Dues restriccions separades produeixen aquest símptoma, i arreglar-ne una deixa l’altra al seu lloc.

Dues restriccions, un símptoma

La primera restricció és l’aïllament: el controlador macvlan de Docker no permet que un contenidor parli amb el seu propi amfitrió a través de la interfície pare. El trànsit entre la pila de l’amfitrió i el contenidor no té camí, per molt que s’escriguin les rutes de l’amfitrió.

La segona restricció és el camí de tornada. La passarel·la per defecte del contenidor sol ser el router de la LAN, així que una resposta adreçada a un client VPN surt per aquest router. Si el router no té cap ruta de tornada al grup de VPN, la resposta es descarta en algun punt intermedi.

Aquestes dues fallades es veuen idèntiques des del client: una petició que arriba i una resposta que no arriba mai. Necessiten reparacions diferents, i una regla masquerade àmplia pot amagar quina de les dues encara està trencada. Per això la primera prova és una captura a la banda del contenidor i no un altre canvi de tallafoc. Si la petició no hi apareix mai, la restricció que hi ha en joc és l’aïllament.

Construïu el calaix de l’amfitrió, de manera estreta

Una segona interfície macvlan a l’amfitrió, connectada al mateix pare en mode pont, dona a la pila de l’amfitrió una identitat pròpia en aquest segment de la LAN. Reserveu-li una adreça fora del pool DHCP i fora del rang del contenidor, i encamineu-hi només el contenidor.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

La primera ordre crea la interfície en mode pont, que és el valor per defecte documentat per a aquest controlador i el mode que voleu per al trànsit entre amfitrió i contenidor. La segona assigna un /32 perquè l’adreça no xoqui amb el prefix de la LAN, i la quarta envia només l’adreça del contenidor a través del calaix.

No redirigiu tota la LAN per la interfície nova. La ruta connectada ordinària es queda com està, i la ruta de l’amfitrió és deliberadament estreta perquè un contenidor guanyi un camí sense que la resta del segment canviï de comportament. Una ruta per defecte apuntada al calaix seria un disseny diferent amb conseqüències diferents. Manteniu-la específica i el radi d’impacte continua sent petit.

Aquestes ordres canvien la configuració de xarxa en un amfitrió en funcionament. En un aparell o una plataforma gestionada, feu servir el mecanisme de configuració compatible d’aquesta plataforma, perquè un canvi interactiu a l’intèrpret d’ordres root pot no sobreviure a una actualització.

Decidiu com es preserva l’origen

Amb el calaix al seu lloc, el contenidor pot arribar a l’amfitrió, i la pregunta passa a ser quina adreça d’origen porta la resposta. Preservar l’origen VPN original és el model més net: el contenidor veu l’adreça real del client i els registres i les regles d’accés del servei la poden fer servir.

Perquè això funcioni, la configuració de xarxa del contenidor ha d’enviar el trànsit de 10.95.0.0/24 cap a 192.168.60.250 com a passarel·la per a aquest camí. Això és una configuració de ruta o de passarel·la compatible dins de la configuració pròpia del contenidor, no un truc de la banda de l’amfitrió. Confirmeu-ho des de dins del contenidor en lloc de suposar que la configuració ha tingut efecte. Una passarel·la per defecte que encara apunta al router de la LAN continuarà enviant respostes al mateix forat.

Si el disseny aprovat, en canvi, amaga els orígens VPN, limiteu la traducció de manera estreta: el grup VPN real, el calaix com a interfície de sortida i el contenidor i el servei concrets.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Feu coincidir el calaix com a interfície de sortida, no el túnel. Una regla que anomena el túnel com a interfície de sortida no coincidirà amb un paquet dirigit cap al contenidor, i aquest és l’error que sol contenir aquesta mena de muntatge. Manteniu la regla tan estreta com la frase anterior i reviseu-la quan canviï el grup.

Verifiqueu des del client, no des de l’amfitrió

Una petició des del mateix amfitrió, lligada a l’adreça del calaix, demostra que el calaix pot arribar al contenidor. No demostra que el contenidor pugui retornar trànsit a un origen preservat 10.95.0.x, perquè l’adreça d’origen d’aquesta prova és la del mateix calaix.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

La primera ordre prova el tram de l’amfitrió al contenidor, i la segona mostra què creua realment el calaix mentre un client VPN real fa la petició. Mireu l’adreça d’origen a l’entrada i si apareix una resposta amb el mateix flux.

Cal tenir l’encaminament habilitat a l’amfitrió, i el camí de reenviament necessita un permís per al grup VPN cap al calaix al port del servei, a més de les respostes establertes. Una regla INPUT de l’amfitrió no autoritza el trànsit reenviat, i aquesta és una causa habitual que el paquet es descarti després que l’encaminament sembli correcte.

Executeu l’aplicació real amb credencials reals i comproveu després que un segon servei no relacionat al mateix contenidor encara us rebutja. Si l’única manera de fer-ho funcionar era obrir totes les regles de reenviament, el disseny no està acabat. Anoteu també quina adreça d’origen ha registrat el servei, perquè és la que faran servir les seves pròpies regles d’accés d’ara endavant.