[肥用云计算] 同一个云企业网内的机器 互相ping不通？

注意是 【同一个云企业网】，非【同一个VPC】。云企业网，其实就是把两个及以上的VPC链接起来的一个功能，由云计算厂商提供。云企业网，具体的搭建可以参照各自云产商的文档。同时【云企业网】取自阿里云产品的话术，每个云计算商的产品都大同小异，注意话术。

前言

最近小伙伴遇到使用云计算过程中遇到一个问题：

1. 有两个不同的 VPC，分别是 netA，netB，同时他们有两个不同的子网 subnetA，subnetB
2. 两片的 VPC 都是使用 云企业网 进行链接
3. 有A，B 两台 服务器 分别是存在两个子网内
4. 发现 A，B 两个 _服务器 _无法 ping 通

小伙伴之前也搭建过类似的网络，之前是可以互通网络的，本次就无法ping通；检查了各种涉及的组件，都没有发现问题，比如 云企业网，安全组，对应的路由等。😵一脸懵逼。

从迷惑到解决问题的过程比较有意思，所以特意进行记录一下。

解决过程

云网络配置

我们知道，云计算宗旨就是 云计算，云存储，云网络。所有的网络都是云计算商提供，设置都脱离于内部机器的配置（比如 linux iptables等），所以首先检查了 云网络的配置。
云网络的配置：

• vpc-netA: 172.18.0.0/16, sunetA: 172.18.32.0/20，macA: 172.18.46.94/20
• vpc-netB: 172.16.0.0/12, sunetB: 172.16.0.0/24，macB: 172.16.0.229/24

云企业网都使用了默认配置，没有太多的异常。固有下面的网络拓扑图。

网络拓扑图：

👻 疑点出现：vpc-netA 和 vpc-netB 网段有可能相互重复。还不能确定，只有使用命令继续检查。

命令排查

尝试 【从 A ping B】。

[root@macA ~]# ping 172.16.0.229 -c 4
PING 172.16.0.229 (172.16.0.229) 56(84) bytes of data.

--- 172.16.0.229 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

ping from A to B 没有提示，一直丢包。

尝试 【从 B ping A】。

[root@macB ~]# ping 172.18.46.94 -c 4
PING 172.18.46.94 (172.18.46.94) 56(84) bytes of data.
From 172.18.0.1 icmp_seq=1 Destination Host Unreachable
From 172.18.0.1 icmp_seq=2 Destination Host Unreachable
From 172.18.0.1 icmp_seq=3 Destination Host Unreachable
From 172.18.0.1 icmp_seq=4 Destination Host Unreachable

--- 172.18.46.94 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms
pipe 4

ping from B to A 提示 Destination Host Unreachable 无法触达到目标机器。提示与【从 A ping B】的不一样。按照提示理解，就是 ipA 是无法触达的。即路由表已经有可以直接触达 ipA 的配置。

继续使用抓包进行检查。

[root@macA ~]# ping 172.16.0.229
PING 172.16.0.229 (172.16.0.229) 56(84) bytes of data.

[root@macB ~]# tcpdump -i eth0 -n -vvv -c 1000 ip host 172.18.46.94
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:05:41.904107 IP (tos 0x0, ttl 64, id 11307, offset 0, flags [DF], proto ICMP (1), length 84)
    172.18.46.94 > 172.16.0.229: ICMP echo request, id 30183, seq 19, length 64
19:05:42.904075 IP (tos 0x0, ttl 64, id 11996, offset 0, flags [DF], proto ICMP (1), length 84)
    172.18.46.94 > 172.16.0.229: ICMP echo request, id 30183, seq 20, length 64

使用命令 在 macA 一直ping，同时在 macB 中进行抓包。发现 macB 可以接收到 echo package，但是没有 reply request。🦄 即 ipA 是可以路由到 ipB 的；反之，不行。

接着在 macB 上使用命令解析 ipA 的路由。

[root@macB ~]# ip route get 172.18.46.94
172.18.46.94 dev br-ef577d1b9435 src 172.18.0.1

🦄 真相开始慢慢浮现了，发现 ipA 的地址，并不是解析到 macB 的实体网卡 eth0 上，而且在一个 虚拟的网桥（br-ef577d1b9435）上。

如果预期是 ipB package 可以路由到 ipA，那么 package 应该是经过 macB 实体网卡 eth0，再经过 云企业网 到 macA 中的。

[root@macB ~]# ip route
default via 172.16.0.253 dev eth0
172.18.0.0/16 dev br-ef577d1b9435 proto kernel scope link src 172.18.0.1  # 这个是关键
172.19.0.0/16 dev br-a9435e042dfa proto kernel scope link src 172.19.0.1

🦄 原来真相是 macB 上使用了 docker，docker 创建了 172.18.0.0/16 网段的 网桥网络，并且这个网段与 subnetA 是重合的。

其实不能怪 docker，因为 netB 的 docker 根本都不清楚 subnetA 的网络情况

路由的解析过程

一起回顾一下 ip 路由的解析过程

1. 首先会检查路由表，是否有对应的路由是符合 要路由的IP 的
2. 如果有，就把这个IP 发送到对应路由网关
3. 如果没有，就会把这个IP 发送到默认网关

所以上例中，ipA package 在 macB 准备发送，macB 会检查路由表，发现 ipA 符合 docker已创建网桥的网段，就会发送到对应的网卡（br-ef577d1b9435）上。

解决办法

快解：在 macB 把 172.18.0.0/16 网段的 docker 创建的网桥网络删除掉，让 ipA 可以默认路由，从 eth0 出，就可以解决问题。
但是这种方案无法限制后续 docker 创建 172.18.0.0/16 或者 有交集网段的网络。正解，还是需要重建VPC网络，让他们不要有交集。

总结

在后期使用云计算过程中，VPC 网段 是一个设置了就不能改变的变量，所以一定要做好前期的规划。

1. 各自的 VPC 网段要互相隔离，不要有交集。比如 172.18.0.0/16 与 172.16.0.0/12 就是有交集了；172.18.0.0/16 与 172.16.0.0/16 就没有交集了。
2. 如果服务器里面需要安装 docker，那么 docker 都尽量设置好 非VPC 使用的网段。比如，本例中可以设置 192.168.0.0/16