阿里云的网络和弹性计算类产品很多，使用场景也多种多样，本文是一些使用场景的集锦。主要思路是从使用特定场景中发生的典型问题出发，总结网络产品使用中的关键点。
场景1: 使用VPN打通多个数据中心
架构
用户自己的数据中心通过专线和阿里云相连，同时用户使用了其他公有云的资源，利用阿里云VPN网关和其他公有云厂商打通IPsec VPN。架构和网段如下：
问题现象
参考文档“VPN网关配合云企业网搭建高速全球网络”，基本架构是可行的。这个场景和文档中的场景很类似，是阿里云VPN网关支持的场景之一。
但问题来了，用户在IDC机器上ping其他云上的资源10.200.1.15时，出现了如下报错信息，表示报文超过了TTL：
From 10.100.1.18 icmp_seq=1 Time to live exceeded
继续用 traceroute探测到目的地址的路径，可以看到在中间某节点出现了环路：
# traceroute 10.200.1.15
traceroute to 10.200.1.15 (10.200.1.15), 30 hops max, 60 byte packets
1 10.200.1.254 (10.102.81.254) 0.924 ms 1.249 ms 2.431 ms
2 172.17.0.3 (172.17.0.3) 0.544 ms 0.522 ms 0.673 ms
// 省略
7 10.100.1.18 (10.100.1.18) 2.641 ms 2.268 ms 2.156 ms
8 10.100.1.18 (10.100.1.18) 2.136 ms
9 10.100.1.18 (10.100.1.18) 2.328 ms
10 *
11 *
// 省略
29 10.100.1.18 (10.100.1.18) 2.828 ms
30 10.100.1.18 (10.100.1.18) 3.241 ms 3.168 ms 3.552 ms
从traceroute信息和网段信息可以判断10.100.1.18已经是阿里上的节点，但是用户表示这个出现环路的IP地址10.100.1.18是一个“未知”地址，是不是阿里云网络出了问题？
分析
首先IP地址10.100.1.18确实是阿里云中的地址，并且是VPN网关的私网地址，这个信息确实需要阿里云同学协助确认。在明确了这点后，再来看看上面的环路意味着什么。
在使用了阿里云VPN网关的情况下，要把去往其他云厂商目的CIDR 10.200.0.0/20的流量从VPN网关送出去，在VPC中需要添加如下路由条目：
正常的VPN网关应该怎么工作呢？收到去往CIDR 10.200.0.0/20的报文后，将报文封装后送进IPsec VPN隧道，通过公网送往对端。看看为什么可能出现环路。查看了VPC路由表配置是正常的，有一种可能性是去往CIDR 10.200.0.0/20的报文送到VPN网关后，VPN网关又来查VPC路由，看到报文下一跳是VPN自己，结果又把报文扔给自己，直到报文的TTL减少到0为止。
那VPN网关为什么没有将报文从公网送到对端呢？有一种可能性是去往CIDR 10.200.0.0/20的报文根本就没有做IPsec封装，从而接下报文还是走VPC路由，而没走公网路由送出去。
根因
沿着这个思路，再来看现象。发现有环路的IDC客户端地址是10.64.3.22，而有另外一些客户端可以正常ping通，地址基本上在10.16.x.y/16网段。所以这个问题变成了“ping相同目标地址，源IP地址不通，效果不通”，该问题并非路由问题了。
我们有理由怀疑是VPN网关没有配置对相映的内网网段做封装。查下VPN网关IPsec连接的本端网段和对端网段的配置(感兴趣流)，如下：
// 10.16.0.0/16表示线下IDC的网段，10.200.0.0/20表示其他公有云中的私有网段
10.16.0.0/16 === 10.200.0.0/20
可以看到本端网段设置为10.16.0.0/16，这个网段并不包括10.64.3.22，所以报文确实不会被封装进IPsec隧道，而一直在VPC路由的影响下形成环路。在本端网段中加入10.64.3.22所在的CIDR即解决问题。当然也可以简单地配置成0.0.0.0/0。
总结
用VPN/专线打通多个数据中心或者VPC是一个常用的混合云场景。但是因为VPN网关未能正确地配置相关感兴趣流网段，导致报文环路在一个对用户不可知的未知节点，带来了一定的排查成本。通过这个案例可以进一步了解VPN网关的在混合云中的使用场景，如何对报文进行封装，以及封装异常的后果。
场景2: ECS 操作系统内路由表对网络联通性的影响
架构
以云企业网为例子，用户利用云企业网打通了3个不同区域的VPC，默认3个VPC之间full mesh联通。
问题现象
3个区域各自分别有1台测试ECS机器：
- Region1 VPC, ECS1 IP 地址：172.17.0.64
- Region2 VPC, ECS2 IP 地址：172.18.1.22
- Region3 VPC, ECS3 IP 地址：172.31.4.18
安全组配置类似，都放行对方。ECS内也没有iptables规则
问题现象：ECS1 172.17.0.64 ping不通ECS3 172.31.4.18，但是ECS2 172.18.1.22可以ping通ECS3 172.31.4.18。
分析
这个问题本身并不复杂，但是如果把排查聚焦在云产品本身的属性和配置上，最终会徒劳无功。除了云产品保证跨地域的VPC顺利打通外，ECS操作系统主机网络相关的因素也直接影响联通性。最典型的就是操作系统内的iptables规则，其次操作系统内的路由表配置，ECS多网卡的策略路由等因素都会影响到网络连通性。
在这个案例里，如果对docker有所了解，那么172.17.0.64所属的网段172.17.0.0/16是带有典型特征的，这个是网桥docker0的默认网段。查看下ECS3 172.31.4.18操作系统的路由表，如下：
# ip route show
default via 172.31.0.253 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.31.0.0/24 dev eth0 proto kernel scope link src 172.31.4.18
根因
ECS3中去往目的网段172.17.0.0/16的报文会走docker0网卡。ECS1发往ECS3上的ICMP echo request被ECS3的eth0网卡接受到，但是回包走了docker0网卡，所以ECS1无法收到ICMP echo reply的回包，导致ECS1无法ping通ECS3。
如果不太熟悉docker，对该问题用常规的检查和抓包也能发现问题点。关键点是需要进行端到端的排查，即以操作系统开始为起始点开始分析。
总结
这个问题是ECS操作系统内路由表对网络连通性影响的一个简单示例。在ECS上跑很多复杂业务的情况下，业务软件(如docker, tunnel等)对主机路由表的影响应该也应该被更多地考虑进去。
