De host bereikt de IPsec-peer, de Docker-container niet

U pingt de externe host vanaf de Linux-machine en hij antwoordt, dus de tunnel werkt. De container ernaast loopt nog steeds in een time-out, en de natuurlijke volgende stap is Docker herstarten. Een container op een bridgenetwerk begint meestal met een ander bronadres en komt de host binnen via forwarding in plaats van via het eigen uitgangspad van de hostapplicatie, dus mat de geslaagde test een ander pakket. Voor een op beleid gebaseerde strongSwan-tunnel is een gewone route naar het externe subnet niet genoeg wanneer het doorgestuurde pakket niet overeenkomt met het geïnstalleerde IPsec-beleid.

De onderstaande uitleg volgt één bestemming via twee bronnen en leest de status voordat er iets verandert.

Begin bij één bestemming en twee bronnen

Kies eerst een bekende dienst op IP, zodat u niet tegelijk DNS aan het debuggen bent. Noteer drie feiten: de bridgeprefix van de container, het bronadres van de hostaanvraag die werkte, en de onderhandelde lokale en externe traffic-selectors voor de tunnel. Die drie getallen verklaren bijna elk geval van dit symptoom.

Herhaal daarna de mislukte aanvraag van binnenuit de container en leg de bron vast die hij werkelijk gebruikt. Als dat adres niet door de lokale selector wordt gedekt, kent u de uitkomst al, en geen enkele hercreatie van de container verandert dat.

Lees het beleid voordat u Docker aanraakt

Alleen-lezen hostcontroles dekken de routingbeslissingen, de beleidsdatabase en de regels die daartussen kiezen:

ip rule show
ip route show table all
ip xfrm policy

De beleidslijst toont selectors en richting zonder een IPsec-statusdump vol sleutelmateriaal nodig te hebben, daarom is het veilig om hem in een ticket te plakken. Zoek een lokale selector die het hostadres dekt maar niet de bridgeprefix. Controleer ook overlap: een containerroute die de externe bestemming als lokaal behandelt, levert nooit het verwachte doorgestuurde pakket op, en de tunnel krijgt de schuld. Bewaar die lijst naast het bronadres van de container, want die twee samen zijn de hele vergelijking.

Ontbreekt de containerprefix, stop dan en beslis de architectuur voordat u iets anders bewerkt. De rest van deze uitleg gaat ervan uit dat u het erover eens bent welk bronadres op de lijn moet verschijnen.

Controleer filtering en vertaling op volgorde

De Linux-bridgefirewall van Docker kan forwarding blokkeren onafhankelijk van IPsec. Met de iptables-backend, inspecteer het FORWARD-pad en de DOCKER-USER-beslissingen, en bedenk dat een regel die na een eerder oordeel is toegevoegd misschien nooit draait. De nftables-backend integreert anders, dus maak geen DOCKER-USER-keten alleen omdat een iptables-voorbeeld hem zo noemde; controleer welke backend uw daemon werkelijk gebruikt.

Controleer daarna de bronvertaling. Een brede MASQUERADE-regel kan een pakket dat eerder bij een IPsec-selector paste veranderen in een pakket dat er niet meer bij past, en de storing lijkt precies op een routingprobleem. De strongSwan-forwardinggids documenteert de NAT-uitzondering die nodig is vóór zulke vertaling voor verkeer dat al bij een beleid past.

Die uitzondering is geen manier om een ongedekte containerbron aan de tunnel toe te voegen. Ze beschermt alleen verkeer dat al bij het ontwerp past, dus beslecht eerst de selector- en terugwegvragen en laat daarna NAT en filtering met het antwoord overeenkomen. Als u de uitzondering eerder gaat verbreden, is de selector het ding dat moet veranderen, niet de NAT-regel.

Beslis daarna gerouteerd of vertaald

Een gerouteerd containersubnet vereist dat beide peers dat subnet accepteren en dat er een externe terugweg ernaartoe is, wat meestal een selectorwijziging aan beide uiteinden betekent en een gesprek met de eigenaar van de verre kant. Een bewust vertaald ontwerp moet in plaats daarvan een adres presenteren dat door het beleid wordt gedekt in de relevante opzoekfase, wat meestal een smalle, gedocumenteerde regel betekent in plaats van een standaard-MASQUERADE.

Geen van beide regelingen volgt automatisch uit de werkende tunnel van de host, en kiezen tussen beide is een ontwerpbeslissing met een eigenaar. Schrijf op welke u koos, want anders leidt de volgende engineer het opnieuw af uit de firewallellers.

Let ook op de hybride storing: de helft van de regelset vertaald en de helft niet, wat wisselend succes geeft dat afhangt van de bestemmingspoort en niet van iets aan het netwerk.

Verifieer met een nieuwe verbinding, niet met een herstart

Gebruik een nieuwe applicatieverbinding terwijl u smalle firewallellers en de externe ontvanger bekijkt, zodat elke waarneming een bron heeft. Een Docker-herstart kan de regelstatus veranderen en verstoort ook workloads, wat u het schone signaal kost dat u probeerde te krijgen.

Het blijvende resultaat zijn vier uitspraken die u kunt tonen: de containerbron, het bijbehorende beschermde pad, toegestane forwarding en een antwoord dat terugkomt. Als alle vier gelden, bereikt de container de peer om dezelfde reden als de host.