El host llega al par IPsec, el contenedor de Docker no

Hace ping al host remoto desde la máquina Linux y responde, así que el túnel funciona. El contenedor de al lado sigue agotando el tiempo, y el siguiente paso natural es reiniciar Docker. Un contenedor en red puente suele arrancar con otra dirección de origen y entra al host por reenvío en lugar de por la ruta de salida propia de la aplicación del host, así que la prueba correcta midió otro paquete. Para un túnel strongSwan basado en políticas, una ruta normal hacia la subred remota no basta cuando el paquete reenviado no coincide con la política IPsec instalada.

El recorrido siguiente sigue un destino a través de dos orígenes, leyendo el estado antes de cambiar nada.

Empiece por un destino y dos orígenes

Elija primero un servicio conocido por IP, para no estar depurando DNS al mismo tiempo. Anote tres datos: el prefijo puente del contenedor, la dirección de origen de la petición del host que funcionó y los selectores de tráfico local y remoto negociados para el túnel. Esos tres números explican casi todos los casos de este síntoma.

Luego repita la petición fallida desde dentro del contenedor y capture el origen que realmente usa. Si esa dirección no está cubierta por el selector local, ya conoce el resultado, y ninguna recreación del contenedor lo cambiará.

Lea las políticas antes de tocar Docker

Las comprobaciones de host de solo lectura cubren las decisiones de encaminamiento, la base de datos de políticas y las reglas que eligen entre ellas:

ip rule show
ip route show table all
ip xfrm policy

El listado de políticas muestra selectores y dirección sin necesidad de un volcado de estado IPsec lleno de material de clave, por eso es seguro pegarlo en un ticket. Busque un selector local que cubra la dirección del host pero no el prefijo puente. Compruebe también el solapamiento: una ruta de contenedor que trata el destino remoto como local nunca producirá el paquete reenviado que espera, y el túnel se lleva la culpa. Guarde ese listado junto a la dirección de origen del contenedor, porque esas dos cosas juntas son toda la comparación.

Si falta el prefijo del contenedor, deténgase y decida la arquitectura antes de tocar nada más. El resto de este recorrido supone que han acordado qué dirección de origen debe aparecer en el cable.

Compruebe filtrado y traducción en orden

El cortafuegos puente de Linux de Docker puede bloquear el reenvío con independencia de IPsec. Con el backend iptables, inspeccione la ruta FORWARD y las decisiones DOCKER-USER, recordando que una regla añadida tras un veredicto anterior puede no ejecutarse nunca. El backend nftables se integra de otra forma, así que no cree una cadena DOCKER-USER solo porque un ejemplo de iptables la nombrara; compruebe qué backend usa realmente su demonio.

Luego compruebe la traducción de origen. Una regla MASQUERADE amplia puede convertir un paquete que antes coincidía con un selector IPsec en uno que ya no coincide, y el fallo parece exactamente un problema de encaminamiento. La guía de reenvío de strongSwan documenta la exención de NAT necesaria antes de esa traducción para el tráfico que ya coincide con una política.

Esa exención no es una forma de añadir al túnel un origen de contenedor no cubierto. Solo protege el tráfico que ya encaja en el diseño, así que resuelva primero las cuestiones de selector y ruta de vuelta, y luego haga que NAT y filtrado coincidan con la respuesta. Si se descubre ampliando la exención, lo que hay que cambiar es el selector, no la regla NAT.

Luego decida enrutado o traducido

Una subred de contenedor enrutada exige que ambos pares acepten esa subred y una ruta de vuelta remota hacia ella, lo que suele implicar un cambio de selector en ambos extremos y una conversación con quien posee el lado lejano. Un diseño traducido a propósito debe presentar en cambio una dirección cubierta por la política en la etapa de consulta relevante, lo que suele implicar una regla estrecha y documentada en lugar de un MASQUERADE por defecto.

Ninguna de las dos disposiciones se sigue automáticamente del túnel funcionante del host, y elegir entre ellas es una decisión de diseño con un responsable. Anote cuál eligió, porque el siguiente ingeniero la volverá a deducir de los contadores del cortafuegos.

Vigile también el fallo híbrido: la mitad del conjunto de reglas traducida y la otra mitad no, lo que produce un éxito intermitente que depende del puerto de destino y no de nada de la red.

Verifique con una conexión nueva, no con un reinicio

Use una conexión nueva de la aplicación mientras observa contadores estrechos del cortafuegos y el receptor remoto, para que cada observación tenga un origen. Un reinicio de Docker puede cambiar el estado de las reglas y también alterará cargas de trabajo, lo que le cuesta la señal limpia que quería obtener.

El resultado duradero son cuatro afirmaciones que puede mostrar: el origen del contenedor, la ruta protegida correspondiente, el reenvío permitido y una respuesta que vuelve. Cuando las cuatro se cumplen, el contenedor llega al par por la misma razón que el host.