Routing von Docker-Containern mithilfe einer anderen physischen Netzwerkschnittstelle und eines anderen Standardgateways

Hintergrundinformation

Ich habe einen Server mit zwei Netzwerkschnittstellen, auf dem Docker ausgeführt wird. Docker erstellt wie einige Virtualisierungstools eine Linux-Bridge-Schnittstelle mit dem Namen docker0. Diese Schnittstelle ist standardmäßig mit einer IP von konfiguriert, 172.17.42.1und alle Docker-Container kommunizieren mit dieser Schnittstelle als Gateway und erhalten IP-Adressen im selben /16Bereich. Soweit ich weiß, wird der gesamte Netzwerkverkehr zu / von Containern über ein NAT abgewickelt, so dass er anscheinend von einem NAT ausgeht 172.17.42.1und an einen eingehenden Datenverkehr gesendet wird 172.17.42.1.

Mein Setup sieht so aus:

                                          +------------+        /
                                          |            |       |
                            +-------------+ Gateway 1  +-------
                            |             | 10.1.1.1   |     /
                     +------+-------+     +------------+    |
                     |     eth0     |                      /
                     |   10.1.1.2   |                      |
                     |              |                      |
                     | DOCKER HOST  |                      |
                     |              |                      | Internet
                     |   docker0    |                      |
                     |   (bridge)   |                      |
                     |  172.17.42.1 |                      |
                     |              |                      |
                     |     eth1     |                      |
                     |  192.168.1.2 |                      \
                     +------+-------+     +------------+    |
                            |             |            |     \
                            +-------------+ Gateway 2  +-------
                                          | 192.168.1.1|       |
                                          +------------+            

Das Problem

Ich möchte den gesamten Datenverkehr von / zu Docker-Containern aus der zweiten eth1 192.168.1.2Schnittstelle an ein Standard-Gateway von leiten 192.168.1.1, während der gesamte Datenverkehr vom / zum Host-Computer über die eth0 10.1.1.2Schnittstelle an ein Standard-Gateway von leiten soll 10.1.1.1. Ich habe eine Reihe von Dingen bisher erfolglos ausprobiert, aber das, was meiner Meinung nach am ehesten zu korrigieren ist, ist, iproute2 wie folgt zu verwenden:

# Create a new routing table just for docker
echo "1 docker" >> /etc/iproute2/rt_tables

# Add a rule stating any traffic from the docker0 bridge interface should use 
# the newly added docker routing table
ip rule add from 172.17.42.1 table docker

# Add a route to the newly added docker routing table that dictates all traffic
# go out the 192.168.1.2 interface on eth1
ip route add default via 192.168.1.2 dev eth1 table docker

# Flush the route cache
ip route flush cache

# Restart the Docker daemon so it uses the correct network settings
# Note, I do this as I found Docker containers often won't be able
# to connect out if any changes to the network are made while it's     
# running
/etc/init.d/docker restart

Wenn ich einen Container aufbringe, kann ich danach gar nicht mehr herauspingen. Ich bin nicht sicher, ob Bridge-Schnittstellen genauso behandelt werden wie physische Schnittstellen für diese Art von Routing. Ich möchte lediglich eine Überprüfung der Integrität sowie Tipps, wie ich diese scheinbar einfache Aufgabe ausführen kann.

Möglicherweise müssen Sie auch mehr über das Setup von iptables nachdenken. Docker maskiert den gesamten Datenverkehr, der aus dem Container-Subnetz stammt, z. B. 172.17.0.0/16, auf 0.0.0.0. Wenn Sie ausführen iptables -L -n -t nat, können Sie die POSTROUTING-Kette unter der entsprechenden Tabelle sehen.

Chain POSTROUTING (Policy ACCEPT)
Zielprotokoll Quellenziel
MASQUERADE all - 172.17.0.0/16 0.0.0.0/0

Jetzt können Sie diese Regel entfernen und durch eine Regel ersetzen, die den gesamten Datenverkehr aus dem Subnetz der Container zur IP - 192.168.1.2 Ihrer zweiten Schnittstelle maskiert, wie Sie es wünschen. Die Löschregel lautet, sofern es sich um die erste Regel in der POSTROUTING-Kette handelt:

iptables -t nat -D POSTROUTING 1

Dann fügen Sie diese benutzerdefinierte Regel hinzu -

iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -j SNAT - zur Quelle 192.168.1.2

Ein Freund und ich hatten genau dieses Problem, bei dem wir wollten, dass Docker mehrere Netzwerkschnittstellen unterstützen, die Anfragen bearbeiten. Wir haben speziell mit dem AWS EC2-Service zusammengearbeitet, bei dem wir auch die zusätzlichen Schnittstellen angeschlossen / konfiguriert / aufgerufen haben. In diesem Projekt gibt es mehr als das, was Sie brauchen. Ich werde versuchen, nur das einzubeziehen, was Sie hier brauchen.

Zunächst haben wir eine separate Routentabelle erstellt für eth1:

ip route add default via 192.168.1.2 dev eth1 table 1001

Als nächstes haben wir die Mangeltabelle so konfiguriert, dass einige Verbindungsmarkierungen gesetzt werden, die von kommen eth1:

iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-xmark 0x1001/0xffffffff
iptables -t mangle -A PREROUTING -i eth1 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff

Schließlich fügen wir diese Regel hinzu, damit alle fwmarks die neu erstellte Tabelle verwenden können.

ip rule add from all fwmark 0x1001 lookup 1001

Mit dem folgenden iptablesBefehl wird die Verbindungsmarke wiederhergestellt, und die Routing-Regel kann die richtige Routing-Tabelle verwenden.

iptables -w -t mangle -A PREROUTING -i docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

Ich glaube, dies ist alles, was in unserem komplexeren Beispiel benötigt wird, in dem (wie gesagt) unser Projekt die eth1Schnittstelle beim Booten anhängt / konfiguriert / aufruft .

Jetzt würde dieses Beispiel die Verbindungen nicht davon abhalten eth0, Anfragen zu bearbeiten, docker0aber ich glaube, Sie könnten eine Routing-Regel hinzufügen, um dies zu verhindern.

Die Maskerade ist nicht vom 172.17.42.1 sondern eher

 -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

Was bedeutet, dass diese Regel nicht richtig funktioniert.

ip rule add from 172.17.42.1 table docker

Versuchen Sie es stattdessen

ip rule add from 172.17.0.0/16 table docker