Azure 站点到站点 VPN 与位于 NAT 之后的对端:检查清单

请按顺序逐项检查,并在第一项失败处停下。大多数“Azure 不支持位于 NAT 之后的设备”的报告,最终都指向 Azure 无法访问的对端地址,或者一条从未由正确一侧发起的隧道。外层传输与内层路由是两个不同的问题,把它们混在一起会白白耗掉一个下午。下面每一步都会产出一个可以交给他人复核的观察结果。

第 1 步:先确认对端是否真的位于 NAT 之后

比较设备 WAN 接口上的地址与 Azure 为它看到的地址。如果两者不同,说明中间有设备在做转换,而这个转换设备现在已经是你 VPN 设计的一部分。向运营商确认映射是静态还是共享的,因为共享映射会改变你可以依赖的前提。使用私有 WAN 地址且没有任何转发的设备,与位于运营商级 NAT 之后、拥有稳定公网映射的设备,属于两种不同的情况。

如果两个地址一致,就此停下:NAT 不是你的问题,这份清单剩下的内容也帮不上忙。

把两个地址以及转换设备的型号记进工单。这一行记录可以省掉下一轮“为什么配置好的对端不回应”的追问。

第 2 步:就由谁发起达成一致

Azure VPN Gateway 常见问题说明了 NAT-T 支持,并补充指出:当本地设备位于 NAT 之后时,应由它来发起 IPsec 隧道。这与有状态转换的工作方式一致,因为正是内网设备先发出第一个包,转换设备才会保留映射。如果指望 Azure 发起,而没有任何报文去建立那条映射,隧道就永远不会启动。

配置对端时,让“只做响应方”这类错误一眼可见,并确认设备是自行重试还是需要外部触发。有些设备只有在出现感兴趣流量时才建立隧道,这在感兴趣流量是健康探测且永远不来之前都没问题。

在手动发起期间观察设备上的 IKE 交换;那里如果没有动静,答案在路由或防火墙上,而不在 Azure 上。

第 3 步:把对端地址配对

Azure 需要在其本地网络网关对象中为对端填写一个可达的公网地址,通常是转换设备的公网地址,而不是设备的内网地址。设备用来认证的身份是另一个字段,它可以与 Azure 拨号的地址合法地不同。务必把两者分清,因为一旦互换,就会产生看起来与 NAT 问题一模一样的认证失败。

如果公网地址发生变化,这个对象也必须随之更新。解析到过期地址的域名,比需要手工更新的静态地址更糟。

把三个值都写下来:设备本地地址、转换后的公网地址、配置好的对端身份。

第 4 步:只放行 NAT-T 需要的端口

NAT-T 把 ESP 封装在 UDP 中,RFC 3948 描述了这种封装:在 500 端口完成初始协商后改用 4500 端口。你的防火墙和转换设备都必须放行该交换及其返回流量。放开一个无关的 TCP 端口并不能证明这条路径可用,而只放行出方向、不放行回应方向的规则同样会失败。

当对端主动发起且转换设备保持状态时,并不必然需要静态的入站端口映射。当映射不稳定,或者路径上有什么东西会激进地让状态过期时,它才成为必需。

在转换设备两侧各抓一次包,封装差异立刻就能看出来。

第 5 步:把外层传输与内层路由分开

一条能建立却什么都传不过去的隧道属于路由问题,不是 NAT-T 问题。站点之间仍然需要兼容的流量选择器、匹配的地址空间、访问规则,以及应用网段的回程路径。这些都不是一次成功的 IKE 交换能提供的。

如果两个站点使用重叠的私有网段,隧道内部的转换是另一套设计,有它自己的规则。不要因为外层网关恰好放在家用路由器后面就重新编址某个子网。

在动手改动之前,先按阶段给故障分类,并把这份分类留在工单里,让下一位接手的人从你停下的地方继续。