L’host raggiunge il peer IPsec, il container Docker no

Fate ping verso l’host remoto dalla macchina Linux e risponde, quindi il tunnel funziona. Il container accanto continua ad andare in timeout, e il passo successivo naturale è riavviare Docker. Un container su rete bridge parte di solito con un altro indirizzo sorgente ed entra nell’host tramite forwarding invece che tramite il percorso di uscita proprio dell’applicazione sull’host, quindi il test riuscito ha misurato un altro pacchetto. Per un tunnel strongSwan basato su policy, una rotta ordinaria verso la subnet remota non basta quando il pacchetto inoltrato non corrisponde alla policy IPsec installata.

Il percorso seguente segue una destinazione attraverso due sorgenti, leggendo lo stato prima di cambiare qualsiasi cosa.

Partite da una destinazione e due sorgenti

Scegliete prima un servizio noto per IP, così non state debuggando DNS nello stesso momento. Annotate tre fatti: il prefisso bridge del container, l’indirizzo sorgente della richiesta dall’host che ha funzionato e i selettori di traffico locale e remoto negoziati per il tunnel. Quei tre numeri spiegano quasi ogni caso di questo sintomo.

Poi ripetete la richiesta fallita dall’interno del container e catturate la sorgente che usa davvero. Se quell’indirizzo non è coperto dal selettore locale, conoscete già l’esito, e nessuna ricreazione del container lo cambierà.

Leggete le policy prima di toccare Docker

I controlli sull’host in sola lettura coprono le decisioni di routing, il database delle policy e le regole che scelgono tra di esse:

ip rule show
ip route show table all
ip xfrm policy

L’elenco delle policy mostra selettori e direzione senza bisogno di un dump dello stato IPsec pieno di materiale di chiave, per questo è sicuro incollarlo in un ticket. Cercate un selettore locale che copra l’indirizzo dell’host ma non il prefisso bridge. Controllate anche la sovrapposizione: una rotta del container che tratta la destinazione remota come locale non produrrà mai il pacchetto inoltrato che vi aspettate, e il tunnel viene incolpato. Salvate quell’elenco accanto all’indirizzo sorgente del container, perché quei due insieme sono tutto il confronto.

Se il prefisso del container manca, fermatevi e decidete l’architettura prima di modificare altro. Il resto di questo percorso presuppone che abbiate concordato quale indirizzo sorgente debba comparire sul filo.

Controllate filtraggio e traduzione in ordine

Il firewall bridge Linux di Docker può bloccare il forwarding indipendentemente da IPsec. Con il backend iptables, ispezionate il percorso FORWARD e le decisioni DOCKER-USER, ricordando che una regola aggiunta dopo un verdetto precedente potrebbe non essere mai eseguita. Il backend nftables si integra diversamente, quindi non create una catena DOCKER-USER solo perché un esempio iptables l’ha chiamata così; controllate quale backend usa davvero il vostro daemon.

Controllate poi la traduzione della sorgente. Una regola MASQUERADE ampia può trasformare un pacchetto che prima corrispondeva a un selettore IPsec in uno che non vi corrisponde più, e il guasto sembra esattamente un problema di routing. La guida al forwarding di strongSwan documenta l’esenzione NAT necessaria prima di tale traduzione per il traffico che già corrisponde a una policy.

Quell’esenzione non è un modo per aggiungere al tunnel una sorgente di container non coperta. Protegge solo il traffico che già rientra nel progetto, quindi risolvete prima le questioni di selettore e percorso di ritorno, poi fate concordare NAT e filtraggio con la risposta. Se vi trovate ad allargare l’esenzione, è il selettore che va cambiato, non la regola NAT.

Poi decidete instradato o tradotto

Una subnet di container instradata richiede che entrambi i peer accettino quella subnet e un percorso di ritorno remoto verso di essa, il che di solito significa un cambio di selettore su entrambe le estremità e una conversazione con chi possiede il lato remoto. Un progetto deliberatamente tradotto deve invece presentare un indirizzo coperto dalla policy nella fase di lookup pertinente, il che di solito significa una regola stretta e documentata invece di un MASQUERADE predefinito.

Nessuna delle due disposizioni deriva automaticamente dal tunnel funzionante dell’host, e scegliere tra le due è una decisione di progetto con un responsabile. Annotate quale avete scelto, perché altrimenti l’ingegnere successivo la rideriverà dai contatori del firewall.

Attenti anche al guasto ibrido: metà del set di regole tradotta e metà no, il che produce un successo intermittente che dipende dalla porta di destinazione e non da qualcosa sulla rete.

Verificate con una connessione nuova, non con un riavvio

Usate una connessione applicativa nuova osservando contatori di firewall stretti e il ricevitore remoto, così ogni osservazione ha una sorgente. Un riavvio di Docker può cambiare lo stato delle regole e disturberà anche i carichi di lavoro, il che vi costa il segnale pulito che cercavate.

Il risultato duraturo sono quattro affermazioni che potete mostrare: la sorgente del container, il percorso protetto corrispondente, il forwarding consentito e una risposta che torna. Quando tutte e quattro valgono, il container raggiunge il peer per la stessa ragione dell’host.