Värden når IPsec-partnern, Docker-containern gör det inte

Du pingar fjärrvärden från Linux-maskinen och den svarar, så tunneln fungerar. Containern bredvid dig får fortfarande timeout, och nästa naturliga steg är att starta om Docker. En container på ett bronätverk börjar oftast med en annan källadress och kommer in till värden via vidarebefordran i stället för genom värdapplikationens egen utväg, så mätte det lyckade testet ett annat paket. För en policybaserad strongSwan-tunnel räcker inte en vanlig rutt mot fjärrsubnätet när det vidarebefordrade paketet inte matchar den installerade IPsec-policyn.

Genomgången nedan följer en destination genom två källor och läser tillståndet innan något ändras.

Börja med en destination och två källor

Välj först en känd tjänst efter IP, så att du inte felsöker DNS samtidigt. Notera tre fakta: containerns broprefix, källadressen för den värdbegäran som fungerade, och de förhandlade lokala och fjärranslutna trafikselektorerna för tunneln. De tre talen förklarar nästan varje fall av det här symptomet.

Upprepa sedan den misslyckade begäran inifrån containern och fånga den källa den faktiskt använder. Om adressen inte täcks av den lokala selektorn känner du redan till resultatet, och ingen återskapning av containern ändrar det.

Läs policyerna innan du rör Docker

Skrivskyddade värdkontroller täcker routningsbesluten, policydatabasen och reglerna som väljer mellan dem:

ip rule show
ip route show table all
ip xfrm policy

Policylistan visar selektorer och riktning utan att en IPsec-tillståndsdump full av nyckelmaterial behövs, därför är den säker att klistra in i ett ärende. Leta efter en lokal selektor som täcker värdadressen men inte broprefixet. Kontrollera också överlappning: en containerrutt som behandlar fjärrdestinationen som lokal kommer aldrig att producera det förväntade vidarebefordrade paketet, och tunneln får skulden. Spara listan bredvid containerns källadress, för de två tillsammans är hela jämförelsen.

Saknas containerprefixet, stanna och bestäm arkitekturen innan du redigerar något annat. Resten av genomgången förutsätter att ni har enats om vilken källadress som ska synas i nätet.

Kontrollera filtrering och översättning i ordning

Dockers Linux-brobrandvägg kan blockera vidarebefordran oberoende av IPsec. Med iptables-backend, granska FORWARD-vägen och DOCKER-USER-besluten, och kom ihåg att en regel som läggs till efter en tidigare dom kanske aldrig körs. nftables-backend integreras annorlunda, så skapa inte en DOCKER-USER-kedja bara för att ett iptables-exempel kallade den så; kontrollera vilken backend din daemon faktiskt använder.

Kontrollera sedan källöversättningen. En bred MASQUERADE-regel kan förvandla ett paket som tidigare matchade en IPsec-selektor till ett som inte längre gör det, och felet ser exakt ut som ett routningsproblem. Den strongSwan-vidarebefordringsguiden dokumenterar det NAT-undantag som behövs före en sådan översättning för trafik som redan matchar en policy.

Undantaget är inte ett sätt att lägga till en otäckt containerkälla i tunneln. Det skyddar bara trafik som redan passar designen, så lös selektor- och returvägsfrågorna först och få sedan NAT och filtrering att stämma med svaret. Om du i stället börjar vidga undantaget är det selektorn som ska ändras, inte NAT-regeln.

Bestäm sedan routat eller översatt

Ett routat containersubnät kräver att båda parterna accepterar subnätet och en fjärrreturväg dit, vilket oftast betyder en selektorändring i båda ändar och ett samtal med ägaren av den bortre sidan. En medvetet översatt design måste i stället presentera en adress som täcks av policyn i det relevanta uppslagsteget, vilket oftast betyder en smal, dokumenterad regel i stället för en standard-MASQUERADE.

Ingen av de två ordningarna följer automatiskt av värdens fungerande tunnel, och valet mellan dem är ett designbeslut med en ägare. Skriv ned vilken du valde, annars härleder nästa ingenjör det igen från brandväggsräknarna.

Se också upp för det hybrida felet: halva regeluppsättningen översatt och halva inte, vilket ger sporadisk framgång som beror på destinationsporten och inte på något i nätet.

Verifiera med en ny anslutning, inte en omstart

Använd en ny applikationsanslutning medan du följer smala brandväggsräknare och fjärrmottagaren, så att varje observation har en källa. En Docker-omstart kan ändra regeltillståndet och stör också arbetsbelastningar, vilket kostar dig den rena signal du försökte få.

Det varaktiga resultatet är fyra påståenden du kan visa: containerns källa, den matchande skyddade vägen, tillåten vidarebefordran och ett svar som kommer tillbaka. När alla fyra håller når containern partnern av samma skäl som värden.