Verwenden der iptables-Weiterleitung unter Beibehaltung der Quell-IP

Question

Überlassen Sie die Umleitung einfach Docker. Sie ist dynamisch und kann sich ändern, wenn Container hinzugefügt, entfernt oder neu gestartet werden. Aber sieheAKTUALISIERENunten.

Diese Umleitung sollte nicht auf 172.18.0.1 erfolgen, da es sich hier um den Host und nicht um den Container handelt. Wenn der Host eine solche Verbindung empfängt, wird sie vondocker-proxywelches es an den Container weiterleitet, wobei die Quell-IP-Adresse dabei verloren geht.

Docker leitet diesen Port bereits in der allerletzten Regel des Regelsatzes korrekt per DNAT + weiter (außer vom Host selbst, der docker-proxydiese Rolle spielt), zum laufenden Container mit der Adresse 172.18.0.2. Außer dass er so konfiguriert ist, dass Port 2525 statt Port 25 verwendet wird.

  107  6020 DNAT       tcp  --  !br-b147ffdbc9f3 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2525 to:172.18.0.2:25

Dies sollte mit den Docker-Einstellungen behoben werden, nicht manuelliptablesRegeln, die sich nicht ändern können, wenn sich das Containerlayout ändert. Da Port 25 privilegiert ist, sind zusätzliche Einstellungen erforderlich, wenn Docker rootless ausgeführt wird. Überprüfen Sie dieDokumentation zum Freigeben privilegierter Ports.

AKTUALISIEREN(unter Berücksichtigung der Kommentare des OP): Der OP kann derzeit nicht verwendet werden, -p 25:25da docker-proxyer mit dem SMTP-Server des lokalen Hosts kollidiert und um das Abhören auf Port 25 auf dem Host konkurriert. Das ist der Grund für die anfängliche (falsche)iptablesDie Umleitung wurde von OP vorgenommen.

Man kann entweder:

Deaktivieren Sie es global, docker-proxyindem Sie es dockerdmit der Eigenschaft userland-proxy„false“ ausführen.

entweder alsParameter --userland-proxy=falseoder als Eigenschaft "userland-proxy": falsehinzugefügt zu/etc/docker/daemon.json.

Dies ermöglicht dann die Verwendung docker run ... -p 25:25 ...(alsdokumentiert) ohne Konflikte: Der Host erreicht sich selbst, wenn er localhost oder $HOSTNAME erreicht, Remote-Systeme erreichen den Container und keine „Adresse wird bereits verwendet“ führt dazu, dass der SMTP-Daemon des Hosts oder der Container von Docker beim Start fehlschlägt.
oder fügen Sie eine manuelle Umleitung hinzu (mit der langwierigen Einrichtung weiter unten, um dies fast automatisch durchzuführen)

Bei jedem Neustart des Containers besteht das Risiko, dass sich seine (interne) IP-Adresse ändert. Diese muss also berechnet werden. Bei einem Container, der mxüber ein Netzwerk benannt ist mxund nur eine IP-Adresse verwendet, kann dies wie unten erläutert erfolgen.

Erstellen Sie eine separate Prerouting-Kette (damit sie geleert werden kann, ohne dass etwas anderes geleert werden muss) und rufen Sie sie zuerst auf:
```
iptables -t nat -N mynat
iptables -t nat -I PREROUTING -j mynat
```
Die IP-Adresse des Containers kann programmgesteuert abgerufen werden (für den einfachen Fall eines Containers, der mxmit einer einzelnen Adresse benannt ist):
```
containerip=$(docker container inspect --format '{{.NetworkSettings.IPAddress}}' mx)
```
(oder man könntejq: containerip=$(docker container inspect mx | jq '.[].NetworkSettings.IPAddress')

Den Namen der Bridge-Schnittstelle zu finden ist komplizierter, oder zumindest konnte ich keine Möglichkeit finden, dies nur mit zu tun docker ... inspect. Suchen Sie also die IP-Adresse auf dem Host und fragen Sie den Host mit ab, ip addressum nur die Bridge-Schnittstelle zu finden, auf der diese spezielle IP-Adresse festgelegt ist (erfordert den jqBefehl).
```
 bridgeip=$(docker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' mx)
 bridgeinterface=$(ip -json address show to "$bridgeip"/32 | jq -r '.[].ifname')
```
mynatBei jedem (Neu-)Start des Containers leeren und neu auffüllen :
```
iptables -t nat -F mynat
iptables -t nat -A mynat ! -i "$bridgeinterface" -p tcp --dport 25 -j DNAT --to-destination "$containerip":25
```
was im vorliegenden Fall lauten würde:

iptables -t nat -I mynat ! -i br-b147ffdbc9f3 -p tcp --dport 25 -j DNAT --to-destination 172.18.0.2:25

Und um sicherzugehen, dass Dockers eigene Firewall-Regeln diesen Datenverkehr nicht blockieren, führen Sie etwas Ähnliches aus, beginnend in filter/ FORWARDimDOCKER-USERKette.

Zunächst (wenn vom Boot aus, müssen Sie möglicherweise auch zuerstDOCKER-USER):
```
iptables -N myforward
iptables -I DOCKER-USER 1 -j myforward
```
Dann später bei jedem (Neu-)Start des Containers:
```
iptables -F myforward
iptables -A myforward -p tcp ! -i "$bridgeinterface" -d "$containerip" -p tcp --dport 25 -j ACCEPT
```
was im vorliegenden Fall lauten würde:
```
iptables -A myforward -p tcp ! -i br-b147ffdbc9f3 -d 172.18.0.2 -p tcp --dport 25 -j ACCEPT
```

Anmerkungen:

Um die oben genannten Regeln zu vereinfachen und einige der Berechnungen zu vermeiden, können der Container und sein Bridge-Netzwerk mit festen IP-Adressen gestartet werden. Siehe beispielsweise diese SO Q/A:Weisen Sie dem Docker-Container eine statische IP zu.
Hier ist auch ein UL SE Q/A mit einer Antwort von mir über Probleme bei der Interaktion mit Docker (es richtet sich anNftablesaber einige Teile über die DOCKER-USERKetten- oder br_netfilterBrückeninteraktionen sind immer noch von Interesse):Nftables-Whitelist-Docker

Answer 1