Publicación de portos de Docker fronte á VPN: a onde vai a resposta

Un contedor publicado responde desde o seu propio enderezo antes do NAT inverso. Dous deseños poden manter esa resposta na ruta pública, con custos distintos.

O host segue respondendo por SSH despois de que se levante unha VPN de túnel completo, pero un servizo publicado con Docker na mesma máquina queda mudo. O listener non ten nada malo: o contedor execútase, a asignación de portos existe e o paquete chega. O contedor está san e a petición si o acada. O que cambia é de onde parte a resposta cando Linux escolle a súa ruta, e esa diferenza decide cal dos dous deseños seguintes precisa.

Siga a tupla a través do NAT de destino

Tome un host en 192.0.2.10 que publica TCP 2222 cara a un contedor en 172.30.240.5:22. Unha petición desde 198.51.100.25 tradúcese antes de chegar ao contedor, e o contedor responde como tal.

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

Na decisión de ruta do host a resposta aínda leva o enderezo de orixe do contedor. A tradución inversa restaura máis tarde a tupla publicada, e por iso o paquete parece incorrecto xusto no momento en que se escolle a ruta.

Por que unha regra só para o host non a ve

Unha regra que selecciona a táboa WAN só para paquetes de 192.0.2.10 cobre os propios daemons do host e pasa por alto por completo esta resposta reenviada. O enderezo de orixe da resposta é 172.30.240.5, non o do host.

A corrección excesiva consiste en encamiñar todo desde o contedor pola WAN, o que ademais exime da VPN as conexións saíntes non relacionadas do contedor. É unha política distinta da que se lle pediu, e normalmente sorprende a alguén máis adiante.

A coincidencia posterior ao DNAT é outro hook

A documentación de Docker sobre cortafogos sinala que o filtrado ordinario de usuario ve o destino posterior ao DNAT, así que coincidir o porto publicado 2222 nunha regra normal non é o mesmo que coincidir o porto 22 do contedor. Se a tupla orixinal importa, use o mecanismo de destino orixinal admitido en lugar de adiviñar que porto é visible.

Esta confusión de hooks produce regras que parecen correctas e nunca coinciden. Revise os contadores da propia regra antes de reescribir a política. Unha regra sen ningunha coincidencia dille que se está a avaliar nun lugar ao que o paquete nunca chega.

Deseño A: levar a decisión como estado de conexión

Unha marca de conexión pode levar a decisión de entrada a través da tradución, pero debe restaurarse no paquete antes da busca de ruta que importa. As etapas son:

  1. Reserve un campo de marca e unha prioridade de regra que non choquen con Docker, a VPN nin outro propietario de política.
  2. Identifique só a nova conexión WAN prevista nun punto previo ao DNAT onde o seguimento de conexións estea dispoñible.
  3. Rexistre a decisión na marca de conexión, sen forzar a propia petición orixinal cara á táboa WAN.
  4. Na dirección de resposta, restaure só os seus propios bits de marca no paquete antes do encamiñamento.
  5. Seleccione unha táboa WAN completa coa suficiente antelación para que unha regra da VPN non poida gañar primeiro.

Esa táboa necesita as rutas conectadas reais e a porta de enlace. Tamén necesita un comportamento definido cando falta a ruta. A caída silenciosa ao túnel é o peor resultado, porque a configuración segue parecendo que funciona. No seu lugar, falle de forma pechada e rexístreo.

Deseño B: terminar no host

Un frontend configurado deliberadamente no lado do host, como un proxy TCP ou un proxy inverso diante do contedor, mantén a resposta orixinada no enderezo do host. Entón as regras escritas para o host compórtanse como se espera, e o contedor permanece na súa rede privada.

O custo é outra peza móbil coa súa propia configuración, manexo de enderezos de orixe e controis de acceso. Normalmente é o límite admitido máis simple, e a miúdo é a resposta correcta cando a política de encamiñamento a mantería unha soa persoa que podería marchar.

Verifique o cambio, non a intención

Abra unha conexión autorizada nova desde o lado público e confirme que a resposta sae pola interface prevista. Despois comprobe que unha petición non relacionada iniciada polo contedor segue a VPN.

Non baleire a táboa de conexións da máquina para probar unha regra: as entradas existentes conservan a súa asignación anterior, e o baleirado rompe todo o demais no host. Publicar un porto define a accesibilidade. Non define a ruta da resposta. Escriba o deseño elixido cos seus nomes de táboa, para que a seguinte persoa non teña que redescubrilo durante un incidente.

Artigos relacionados