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

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

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

场景1: 使用VPN打通多个数据中心

架构

用户自己的数据中心通过专线和阿里云相连,同时用户使用了其他公有云的资源,利用阿里云VPN网关和其他公有云厂商打通IPsec VPN。架构和网段如下:
image

问题现象

参考文档“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 
AI 代码解读

从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中需要添加如下路由条目:
image

正常的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  
AI 代码解读

可以看到本端网段设置为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联通。
image

问题现象

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
AI 代码解读

根因

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

相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
怀知
+关注
目录
打赏
0
0
0
0
74
分享
相关文章
阿里云CDN:构建全球化智能加速网络的数字高速公路
阿里云CDN构建全球化智能加速网络,拥有2800多个边缘节点覆盖67个国家,实现毫秒级网络延迟。其三级节点拓扑结构与智能路由系统,结合流量预测模型,确保高命中率。全栈式加速技术包括QUIC协议优化和Brotli压缩算法,保障安全与性能。五层防御机制有效抵御攻击,行业解决方案涵盖视频、物联网及游戏等领域,支持新兴AR/VR与元宇宙需求,持续推动数字内容分发技术边界。
69 13
阿里云SLB深度解析:从流量分发到架构优化的技术实践
本文深入探讨了阿里云负载均衡服务(SLB)的核心技术与应用场景,从流量分配到架构创新全面解析其价值。SLB不仅是简单的流量分发工具,更是支撑高并发、保障系统稳定性的智能中枢。文章涵盖四层与七层负载均衡原理、弹性伸缩引擎、智能DNS解析等核心技术,并结合电商大促、微服务灰度发布等实战场景提供实施指南。同时,针对性能调优与安全防护,分享连接复用优化、DDoS防御及零信任架构集成的实践经验,助力企业构建面向未来的弹性架构。
167 76
阿里云携手神州灵云打造云内网络性能监测标杆 斩获中国信通院高质量数字化转型十大案例——金保信“云内网络可观测”方案树立云原生运维新范式
2025年,金保信社保卡有限公司联合阿里云与神州灵云申报的《云内网络性能可观测解决方案》入选高质量数字化转型典型案例。该方案基于阿里云飞天企业版,融合云原生引流技术和流量“染色”专利,解决云内运维难题,实现主动预警和精准观测,将故障排查时间从数小时缩短至15分钟,助力企业降本增效,形成可跨行业复制的数字化转型方法论。
阿里云X86/ARM/GPU/裸金属/超算等五大服务器架构技术特点、场景适配与选型策略
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别。本文将深入解析这些架构的特点、优势及适用场景,帮助用户更好地根据实际需求做出选择。
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
105 12
阿里云通用算力型U1实例怎么样?u1实例技术架构、场景适配与优惠价格参考
阿里云服务器ECS 通用算力型u1实例2核4G,5M固定带宽,80G ESSD Entry盘,企业用户专享优惠价格199元1年,很多用户关心这个款云服务器怎么样?阿里云通用算力型U1实例自推出以来,凭借独特的"均衡算力+智能调度"设计理念,在IaaS市场开辟出差异化的竞争赛道。本文将通过技术架构解析、典型场景适配分析、全生命周期成本测算三个维度,全面解构这款热门云服务器实例的核心价值,以供参考和选择。
网络安全与信息安全:知识分享####
【10月更文挑战第21天】 随着数字化时代的快速发展,网络安全和信息安全已成为个人和企业不可忽视的关键问题。本文将探讨网络安全漏洞、加密技术以及安全意识的重要性,并提供一些实用的建议,帮助读者提高自身的网络安全防护能力。 ####
121 17
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
随着互联网的普及,网络安全问题日益突出。本文将从网络安全漏洞、加密技术和安全意识三个方面进行探讨,旨在提高读者对网络安全的认识和防范能力。通过分析常见的网络安全漏洞,介绍加密技术的基本原理和应用,以及强调安全意识的重要性,帮助读者更好地保护自己的网络信息安全。
91 10
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
随着互联网的普及,网络安全问题日益突出。本文将介绍网络安全的重要性,分析常见的网络安全漏洞及其危害,探讨加密技术在保障网络安全中的作用,并强调提高安全意识的必要性。通过本文的学习,读者将了解网络安全的基本概念和应对策略,提升个人和组织的网络安全防护能力。

热门文章

最新文章