根据你的描述，基础VPN连通性没问题，但第二个地址空间10.0.2.0/24无法访问，我给你梳理几个关键排查方向，按优先级推进：

1. 确认VNet地址空间已纳入VPN路由宣告范围 #

这是最常见的问题根源：你新增的10.0.2.0/24地址空间可能没被包含在VPN连接的路由宣告里。

• 如果是站点到站点(S2S) VPN：
  • 检查Azure端的本地网络网关配置，确认其“地址空间”列表中包含10.0.2.0/24；
  • 同步检查对方VPN设备的配置，确保对方也将10.0.2.0/24添加到了向Azure宣告的路由前缀中。
• 如果是点到站点(P2S) VPN：
  • 先确认VPN网关的“点到站点配置”中地址池（你的是10.0.1.0/24）配置正常；
  • 在VPN客户端验证路由是否生效：
    • Windows：打开命令提示符，运行 route print，查找VPN适配器对应的路由条目，确认存在10.0.2.0 255.255.255.0指向VPN网关的路由；
    • Linux/macOS：终端运行 ip route show，检查是否有10.0.2.0/24的路由指向P2S虚拟接口。

2. 检查VPN网关的有效路由 #

即使未配置自定义路由，Azure网关也应自动学习VNet的所有地址空间，但偶尔会出现同步延迟或遗漏：

• 进入Azure门户的VPN网关页面，查看“有效路由”列表，确认10.0.2.0/24存在且下一跳类型为“Virtual Network”；
• 若该路由缺失，尝试重启VPN网关（注意：重启会导致VPN中断数分钟，请在业务低峰操作）。

3. 验证VNet地址空间的生效状态 #

确认10.0.2.0/24已成功加入VNet地址空间且配置无误：

• 进入VNet的配置页面，查看“地址空间”标签，确保10.0.2.0/24在列表中，无拼写错误（比如误写为10.0.1.0/24导致冲突）；
• 若刚添加不久，等待5-10分钟让配置同步到网关。

4. 排查流量是否到达目标虚拟机 #

虽然你提到安全规则一致，但可以通过流量日志和抓包进一步验证：

• 针对10.0.2.0/24内虚拟机的NSG，开启“流量日志”，过滤来自VPN地址池10.0.1.0/24的流量，确认是否有入站流量被意外拒绝；
• 在目标虚拟机上抓包：Linux用tcpdump -i any host <你的VPN客户端IP>，Windows用Wireshark，然后从客户端发起访问，观察虚拟机是否收到数据包：
  • 若未收到，问题出在网关或路由环节；
  • 若收到但无响应，检查虚拟机本地防火墙是否拦截了流量。

5. 检查VPN连接的路由宣告状态 #

进入Azure门户的VPN连接详情页，查看“已宣告路由”列表，确认10.0.2.0/24在其中。若是S2S VPN，还需确认对方设备已正确将该前缀推送给Azure网关。

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