O host chega ao par IPsec, o contedor de Docker non

Fai ping ao host remoto desde a máquina Linux e responde, así que o túnel funciona. O contedor de ao lado segue esgotando o tempo, e o seguinte paso natural é reiniciar Docker. Un contedor en rede ponte adoita arrincar cunha dirección de orixe distinta e entra no host por reenvío en lugar de polo camiño de saída propio da aplicación do host, así que a proba correcta mediu outro paquete. Para un túnel strongSwan baseado en políticas, unha ruta normal cara á subrede remota non abonda cando o paquete reenviado non coincide coa política IPsec instalada.

O percorrido seguinte segue un destino a través de dúas orixes, lendo o estado antes de cambiar nada.

Comece por un destino e dúas orixes

Escolla primeiro un servizo coñecido por IP, para non estar depurando DNS ao mesmo tempo. Anote tres datos: o prefixo ponte do contedor, a dirección de orixe da petición do host que funcionou e os selectores de tráfico local e remoto negociados para o túnel. Esas tres cifras explican case todos os casos deste síntoma.

Logo repita a petición fallida desde dentro do contedor e capture a orixe que realmente usa. Se esa dirección non está cuberta polo selector local, xa coñece o resultado, e ningunha recreación do contedor o cambiará.

Lea as políticas antes de tocar Docker

As comprobacións de host de só lectura cobren as decisións de encamiñamento, a base de datos de políticas e as regras que elixen entre elas:

ip rule show
ip route show table all
ip xfrm policy

A listaxe de políticas mostra selectores e dirección sen necesidade dun volcado de estado IPsec cheo de material de clave, por iso é seguro pegalo nun ticket. Busque un selector local que cubra a dirección do host pero non o prefixo ponte. Comprobe tamén o solapamento: unha ruta de contedor que trata o destino remoto como local nunca producirá o paquete reenviado que espera, e o túnel leva a culpa. Garde esa listaxe xunto á dirección de orixe do contedor, porque esas dúas cousas xuntas son toda a comparación.

Se falta o prefixo do contedor, detéñase e decida a arquitectura antes de tocar nada máis. O resto deste percorrido supón que acordaron que dirección de orixe debe aparecer no cable.

Comprobe filtrado e tradución por orde

A devasa ponte de Linux de Docker pode bloquear o reenvío con independencia de IPsec. Co backend iptables, inspeccione a ruta FORWARD e as decisións DOCKER-USER, lembrando que unha regra engadida tras un veredicto anterior pode non executarse nunca. O backend nftables intégrase doutro xeito, así que non cree unha cadea DOCKER-USER só porque un exemplo de iptables a nomease; comprobe que backend usa realmente o seu demonio.

Logo comprobe a tradución de orixe. Unha regra MASQUERADE ampla pode converter un paquete que antes coincidía cun selector IPsec nun que xa non coincide, e o fallo parece exactamente un problema de encamiñamento. A guía de reenvío de strongSwan documenta a exención de NAT necesaria antes desa tradución para o tráfico que xa coincide cunha política.

Esa exención non é unha forma de engadir ao túnel unha orixe de contedor non cuberta. Só protexe o tráfico que xa encaixa no deseño, así que resolva primeiro as cuestións de selector e camiño de volta, e despois faga que NAT e filtrado coincidan coa resposta. Se se atopa ampliando a exención, o que hai que cambiar é o selector, non a regra NAT.

Logo decida encamiñado ou traducido

Unha subrede de contedor encamiñada esixe que ambos os pares acepten esa subrede e un camiño de volta remoto cara a ela, o que adoita implicar un cambio de selector nos dous extremos e unha conversa con quen posúe o lado afastado. Un deseño traducido a propósito debe presentar en cambio unha dirección cuberta pola política na etapa de consulta relevante, o que adoita implicar unha regra estreita e documentada en lugar dun MASQUERADE por defecto.

Ningunha das dúas disposicións se segue automaticamente do túnel funcionante do host, e elixir entre elas é unha decisión de deseño cun responsable. Anote cal escolleu, porque o seguinte enxeñeiro volveraa deducir dos contadores da devasa.

Vixíe tamén o fallo híbrido: a metade do conxunto de regras traducida e a outra metade non, o que produce un éxito intermitente que depende do porto de destino e non de nada da rede.

Verifique cunha conexión nova, non cun reinicio

Use unha conexión nova da aplicación mentres observa contadores estreitos da devasa e o receptor remoto, para que cada observación teña unha orixe. Un reinicio de Docker pode cambiar o estado das regras e tamén alterará cargas de traballo, o que lle custa o sinal limpo que quería obter.

O resultado duradeiro son catro afirmacións que pode mostrar: a orixe do contedor, a ruta protexida correspondente, o reenvío permitido e unha resposta que volve. Cando as catro se cumpren, o contedor chega ao par polo mesmo motivo que o host.