阿里云网络产品常见架构场景及问题

阿里云的网络和弹性计算类产品很多,使用场景也多种多样,本文是一些使用场景的集锦。主要思路是从使用特定场景中发生的典型问题出发,总结网络产品使用中的关键点。

场景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等)对主机路由表的影响应该也应该被更多地考虑进去。

上一篇:基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - ActiveXForm运行容器


下一篇:ShareDrop – 苹果 AirDrop 服务的 HTML5 实现