iptables転送を使用し、送信元IPを適切に維持する

Question

リダイレクトはDockerに任せましょう。これは動的で、コンテナが追加、削除、再起動されると変更される可能性があります。しかし、アップデート下に。

このリダイレクトは、コンテナではなくホストである172.18.0.1に行われるべきではありません。ホストがこのような接続を受信すると、docker-proxyこれにより、コンテナにプロキシされ、そのプロセスで送信元 IP アドレスが失われます。

Docker はすでに、ルールセットの最後のルールで、このポートを 172.18.0.2 アドレスの実行中のコンテナーに正しく DNAT + ルーティングしています (この役割を果たすホスト自体からは除きますdocker-proxy)。ただし、ポート 25 ではなくポート 2525 を使用するように構成されています。

  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

これは手動ではなくDocker設定で修正する必要がありますiptablesコンテナレイアウトが変更されても変更できないルール。ポート25は特権ポートなので、Dockerがルートレスで実行されている場合は追加の設定が必要です。特権ポートの公開に関するドキュメント。

アップデート-p 25:25（OPのコメントを考慮すると）：OPは現在、ローカルホストのSMTPサーバーと衝突し、ホストのポート25でリッスンするために競合するため使用できませんdocker-proxy。これが、最初の（間違った）理由です。iptablesリダイレクトは OP によって行われました。

次のいずれかが可能です:

プロパティをfalseに設定してdocker-proxy実行することでグローバルに無効にするdockerduserland-proxy

またはパラメータ --userland-proxy=false"userland-proxy": falseまたは追加されたプロパティとして/etc/docker/daemon.json。

これdocker run ... -p 25:25 ...により、（文書化された) が衝突することなく、ホストは localhost または $HOSTNAME に到達すると自分自身に到達し、リモートシステムはコンテナーに到達し、「アドレスが既に使用中」になることがないため、ホストの SMTP デーモンまたは Docker のコンテナーが起動時に失敗することはありません。
または、手動でリダイレクトを追加します（ほぼ自動的に行うには、以下の長いセットアップが必要です）

コンテナが再起動されるたびに、その (内部) IP アドレスが変更されるリスクがあります。そのため、これを計算する必要があります。したがって、mxネットワーク名を使用して名前を付けられたコンテナとmx、関係する単一の IP アドレスでは、以下で説明するようにこれを実行できます。

別の事前ルーティングチェーンを作成し (他のものをフラッシュしなくてもフラッシュできるように)、最初にそれを呼び出します。
```
iptables -t nat -N mynat
iptables -t nat -I PREROUTING -j mynat
```
コンテナの IP アドレスはプログラムで取得できます (mx単一のアドレスで名前が付けられたコンテナの単純なケースの場合)。
```
containerip=$(docker container inspect --format '{{.NetworkSettings.IPAddress}}' mx)
```
（またはjq: containerip=$(docker container inspect mx | jq '.[].NetworkSettings.IPAddress')

ブリッジインターフェイス名の検索はより複雑です。少なくとも、のみを使用して検索する方法は見つかりませんでしたdocker ... inspect。したがって、ホスト上でその IP アドレスを見つけ、を使用してホストを照会し、ip addressこの特定の IP アドレスが設定されているブリッジインターフェイスのみを検索します (jqコマンドが必要です)。
```
 bridgeip=$(docker network inspect --format '{{(index .IPAM.Config 0).Gateway}}' mx)
 bridgeinterface=$(ip -json address show to "$bridgeip"/32 | jq -r '.[].ifname')
```
mynatコンテナが(再)起動されるたびにフラッシュして再読み込みします。
```
iptables -t nat -F mynat
iptables -t nat -A mynat ! -i "$bridgeinterface" -p tcp --dport 25 -j DNAT --to-destination "$containerip":25
```
現在のケースでは次のようになります。

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

そして、Docker自身のファイアウォールルールがそのようなトラフィックをブロックしないようにするには、filter/から同様のことを行ってくださいFORWARD。DOCKER-USER鎖。

最初に（起動からの場合は、最初に作成する必要があるかもしれません）DOCKER-USER):
```
iptables -N myforward
iptables -I DOCKER-USER 1 -j myforward
```
その後、コンテナが（再）起動されるたびに次のようになります。
```
iptables -F myforward
iptables -A myforward -p tcp ! -i "$bridgeinterface" -d "$containerip" -p tcp --dport 25 -j ACCEPT
```
現在のケースでは次のようになります。
```
iptables -A myforward -p tcp ! -i br-b147ffdbc9f3 -d 172.18.0.2 -p tcp --dport 25 -j ACCEPT
```

ノート：

上記のルールを簡素化し、計算の一部を回避するために、コンテナとそのブリッジネットワークを固定 IP アドレスで起動することができます。たとえば、次の SO Q/A を参照してください。Dockerコンテナに静的IPを割り当てる。
こちらもUL SE Q/Aで、Dockerとのやりとりで発生する問題についての私の回答です（nftablesDOCKER-USERしかし、チェーンやブリッジの相互作用に関するいくつかの部分はbr_netfilter依然として興味深いです):nftables ホワイトリスト docker

Answer 1