我如何configurationDocker与我的ens34networking接口（而不是eth0）？
有谁知道如何docker决定哪个网卡将与docker0networking工作？ 我有一个有两个接口（eth0和ens34）的节点，但是只有通过eth0的请求被转发到容器。
当我的虚拟机configuration好了，并且安装了Docker后，我开始了一个非常愚蠢的testing：我创build了一个centos虚拟机，安装了netcat并提交了镜像。 然后我启动了一个监听端口8080的守护进程容器。我使用了：
docker -it -p 8080:8080 --name nc-server nc-server nc -vv -l 8080 所以我尝试连接到从同一networking中的另一个节点（与接口ens34相同的IP地址）监听8080端口的容器。 它不起作用。
而当我从另一台机器向eth0的IP地址发送请求时，我发现容器中有一些反应（通信正常）。 我用下面的方法“输出”输出：
docker logs -ft nc-server
我的结论是：eth0（主NIC）和docker0之间有一些神秘的关系，发送到ens34（10. ）接口的请求永远不会被转发到veth / docker0接口，只有通过eth0 9. *）。 为什么？
此外，我知道如果我使用–net = host，我可以使所有的工作，但我不想用它…它不觉得正确的，是在Docker中使用HOST模式的标准做法容器？ 任何警告呢？
–
更新：我设法禁用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
filter
[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
NAT
[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
思考？
首先，排除明显并确保其他networking上的主机知道如何路由到您的机器到达集装箱networking。 为此，请检查
netstat -nr
在源主机上，并确保您的docker子网与docker主机列为网关，或者处理上游通信的默认路由器知道您的主机。
如果stream量被路由但阻塞，那么你正在进入转发和iptables 。 对于转发，以下应该显示1：
cat /proc/sys/net/ipv4/ip_forward
请确保您的本地主机使用相同的netstat命令显示了到您的容器networking的网桥的路由，docker0接口和您的docker子网应该有一行作为目标：
netstat -nr
对于iptables，检查是否有任何需要调整的接口特定的NAT或过滤规则：
iptables -t filter -vS iptables -t nat -vS
如果您的转发规则默认为DROP而不是ACCEPT，那么您可能需要添加一些日志logging，或者如果您确信它可以被信任（例如，主机在另一个防火墙之后），则只需更改默认值即可接受stream量。
这就是说，直接在主机上广告端口是一个相当普遍的做法与集装箱。 对于私人的东西，你可以在他们的内部networking上设置多个容器，这些容器可以相互通信，但是没有其他的容器，而且你只用主机上的-p来暴露真正开放给世界其他地方的端口运行标志（或docker-compose中的ports选项）。