L’amfitrió arriba al parell IPsec, però el contenidor Docker no

Feu ping a l’amfitrió remot des de la màquina Linux i respon, així que el túnel funciona. El contenidor del costat encara es queda sense temps, i el següent pas natural és reiniciar Docker. Un contenidor en xarxa pont normalment arrenca amb una adreça d’origen diferent i entra a l’amfitrió per reenviament en lloc de pel camí de sortida propi de l’aplicació de l’amfitrió, així que la prova correcta va mesurar un paquet diferent. Per a un túnel strongSwan basat en polítiques, una ruta ordinària cap a la subxarxa remota no n’hi ha prou quan el paquet reenviat no encaixa amb la política IPsec instal·lada.

El recorregut següent segueix una destinació a través de dues fonts, llegint l’estat abans de canviar res.

Comenceu amb una destinació i dues fonts

Trieu primer un servei conegut per IP, perquè no estigueu depurant DNS alhora. Anoteu tres fets: el prefix pont del contenidor, l’adreça d’origen de la petició de l’amfitrió que va funcionar i els selectors de trànsit local i remot negociats per al túnel. Aquests tres números expliquen gairebé tots els casos d’aquest símptoma.

Després repetiu la petició fallida des de dins del contenidor i captureu la font que realment fa servir. Si aquesta adreça no la cobreix el selector local, ja coneixeu el resultat, i cap recreació del contenidor no el canviarà.

Llegiu les polítiques abans de tocar Docker

Les comprovacions d’amfitrió només de lectura cobreixen les decisions d’encaminament, la base de dades de polítiques i les regles que trien entre elles:

ip rule show
ip route show table all
ip xfrm policy

El llistat de polítiques mostra selectors i direcció sense necessitat d’un buidatge d’estat IPsec ple de material de clau, i per això és segur enganxar-lo en un tiquet. Busqueu un selector local que cobreixi l’adreça de l’amfitrió però no el prefix pont. Comproveu també el solapament: una ruta de contenidor que tracta la destinació remota com a local mai produirà el paquet reenviat que espereu, i el túnel se’n porta la culpa. Guardeu aquest llistat al costat de l’adreça d’origen del contenidor, perquè aquestes dues coses juntes són tota la comparació.

Si falta el prefix del contenidor, atureu-vos i decidiu l’arquitectura abans de tocar res més. La resta d’aquest recorregut assumeix que heu acordat quina adreça d’origen ha d’aparèixer al fil.

Comproveu filtratge i traducció en ordre

El tallafoc pont de Linux de Docker pot bloquejar el reenviament independentment d’IPsec. Amb el rerefons iptables, inspeccioneu el camí FORWARD i les decisions DOCKER-USER, recordant que una regla afegida després d’un veredicte anterior pot no executar-se mai. El rerefons nftables s’integra diferent, així que no creeu una cadena DOCKER-USER només perquè un exemple d’iptables l’anomenava; comproveu quin rerefons fa servir realment el vostre dimoni.

Després comproveu la traducció d’origen. Una regla MASQUERADE àmplia pot convertir un paquet que abans encaixava amb un selector IPsec en un que ja no hi encaixa, i la fallada sembla exactament un problema d’encaminament. La guia de reenviament de strongSwan documenta l’exempció de NAT necessària abans d’aquesta traducció per al trànsit que ja encaixa amb una política.

Aquesta exempció no és una manera d’afegir al túnel una font de contenidor no coberta. Només protegeix el trànsit que ja encaixa amb el disseny, així que resoleu primer les qüestions de selector i camí de tornada, i després feu que NAT i filtratge coincideixin amb la resposta. Si us trobeu ampliant l’exempció, el que cal canviar és el selector, no la regla NAT.

Després decidiu encaminat o traduït

Una subxarxa de contenidor encaminada requereix que tots dos extrems acceptin aquesta subxarxa i un camí de tornada remot cap a ella, cosa que normalment vol dir un canvi de selector als dos extrems i una conversa amb qui posseeix el costat llunyà. Un disseny traduït deliberadament ha de presentar en canvi una adreça coberta per la política a l’etapa de consulta rellevant, cosa que normalment vol dir una regla estreta i documentada en lloc d’un MASQUERADE per defecte.

Cap de les dues disposicions no es desprèn automàticament del túnel funcionant de l’amfitrió, i triar-ne una és una decisió de disseny amb un responsable. Anoteu quina heu triat, perquè el proper enginyer, si no, la tornarà a deduir dels comptadors del tallafoc.

Vigileu també la fallada híbrida: la meitat del conjunt de regles traduïda i l’altra meitat no, cosa que produeix un èxit intermitent que depèn del port de destinació i no de res de la xarxa.

Verifiqueu amb una connexió nova, no amb un reinici

Feu servir una connexió nova d’aplicació mentre observeu comptadors estrets del tallafoc i el receptor remot, perquè cada observació tingui una font. Un reinici de Docker pot canviar l’estat de les regles i també destorbarà les càrregues de treball, cosa que us costa el senyal net que volíeu obtenir.

El resultat durador són quatre afirmacions que podeu mostrar: la font del contenidor, el camí protegit corresponent, el reenviament permès i una resposta que torna. Quan les quatre es compleixen, el contenidor arriba al parell pel mateix motiu que l’amfitrió.