DNAT en un contenidor VPN: reenviament, no INPUT

La petició arriba adreçada a la IP del túnel i surt del mateix contenidor adreçada a un servei veí. Entre aquests dos moments, el DNAT va reescriure la destinació i el paquet va deixar de ser entrada per al contenidor VPN. Ara és trànsit reenviat, jutjat per una regla diferent. Aquest canvi explica per què una regla de tallafocs que sembla correcta per a l'adreça del túnel no té cap efecte sobre la connexió traduïda.

Seguiu el paquet després de la traducció

Agafeu un pool de clients 10.90.0.0/24 i una adreça de túnel 10.90.0.1. Dos contenidors seuen en un sol bridge: 192.0.2.2 executa la VPN i 192.0.2.3 executa l'aplicació. Un client es connecta a 10.90.0.1:8080, i la regla DNAT de l'espai de noms del contenidor VPN ho reescriu a l'adreça i el port reals de l'aplicació. Després, una ruta envia el paquet pel bridge. Aquestes adreces són il·lustratives, no una recepta de desplegament.

El port on l'aplicació escolta realment pot diferir de qualsevol port publicat a l'amfitrió. Llegiu l'oïdor dins del contenidor en lloc de suposar que tots dos números coincideixen.

El permís pertany al camí de reenviament

El contenidor VPN necessita reenviament d'IP i una decisió de reenviament limitada al pool de clients, l'adreça de l'aplicació i el port previst. Les respostes establertes necessiten la seva pròpia autorització. Una regla que coincideix amb l'adreça original del túnel no coincidirà després del DNAT, perquè la destinació ja ha canviat. Una autorització INPUT és el ganxo equivocat per a trànsit que ja no s'adreça a aquest amfitrió.

Manteniu l'abast estret: un rang d'origen, una destinació, un servei. Una regla de reenviament permissiva és més fàcil d'escriure i molt més difícil de defensar després.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Les cadenes de Docker no són les cadenes del vostre contenidor

Les regles dins de l'espai de noms del contenidor no són les regles de l'amfitrió Docker. Quan el trànsit creua de la interfície del túnel al bridge, el tallafocs del bridge de l'amfitrió pot prendre una altra decisió. Amb el rerefons iptables de Docker, les cadenes de reenviament documentades i els punts de coincidència posteriors al DNAT són on apareix aquesta decisió.

La referència de tallafocs de Docker descriu aquestes cadenes i la coincidència posterior al DNAT. No arregleu una acceptació que falta desactivant la gestió del tallafocs de Docker o fent permissiva cada cadena, perquè això elimina la frontera que esteu intentant utilitzar.

Feu del camí de tornada una elecció deliberada

Si es conserva l'adreça d'origen, l'aplicació veu 10.90.0.x i ha d'encaminar les respostes de tornada a través del contenidor VPN. Si no, la seva passarel·la Docker habitual les enviarà a l'amfitrió, que no posseeix el túnel. L'alternativa és una traducció d'origen estretament limitada al contenidor VPN, que simplifica la resposta però amaga el client a l'aplicació. Trieu a propòsit i anoteu quina opció heu triat.

Proveu una connexió permesa nova des d'un client corrent, i després confirmeu que els ports no relacionats continuen tancats. Quan un paquet desaparegui, inspeccioneu l'espai de noms de la VPN, l'espai de noms de l'aplicació i el registre propi de l'aplicació. Un ping a la passarel·la del bridge no és una prova d'acceptació del servei.

Manteniu les regles a la configuració d'inici compatible del contenidor, perquè les edicions interactives desapareixen quan es recrea. La publicació d'un port a l'amfitrió és un camí d'exposició diferent i no cal només perquè el servei sigui abastable a través del túnel.