Как настроить Docker для работы с моим сетевым интерфейсом ens34 (вместо eth0)?

Question

Кто-нибудь знает, как докер решает, какая сетевая карта будет работать с сетью docker0? У меня есть узел с двумя интерфейсами (eth0 и ens34), однако только запросы, которые проходят через eth0, перенаправляются в контейнер.

Когда моя виртуальная машина была предоставлена, а Docker был установлен, я начал очень глупый тест: я создал centos vm, установил netcat на него и зафиксировал изображение. Затем я начал контейнер демон прослушивает порт 8080. Я использовал:

docker -it -p 8080:8080 --name nc-server nc-server nc -vv -l 8080 

Так что я попытался подключиться к контейнеру на порту 8080 с другого узла в одной и той же сети (в том же IP-адрес в качестве интерфейса ens34). Это не работает.

Принимая во внимание, что когда я отправил запрос с другого компьютера на IP-адрес из eth0, я увидел некоторую реакцию в контейнере (связь работала). Я «хвостовой» свою продукцию с:

docker logs -ft nc-server 

Моим вывод с этим экспериментом: есть какая-то таинственная связь между eth0 (первичным NIC) и docker0 и запросами, посылаемыми в ens34 (10. ) интерфейс никогда не пересылаются в интерфейсы veth/docker0, только запросы, которые проходят через eth0 (9. *). Почему это?

Кроме того, я знаю, что могу сделать все работоспособным, если я использую --net = host, но я не хочу использовать это ... он не так или иначе чувствует себя, это стандартная практика использования Режим HOST в контейнерах Docker? Какие-либо оговорки по этому поводу?

-

UPDATE: мне удалось заставить его работать после отключения IPTables:

service iptables stop 

Однако, я до сих пор не понимаю, что происходит. Информация ниже должна быть актуальной, чтобы понять, что происходит:

IFCONFIG

[root@mydockervm2 myuser]# ifconfig | grep -A 1 flags 
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
     inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 
-- 
ens34: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
     inet 10.1.21.18 netmask 255.255.255.0 broadcast 10.1.21.255 
-- 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
     inet 9.32.145.99 netmask 255.255.255.0 broadcast 9.32.148.255 
-- 
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 
     inet 127.0.0.1 netmask 255.0.0.0 
-- 
veth8dbab2f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
     inet6 fe80::3815:67ff:fe9b:88e9 prefixlen 64 scopeid 0x20<link> 
-- 
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 
     inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 

NETSTAT

[root@mydockervm2 myuser]# netstat -nr 
Kernel IP routing table 
Destination  Gateway   Genmask   Flags MSS Window irtt Iface 
0.0.0.0   9.32.145.1  0.0.0.0   UG  0 0   0 eth0 
9.32.145.0  0.0.0.0   255.255.255.0 U   0 0   0 eth0 
10.1.21.0  0.0.0.0   255.255.255.0 U   0 0   0 ens34 
169.254.0.0  0.0.0.0   255.255.0.0  U   0 0   0 eth0 
169.254.0.0  0.0.0.0   255.255.0.0  U   0 0   0 ens34 
172.17.0.0  0.0.0.0   255.255.0.0  U   0 0   0 docker0 
192.168.122.0 0.0.0.0   255.255.255.0 U   0 0   0 virbr0 

фильтры

[root@mydockervm2 myuser]# iptables -t filter -vS 
-P INPUT ACCEPT -c 169 106311 
-P FORWARD ACCEPT -c 0 0 
-P OUTPUT ACCEPT -c 110 13426 
-N DOCKER 
-N DOCKER-ISOLATION 
-A FORWARD -c 0 0 -j DOCKER-ISOLATION 
-A FORWARD -o docker0 -c 0 0 -j DOCKER 
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -c 0 0 -j ACCEPT 
-A FORWARD -i docker0 ! -o docker0 -c 0 0 -j ACCEPT 
-A FORWARD -i docker0 -o docker0 -c 0 0 -j ACCEPT 
-A FORWARD -m physdev --physdev-is-bridged -c 0 0 -j ACCEPT 
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -c 0 0 -j ACCEPT 
-A DOCKER-ISOLATION -c 0 0 -j RETURN 

физ

[root@mydockervm2 myuser]# iptables -t nat -vS 
-P PREROUTING ACCEPT -c 28 4818 
-P INPUT ACCEPT -c 28 4818 
-P OUTPUT ACCEPT -c 8 572 
-P POSTROUTING ACCEPT -c 8 572 
-N DOCKER 
-A PREROUTING -m addrtype --dst-type LOCAL -c 2 98 -j DOCKER 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -c 0 0 -j DOCKER 
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -c 0 0 -j MASQUERADE 
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 8080 -c 0 0 -j MASQUERADE 
-A DOCKER -i docker0 -c 0 0 -j RETURN 
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -c 0 0 -j DNAT --to-destination 172.17.0.2:8080 

Мысли?

Answer 1

Во-первых, исключите очевидное и убедитесь, что хосты других сетей знают, как направлять на ваш компьютер, чтобы добраться до сети контейнеров. Для этого, проверьте

netstat -nr 

на исходном узле и убедитесь, что ваш докер подсети перечислены с Docker хоста в качестве шлюза, или обработку трафика вверх по умолчанию маршрутизатор знает о своем хозяине.

Если трафик маршрутизируется, но блокируется, то вы получаете переадресацию и iptables.Для переадресации, следующие должен показать 1:

cat /proc/sys/net/ipv4/ip_forward 

Убедитесь, что локальный хост показывает маршрут для мостов в ваши контейнерных сети с одной и той же NETSTAT команды, должна быть линией для интерфейса docker0 и вашего докера подсеть в качестве пункта назначения:

netstat -nr 

для IPTables, проверьте, чтобы увидеть, если есть какие-либо конкретные интерфейс физ или фильтр правил, которые должны быть скорректированы:

iptables -t filter -vS 
iptables -t nat -vS 

Если для вашего прямого правила по умолчанию используется DROP вместо ACCEPT, вы можете захотеть добавить некоторые протоколирования или просто изменить значение по умолчанию для приема трафика, если вы считаете, что ему можно доверять (например, хост находится за другим межсетевым экраном).

Это, как говорится, рекламные порты непосредственно на хосте - довольно распространенная практика с контейнерами. Для частных вещей вы можете настроить несколько контейнеров, изолированных на своей внутренней сети, которые могут разговаривать друг с другом, но не с другими контейнерами, и вы открываете только порты, которые действительно открыты для остального мира на хосте, с флагом -p для запуска (или опции портов в компоновке докеров).