同一虚拟网络内不同子网VM无法通信求助：此前正常无NSG/防火墙阻隔

这种突然爆发的同VNet子网间通信故障确实挺闹心的，既然你已经排除了NSG、本地防火墙和DNS解析的问题（毕竟试过IP直连了），咱们从几个容易被忽略的点一步步排查：

• 核对子网路由表的突发变更
  你提到了app01的有效路由，得仔细盯着这部分：有没有新增的自定义路由把子网间的流量给导偏了？比如不小心加了一条优先级比默认VNet内部路由还高的0.0.0.0/0路由，指向了互联网网关或者其他虚拟设备？
  可以用命令导出完整路由表对比之前的状态（如果有备份的话）：

  # Azure环境示例
  az network nic show-effective-route-table --name app01-nic --resource-group your-resource-group
  # AWS环境示例
  aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=your-subnet-id"
  

  重点看目标地址包含对方子网的路由条目，下一跳是不是VNet本地（对应云平台的内部路由标识），有没有被其他路由覆盖。

• 检查VNet与子网的配置变动
  有没有人误改了子网的地址范围？比如把其中一个子网的CIDR改成和另一个重叠，或者移出了VNet的总CIDR范围？这种操作会直接导致VNet内部路由失效。
  另外也要确认：子网有没有被意外关联到错误的路由表，或者原本的路由表被清空了？

• 清理ARP缓存排除链路层问题
  虽然你用IP通信，但ARP缓存异常也可能导致无法建立连接。在两台VM上分别执行：

  • Windows：arp -d * 清空ARP缓存，之后再ping对方IP试试
  • Linux：ip -s neigh flush all 或者 arp -a -d
    清空后重新发起通信，看是否恢复。

• 排查云平台底层网络的临时故障
  云服务商偶尔会出现底层网络的波动，比如子网所在的物理节点故障、核心网络设备重启等。可以去云控制台的状态页面，看看对应区域有没有网络相关的告警。
  另外试试把其中一台VM重新部署（不是简单重启，是通过云平台的重新部署功能让它迁移到其他物理节点），很多底层节点的问题都能通过这个操作解决。

• 用工具定位TCP连接的具体失败原因
  只靠ping可能不够，用更精准的工具测试：

  • 用telnet <目标IP> <端口>或者nc -zv <目标IP> <端口>测试具体TCP端口，区分是连接超时（路由/网络层面问题）还是连接被拒绝（可能存在隐藏的安全策略）
  • 用tracert <目标IP>（Windows）或者traceroute <目标IP>（Linux）跟踪路由，看看数据包卡在了哪一步。如果直接跳去了互联网，那肯定是路由表被篡改了；如果卡在VNet内部节点，那大概率是云平台的内部网络问题。

如果以上步骤都排查完还是没找到根因，建议收集两台VM的网络诊断日志（比如用tcpdump抓包，或者云平台自带的网络监控工具），分析数据包的走向，应该能精准定位到阻塞点。

内容的提问来源于stack exchange，提问作者Gregory Suvalian