Маршрутизация из Docker-контейнеров с использованием другого физического сетевого интерфейса и шлюза по умолчанию

Исходная информация

У меня есть сервер с двумя сетевыми интерфейсами, на котором работает Docker. Docker, как и некоторые инструменты виртуализации, создает интерфейс моста Linux под названием docker0. Этот интерфейс по умолчанию настроен с IP-адресом, 172.17.42.1и все контейнеры Docker обмениваются данными с этим интерфейсом в качестве своего шлюза, и им назначаются IP-адреса в том же /16диапазоне. Насколько я понимаю, весь сетевой трафик в / из контейнеров проходит через NAT, поэтому исходящие данные, похоже, поступают 172.17.42.1, а входящие отправляются 172.17.42.1.

Моя настройка выглядит так:

                                          +------------+        /
                                          |            |       |
                            +-------------+ 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|       |
                                          +------------+            

Проблема

Я хочу направить весь трафик от / к любым контейнерам Docker из второго eth1 192.168.1.2интерфейса на шлюз по умолчанию 192.168.1.1, при этом весь трафик с / на хост-машину выходитeth0 10.1.1.2 интерфейса на шлюз по умолчанию 10.1.1.1. Я пробовал разные вещи, но безрезультатно, но единственное, что я считаю наиболее близким к исправлению, - это использовать iproute2 следующим образом:

# 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

Когда я поднимаю контейнер, я вообще не могу выскочить из него после этого. Я не уверен, обрабатываются ли мостовые интерфейсы таким же образом, как физические интерфейсы для такого рода маршрутизации, и я просто хочу проверить работоспособность, а также какие-либо советы о том, как я могу выполнить эту, казалось бы, простую задачу.

Возможно, вам придется больше посмотреть на настройку iptables. Docker маскирует весь трафик, исходящий из подсети контейнера, скажем, 172.17.0.0/16, в 0.0.0.0. Если вы запустите iptables -L -n -t nat, вы увидите цепочку POSTROUTING под таблицей nat, которая делает это:

Цепь РАЗМЕЩЕНИЯ (ПРИНЯТЬ ПОЛИТИКУ)
целевой целевой источник назначения
MASQUERADE all - 172.17.0.0/16 0.0.0.0/0

Теперь вы можете удалить это правило и заменить его правилом, которое маскирует весь трафик, исходящий из подсети контейнеров, в IP-адрес вашего второго интерфейса - 192.168.1.2, поскольку это то, что вам нужно. Правило удаления будет, при условии, что это первое правило в цепочке POSTROUTING -

iptables -t nat -D POSTROUTING 1

Затем вы добавляете это пользовательское правило -

iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -j SNAT - к источнику 192.168.1.2

Мы с другом столкнулись с этой проблемой, когда нам хотелось, чтобы докер поддерживал несколько запросов на обслуживание сетевых интерфейсов. Мы специально работали со службой AWS EC2, где мы также подключали / настраивали / вызывали дополнительные интерфейсы. В этом проекте есть не только то, что вам нужно, поэтому я постараюсь включить сюда только то, что вам нужно.

Сначала мы создали отдельную таблицу маршрутов для eth1:

ip route add default via 192.168.1.2 dev eth1 table 1001

Затем мы настроили таблицу mangle для установки некоторых меток соединения, поступающих из 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

Наконец, мы добавляем это правило для всех fwmarks, чтобы использовать новую таблицу, которую мы создали.

ip rule add from all fwmark 0x1001 lookup 1001

Приведенная ниже iptablesкоманда восстановит метку соединения, а затем разрешит правилу маршрутизации использовать правильную таблицу маршрутизации.

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

Я считаю, что это все, что нужно из нашего более сложного примера, где (как я уже сказал) наш проект подключал / настраивал / вызывал eth1интерфейс во время загрузки.

Теперь этот пример не помешает соединениям eth0обслуживать запросы, docker0но я думаю, что вы можете добавить правило маршрутизации, чтобы предотвратить это.

Маскарад не из 172.17.42.1, а скорее

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

Это означает, что это правило не будет работать правильно.

ip rule add from 172.17.42.1 table docker

Попробуй вместо

ip rule add from 172.17.0.0/16 table docker