Publicació de ports de Docker contra la VPN: on va la resposta

L'amfitrió continua responent per SSH després que s'aixequi una VPN de túnel complet, però un servei publicat amb Docker a la mateixa màquina s'emmudeix. El listener no té cap problema: el contenidor funciona, la mapació de ports existeix i el paquet arriba. El contenidor és sa i la petició sí que l'arriba. El que canvia és d'on surt la resposta quan Linux tria la seva ruta, i aquesta diferència decideix quin dels dos dissenys següents necessiteu.

Seguiu la tupla pel NAT de destinació

Preneu un amfitrió a 192.0.2.10 que publica TCP 2222 cap a un contenidor a 172.30.240.5:22. Una petició de 198.51.100.25 es tradueix abans d'arribar al contenidor, i el contenidor respon com a si mateix.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

En la decisió de ruta de l'amfitrió, la resposta encara porta l'adreça d'origen del contenidor. La traducció inversa restaura més tard la tupla publicada, i per això el paquet sembla incorrecte just en el moment en què es tria la ruta.

Per què una regla només per a l'amfitrió no la capta

Una regla que selecciona la taula WAN només per als paquets de 192.0.2.10 cobreix els propis dimonis de l'amfitrió i no capta gens aquesta resposta reenviada. L'adreça d'origen de la resposta és 172.30.240.5, no l'amfitrió.

La correcció excessiva és encaminar-ho tot del contenidor per la WAN, cosa que també eximeix de la VPN les connexions sortints no relacionades del contenidor. És una política diferent de la que us han demanat, i normalment sorprèn algú més endavant.

La coincidència post-DNAT és un altre hook

La documentació de Docker sobre tallafocs assenyala que el filtratge ordinari d'usuari veu la destinació després del DNAT, així que fer coincidir el port publicat 2222 en una regla normal no és el mateix que fer coincidir el port 22 del contenidor. Si la tupla original importa, feu servir el mecanisme de destinació original suportat en lloc d'endevinar quin port és visible.

Aquesta confusió de hooks produeix regles que semblen correctes i no coincideixen mai. Comproveu els comptadors de la mateixa regla abans de reescriure la política. Una regla amb zero impactes us diu que s'avalua en un lloc on el paquet no arriba mai.

Disseny A: portar la decisió com a estat de connexió

Una marca de connexió pot portar la decisió d'entrada a través de la traducció, però s'ha de restaurar al paquet abans de la consulta de ruta que importa. Les etapes són:

1. Reserveu un camp de marca i una prioritat de regla que no xoquin amb Docker, la VPN ni cap altre propietari de política.
2. Identifiqueu només la nova connexió WAN prevista en un punt previ al DNAT on el seguiment de connexions estigui disponible.
3. Registreu la decisió a la marca de connexió, sense forçar la petició original mateixa a la taula WAN.
4. En la direcció de resposta, restaureu només els vostres bits de marca al paquet abans de l'encaminament.
5. Seleccioneu una taula WAN completa prou aviat perquè una regla de la VPN no pugui guanyar primer.

Aquesta taula necessita les rutes connectades reals i la porta d'enllaç. També necessita un comportament definit quan falta la ruta. La caiguda silenciosa al túnel és el pitjor resultat, perquè la configuració encara sembla que funciona. Tanqueu-la en fallada i registreu-ho.

Disseny B: terminar a l'amfitrió

Un frontal configurat deliberadament al costat de l'amfitrió, com ara un proxy TCP o un proxy invers davant del contenidor, manté la resposta originada des de l'adreça de l'amfitrió. Aleshores les regles escrites per a l'amfitrió es comporten com s'espera, i el contenidor es queda a la seva xarxa privada.

El cost és una altra peça mòbil amb la seva pròpia configuració, gestió d'adreces d'origen i controls d'accés. Normalment és el límit suportat més simple, i sovint és la resposta correcta quan la política d'encaminament l'hauria de mantenir una sola persona que podria marxar.

Verifiqueu el canvi, no la intenció

Obriu una connexió autoritzada nova des del costat públic i confirmeu que la resposta surt per la interfície prevista. Després comproveu que una petició no relacionada iniciada pel contenidor encara segueix la VPN.

No buideu la taula de connexions de la màquina per provar una regla: les entrades existents conserven la mapació anterior, i el buidatge trenca tota la resta de l'amfitrió. Publicar un port defineix l'abastabilitat. No defineix el camí de la resposta. Escriviu el disseny triat amb els seus noms de taula, perquè la propera persona no l'hagi de redescobrir durant un incident.