AWS企业资质代办 AWS亚马逊云服务器内网互通设置

亚马逊aws / 2026-04-25 15:58:34

别再问‘我两台服务器为啥ping不通’了，先摸清AWS这张网

朋友，你有没有过这种深夜崩溃时刻：两台EC2明明在同一个VPC里，安全组也放行了所有端口，ping却像石沉大海？SSH连接超时？RDS连不上自己的应用服务器？别急着重装系统——大概率不是代码问题，是你还没真正看懂AWS这张“云上局域网”的说明书。

AWS不是传统机房，它没有物理网线、没有交换机面板、没有管理员帮你拔插网线。它的网络是软件定义的（SDN），每一条通路都得你亲手画出来、写出来、点出来。内网互通？听起来像“同个屋檐下说话”，但在这儿，得先确认：你们是不是真住在同一片屋檐下？屋檐下的门锁（安全组）开了没？走廊（路由表）通不通？连门牌号（私有IP）有没有抄错？

第一步：确认“同屋檐”——VPC和子网不能跨区乱配

很多人以为“创建EC2时选了同一个区域（比如us-east-1），就天然内网互通”。错！关键不在Region，而在VPC（Virtual Private Cloud）。VPC是你的专属云上网络空间，它像一栋大楼，而子网（Subnet）是这栋楼里的不同楼层。

⚠️ 踩坑实录：小张在us-east-1a创建了VPC-A，在us-east-1b又顺手建了个VPC-B，然后把两台EC2分别扔进去。结果？哪怕IP都是10.0.1.x，完全不通。因为VPC之间默认隔离，就像两栋独立公寓楼，隔壁阳台喊话，听不见。

✅ 正确姿势：两台EC2必须部署在同一个VPC下。如果已建好不同VPC，别删——用VPC Peering（对等连接）打通（那是另一篇故事）。现在请打开控制台，核对EC2详情页的“VPC ID”，确保一模一样。

接着看子网：同一VPC下，子网可以跨可用区（AZ），比如us-east-1a和us-east-1b的子网。只要路由表配对，它们依然能内网互通。但注意：子网CIDR不能重叠！比如一个子网是10.0.1.0/24，另一个填10.0.1.128/25？AWS会直接报错。合理规划如：10.0.1.0/24 和 10.0.2.0/24。

第二步：检查“门牌号”——私有IP是否真实有效

别信控制台显示的“私有IP地址”就一定靠谱。尤其当你启用了“自动分配IPv4地址”但又手动绑定了Elastic IP，或者重启过实例，私有IP可能被回收重发。

🔍 自查命令（登录任一实例）：
ip addr show | grep "inet 10\|inet 172\|inet 192"
看输出里是不是你控制台写的那个IP。如果不是？赶紧用aws ec2 assign-private-ip-addresses或控制台重新关联——别靠记忆，靠终端。

顺带一提：别用公有IP测试内网互通！公有IP走的是NAT网关或IGW，绕远路还可能被安全组拦截。务必用私有IP：ping 10.0.1.123，不是ping 54.2xx.xxx.xxx。

第三步：拧开“门锁”——安全组（Security Group）才是真·防火墙

很多人把安全组当“白名单”，只加了出站规则，忘了入站。或者更绝——给A机器开了入站SSH，却没给B机器开入站ICMP（ping）或应用端口。

💡 关键原则：安全组是无状态的（stateless），但作用于实例级别，且只管入站。也就是说：A想连B的22端口，B的安全组必须允许来自A私有IP的22端口入站；A的安全组则决定它自己能出什么（通常全放开即可）。

AWS企业资质代办 ✅ 实操建议：
• 给测试用的EC2，临时设置安全组入站规则：
- 类型：All ICMP - IPv4
- 源：自定义，填另一台EC2的私有IP/32（如10.0.1.123/32）
• 应用上线后，再细化为具体端口（如TCP 8080）+源IP段（如10.0.1.0/24）。

🚫 常见错误：
- 源写成“0.0.0.0/0”（开放全世界，不安全）；
- 源写成“sg-xxxxx”（引用其他安全组）但目标组没包含对应实例；
- 忘记保存——改完规则后一定要点右下角“保存规则”！

第四步：疏通“走廊”——路由表（Route Table）别成死胡同

同一VPC内，主路由表默认就有本地路由（Destination: 10.0.0.0/16 → Target: local），所以子网间互通本应自动生效。但如果你动过路由表……恭喜，可能亲手挖了条护城河。

🔍 检查路径：
1. 找到两台EC2各自所属子网 → 查看子网详情 → “路由表”关联项；
2. 点开该路由表 → 确认存在且状态为“active”的local路由；
3. 别手贱删掉它，也别加冲突路由（比如把10.0.1.0/24指向一个不存在的NAT网关）。

💡 进阶提示：如果你用到了多个自定义路由表，请确保每个子网绑定的是正确的表。曾有客户把数据库子网绑错了路由表，导致应用子网根本找不到它——不是网络断了，是地图画错了。

第五步：终极排查口诀——三查两试一重启

当以上都确认无误，还是不通？按顺序执行：

查日志：在发起方执行tcpdump -i eth0 icmp，看是否发出ping包；在接收方执行同样命令，看是否收到。没发出去？查安全组出站或本地iptables；收到却不回？查接收方安全组入站或系统级防火墙（Ubuntu的ufw、CentOS的firewalld）。
查系统防火墙：AWS不管OS层防火墙！sudo ufw status verbose 或 sudo systemctl status firewalld，临时禁用测试：sudo ufw disable。
查实例状态：确认两台EC2都是“running”，且状态检查（Status Checks）双绿勾。黄标或红标？可能是底层硬件问题，换实例试试。
两试：① 用telnet 目标IP 端口测TCP连通性（比ping更准）；② 在目标机上nc -lvp 8080，源机nc 目标IP 8080敲字，看能否实时回显。
一重启：别笑！有时NetworkManager抽风、DHCP租约异常，重启网络服务（sudo systemctl restart networking）或干脆重启实例，比调参快。

最后送你一张“内网互通自查清单”（打印贴工位）

✓ 两台EC2的VPC ID完全一致
✓ 私有IP用ip addr现场验证，非控制台截图
✓ 接收方安全组：入站规则含源IP+协议+端口（ICMP/TCP）
✓ 发起方安全组：出站规则默认全通，无需特别设
✓ 子网关联的路由表含且仅含一条active的local路由
✓ 操作系统防火墙已关闭或放行对应端口
✓ 用telnet或nc替代ping做最终验证

记住：云计算不是黑魔法，它是可预测、可调试、可掌控的精密系统。每一次“不通”，都是AWS在悄悄提醒你：“嘿，这儿少配了一行规则。” 把它当成解谜游戏，而不是玄学故障。下次再遇到内网问题，深呼吸，打开控制台，对照这篇清单——你离Connection established，只差三次点击和一次Enter。