Использование переадресации iptables с сохранением исходного IP-адреса

Question

Просто позвольте Docker заняться перенаправлением, которое является динамическим и может меняться при добавлении, удалении или перезапуске контейнеров. Но см.ОБНОВЛЯТЬниже.

Это перенаправление не должно быть на 172.18.0.1, который является хостом, а не контейнером. Когда хост получает такое соединение, оно обрабатываетсяdocker-proxyкоторый проксирует его в контейнер, теряя при этом исходный IP-адрес.

Docker уже DNAT + правильно маршрутизирует этот порт (кроме самого хоста, где docker-proxyиграет эту роль) в самом последнем правиле набора правил, на работающий контейнер с адресом 172.18.0.2. За исключением того, что он настроен на использование порта 2525 вместо порта 25.

  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 работает без прав root, необходимы дополнительные настройки, проверьтедокументация о раскрытии привилегированных портов.

ОБНОВЛЯТЬ(учитывая комментарии OP): OP в настоящее время не может использовать, -p 25:25поскольку docker-proxyконфликтует с SMTP-сервером локального хоста и конкурирует за прослушивание порта 25 на хосте. Вот почему изначально (неправильно)iptablesперенаправление было сделано OP.

Можно либо:

отключить глобально, docker-proxyзапустив dockerdсо свойством, userland-proxyустановленным на false

либо какпараметр --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:Назначить статический IP-адрес контейнеру Docker.
Вот также UL SE Q/A с моим ответом о проблемах при взаимодействии с Docker (он предназначен дляnftablesно некоторые части взаимодействия DOCKER-USERцепей или br_netfilterмостиков все еще представляют интерес):nftables белый список docker

Answer 1