二层网络无法访问宿主机上以容器形式运行的服务，TCP 握手失败。

• 外部主机telnet超时
• curl无响应

原因是：net.ipv4.conf.eth0.forwarding=0

因为已找到原因，所以很轻易就能重现出完全一致的异常现象，在此记录完整的排查过程。

1. 排查服务本身的问题

在宿主机xxxx启动了一个nginx容器

docker run --name some-nginx3 -d -p 10001:80 nginx

服务监听正常

tcp6       0      0 :::10001     :::*         LISTEN      806844/docker-proxy 

本机curl正常返回

curl http://127.0.0.1:10001
curl http://xx:10001

容器服务完全正常，那么从外部主机无法访问，就只可能是网络问题。

2. 检查TCP包是否到达了容器内部

通过抓包来确认网络包是否到达来容器内部

• 进入容器(nsenter -n -t `docker inspect -f {{.State.Pid}} 6142917db6b9`),在 eth0 虚拟网卡也就是为容器配备的 veth 设备抓包
• 同时在宿主机上也抓eth0网卡的包

现象是： 宿主机eth0网卡收到了网络包，而容器的eth0没有收到网络包。

3. 检查TCP包是否到达了docker0网桥

按照容器bridge网络架构，容器的veth网卡都是挂在docker0网桥上，因此从外部达到eth0的网络包应该直接到达docker0网桥

• 在宿主机上抓eth0包: tcpdump -i eth0 tcp port 10001
• 在宿主机上抓docker0包: tcpdump -i docker0 tcp port 10001

现象是： 宿主机eth0网卡收到了网络包，而docker0没有收到网络包

从iptables的统计数据来看，也基本上符合这个现象，NAT转到80基本上都没有什么包

通过上面的排查： 宿主机能正常收到外部的网络包，但是宿主机并没有将包转到docker0网桥上

4. 防火墙检查

在 eth0 网卡与 docker 0 网桥之间是漫长的 Linux 内核栈，而 Netfilter 是最可能发生丢包的地方。

Netfilter 是 Linux 内核的框架，提供了对网络数据包进行修改（比如 NAT）和过滤（比如防火墙）的能力。

根据上图，我们要对 Netfilter 网络层（绿色背景）四种表 raw –> mangle –> nat –> filter（优先级依次降低）的各个 Hook 点逐一排查：

1. raw表

iptables -t raw -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

raw表没丢PREROUTING，没啥问题

2. mangle 表

主要用于修改数据包

 iptables -t mangle -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source      destination         
DSCP       tcp  --  0.0.0.0/0   0.0.0.0/0 /* QoS Default rule */ DSCP set 0x08
....

PREROUTING没丢弃，说明这个表也没啥问题

3. nat表

内容是多个容器的NAT表，拿nginx来说，和它通信最关键的三条链

1. 容器和外部通信： -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
2. 外部和容器通信：
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 10001 -j DNAT --to-destination 172.17.0.2:80
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0      0 docker0

这些转发规则都没问题，正常情况下，如果数据包到来NAT，那么DNAT转发就会立马将数据地址转成172.17.0.14，回直接通过docker0网桥转发到容器

iptables -t nat -nL -v 可统计通过链的包数

4. filter表

结合Netfilter的图，前面的链没过，filter链也不会有数据

不支持在 Docs 外粘贴 block

如上图，检查了各个表，发现连数据都没有，显然不太可能是netfilter drop的原因。出于安全考虑，Linux系统默认是禁止数据包转发的，所以肯定是net.ipv4.ip_forward没有开启的问题了。但是这个问题很奇怪。

机器都是通过salt统一初始化

 cat /etc/sysctl.conf
# Manage by SALTSTACK
# Should not change manually
#test
net.ipv4.ip_forward=1

但是当我们定位到问题时：

sysctl -a | grep "\.forwarding" | grep ipv4
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.bond0.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.docker0.forwarding = 1
net.ipv4.conf.eth0.forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.veth0ee43ed.forwarding = 1
...

发现：net.ipv4.conf.eth0.forwarding = 0，将该参数net.ipv4.conf.eth0.forwarding = 1即可。

docker网络知识

安装 Docker 时，它会自动创建三个网络，bridge（创建容器默认连接到此网络）、 none 、host

docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
fbdb4890e912        bridge              bridge              local
4da8dfc54e00        host                host                local
17efe1215bbf        none                null                local

docker run --network=<NETWORK>可指定容器启动时使用那种网络模式

host模式

• 容器宿主机共用一个 Network Namespace
• 使用宿主机的 IP 和端口
• 不用任何 NAT 转换

None模式

• 关闭了容器的网络功能
• 容器并不需要网络时适用

Bridge模式

• 主机上创建一个名为 docker0 的虚拟网桥，主机上启动的 Docker 容器会连接到这个虚拟网桥上
• Docker 会从 RFC1918 所定义的私有 IP 网段中，选择一个和宿主机不同的IP地址和子网分配给 docker0，连接到 docker0 的容器就从这个子网中选择一个未占用的 IP 使用

Bridge网络配置过程

1. 在主机上创建一对虚拟网卡 veth pair 设备。veth 设备总是成对出现的，它们组成了一个数据的通道，数据从一个设备进入，就会从另一个设备出来。因此，veth 设备常用来连接两个网络设备。
2. Docker 将 veth pair 设备的一端放在新创建的容器中，并命名为 eth0。另一端放在主机中，以 veth65f9 这样类似的名字命名，并将这个网络设备加入到 docker0 网桥中，可以通过 brctl show 命令查看。

$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02425f21c208       no

3. 从 docker0 子网中分配一个 IP 给容器使用，并设置 docker0 的 IP 地址为容器的默认网关

route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0

Bridge网络通信原理

• 在 bridge 模式下，连在同一网桥上的容器可以相互通信，也可以 –icc=false禁止；
• Docker 可以通过 –ip_forward 和 –iptables 两个选项控制容器间、容器和外部世界的通信
• 与外界通信，是SNAT过程： -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
• 与容器通信，是DNAT过程：-A DOCKER ! -i docker0 -p tcp -m tcp --dport 10001 -j DNAT --to-destination 172.17.0.14:80

不支持在 Docs 外粘贴 block

自定义网络

高阶内容，不在本文探讨范围。

docker异常问题排查思路

1. 检查服务 监听 route规则
2. 检查系统转发 sysctl -a | grep "\.forwarding" | grep ipv4 forward相关的都必须为1 /etc/sysctl.conf: net.ipv4.ip_forward=1
3. 查看iptables，查看上文提到的关键路由规则，正常情况下，docker能把容器拉起来，iptables规则都不会有问题；

• 与外界通信，是SNAT过程： -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
• 与容器通信，是DNAT过程：-A DOCKER ! -i docker0 -p tcp -m tcp --dport 10001 -j DNAT --to-destination 172.17.0.14:80

4. 抓包，一般能到docker0的包，都能到容器eth0 宿主机eth0和容器eth0 宿主机eth0和docker0网桥
5. 常用命令 查看nat表： iptables-save -t nat 查看route表: route -n 统计nat包计数： iptables-save -c -t nat

参考内容

1. https://outmanzzq.github.io/2019/10/22/docker-network/#421-macvlan-bridge-%E6%A8%A1%E5%BC%8F%E7%A4%BA%E4%BE%8B%E7%94%A8%E6%B3%95
2. https://blog.crazytaxii.com/posts/docker_ip_dnat_error/
3. https://blog.csdn.net/taiyangdao/article/details/88844558
4. https://www.jianshu.com/p/96707d880a47
5. https://mp.weixin.qq.com/s/H8GRaJUZfys3GYs7WP2Qag