Der Host erreicht den IPsec-Peer, der Docker-Container nicht

Sie pingen den entfernten Host von der Linux-Maschine aus, und er antwortet, der Tunnel funktioniert also. Der Container daneben läuft weiterhin in einen Timeout, und der naheliegende nächste Schritt ist ein Neustart von Docker. Ein Container im Bridge-Netz beginnt meist mit einer anderen Quelladresse und gelangt über Forwarding in den Host statt über den eigenen Ausgangspfad der Host-Anwendung, daher hat der erfolgreiche Test ein anderes Paket gemessen. Bei einem policy-basierten strongSwan-Tunnel genügt eine gewöhnliche Route zum entfernten Subnetz nicht, wenn das weitergeleitete Paket nicht zur installierten IPsec-Policy passt.

Der folgende Durchgang verfolgt ein Ziel über zwei Quellen und liest den Zustand, bevor etwas geändert wird.

Mit einem Ziel und zwei Quellen beginnen

Wählen Sie zuerst einen bekannten Dienst nach IP, damit Sie nicht gleichzeitig DNS debuggen. Notieren Sie drei Fakten: das Bridge-Präfix des Containers, die Quelladresse der Host-Anfrage, die funktioniert hat, und die ausgehandelten lokalen und entfernten Traffic-Selektoren des Tunnels. Diese drei Zahlen erklären fast jeden Fall dieses Symptoms.

Wiederholen Sie dann die fehlgeschlagene Anfrage aus dem Container und erfassen Sie die Quelle, die er tatsächlich verwendet. Ist diese Adresse nicht vom lokalen Selektor abgedeckt, kennen Sie das Ergebnis bereits, und kein Neuerstellen des Containers ändert daran etwas.

Lesen Sie die Policies, bevor Sie Docker anfassen

Schreibgeschützte Host-Prüfungen decken die Routing-Entscheidungen, die Policy-Datenbank und die Regeln ab, die zwischen ihnen auswählen:

ip rule show
ip route show table all
ip xfrm policy

Die Policy-Auflistung zeigt Selektoren und Richtung, ohne einen IPsec-Zustandsauszug voller Schlüsselmaterial zu benötigen, deshalb ist sie gefahrlos in ein Ticket einzufügen. Suchen Sie einen lokalen Selektor, der die Host-Adresse abdeckt, aber nicht das Bridge-Präfix. Prüfen Sie auch auf Überlappung: eine Container-Route, die das entfernte Ziel als lokal behandelt, erzeugt niemals das erwartete weitergeleitete Paket, und der Tunnel bekommt die Schuld. Legen Sie diese Auflistung neben die Quelladresse des Containers, denn beide zusammen sind der ganze Vergleich.

Fehlt das Container-Präfix, halten Sie an und entscheiden Sie die Architektur, bevor Sie etwas anderes ändern. Der Rest dieses Durchgangs setzt voraus, dass Sie sich geeinigt haben, welche Quelladresse auf der Leitung erscheinen soll.

Filterung und Übersetzung der Reihe nach prüfen

Die Linux-Bridge-Firewall von Docker kann Forwarding unabhängig von IPsec blockieren. Prüfen Sie beim iptables-Backend den FORWARD-Pfad und die DOCKER-USER-Entscheidungen und bedenken Sie, dass eine nach einem früheren Urteil angehängte Regel womöglich nie läuft. Das nftables-Backend integriert anders, also legen Sie keine DOCKER-USER-Kette an, nur weil ein iptables-Beispiel sie so genannt hat; prüfen Sie, welches Backend Ihr Daemon tatsächlich nutzt.

Prüfen Sie dann die Quellübersetzung. Eine breite MASQUERADE-Regel kann ein Paket, das zuvor zu einem IPsec-Selektor passte, in eines verwandeln, das nicht mehr passt, und der Fehler sieht genau wie ein Routingproblem aus. Der strongSwan-Forwarding-Leitfaden dokumentiert die NAT-Ausnahme, die vor einer solchen Übersetzung für bereits policy-konformen Verkehr nötig ist.

Diese Ausnahme ist kein Weg, eine ungedeckte Container-Quelle zum Tunnel hinzuzufügen. Sie schützt nur Verkehr, der bereits zum Entwurf passt, also klären Sie zuerst die Selektor- und Rückwegfragen und bringen Sie dann NAT und Filterung mit der Antwort in Einklang. Wenn Sie stattdessen die Ausnahme erweitern, ist der Selektor das, was zu ändern ist, nicht die NAT-Regel.

Dann zwischen geroutet und übersetzt entscheiden

Ein geroutetes Container-Subnetz verlangt, dass beide Peers dieses Subnetz akzeptieren, und einen entfernten Rückweg dorthin, was meist eine Selektoränderung an beiden Enden und ein Gespräch mit dem Eigentümer der Gegenseite bedeutet. Ein bewusst übersetztes Design muss stattdessen eine von der Policy gedeckte Adresse in der relevanten Lookup-Stufe vorweisen, was meist eine enge, dokumentierte Regel statt eines Standard-MASQUERADE bedeutet.

Keine der beiden Anordnungen folgt automatisch aus dem funktionierenden Tunnel des Hosts, und die Wahl dazwischen ist eine Entwurfsentscheidung mit einem Eigentümer. Schreiben Sie auf, welche Sie gewählt haben, sonst leitet der nächste Ingenieur sie wieder aus den Firewall-Zählern ab.

Achten Sie auch auf den hybriden Fehler: die Hälfte des Regelwerks übersetzt und die Hälfte nicht, was sporadischen Erfolg erzeugt, der vom Zielport abhängt und nicht von irgendetwas am Netz.

Mit einer frischen Verbindung prüfen, nicht mit einem Neustart

Nutzen Sie eine frische Anwendungsverbindung, während Sie enge Firewall-Zähler und den entfernten Empfänger beobachten, damit jede Beobachtung eine Quelle hat. Ein Docker-Neustart kann den Regelzustand ändern und stört außerdem Workloads, was Sie um das saubere Signal bringt, das Sie wollten.

Das dauerhafte Ergebnis sind vier Aussagen, die Sie zeigen können: die Container-Quelle, der passende geschützte Pfad, erlaubtes Forwarding und eine Antwort, die zurückkommt. Wenn alle vier gelten, erreicht der Container den Peer aus demselben Grund wie der Host.