Firebox 地理位置拒绝：先定位 VPN 入口环节

身处其他国家的用户连不上，第一反应往往是去看那条授予内部资源访问权限的规则。那条规则在准入之后才执行，所以不可能是它拒绝了隧道。真正的阻断环节位于入口路径的某处，而 Firebox 会根据 VPN 服务的不同拥有不止一条入口路径。请按顺序做完这些检查，一旦其中一项解释了拒绝原因就停下来。

检查 1：先确认接入的是哪个服务

对于 SSL 版 Mobile VPN、Access Portal 和基于 TLS 的 BOVPN，入口就是 WatchGuard SSLVPN 策略。请在该策略、也就是实际配置的服务上施加预期限制，而不要依据之后才执行的用户访问规则去推断。

IPsec 走的是另一条路径。内置 IPSec 策略会为相关的分支和移动 VPN 服务允许外部 IPsec 流量进入 Firebox，并且它优先于手工创建的 IPSec 策略。如果你的客户端是 IKEv2，你就在这第二条路径上，SSLVPN 策略与此无关。

在这个领域，最常见的白费下午就是在这里出错：改了一条根本看不到数据包的策略，然后得出限制不起作用的结论。

做一次受控的允许尝试，并把四件事对应起来：客户端的公网源地址、命中的入口服务、匹配到的策略，以及日志中任何 Deny 原因。WatchGuard 的 IKEv2 故障排查指南指出，地理位置和默认数据包处理可能会在内置策略准入之前就拒绝流量，这意味着你看到的拒绝可能指向一个你还没考虑过的环节。

国家或地区分类依据的是实际观测到的网络来源。漫游用户、上游 NAT 或另一条获批路径都可能改变 Firebox 看到的结果，所以要核实地址，而不是听用户描述自己在哪。请索取客户端看到的公网地址，并与 Firebox 日志中的源地址比对。两者不一致时，说明分类依据的是一条没人提到的路径。

如果手工 IPSec 策略看起来被忽略，请检查内置策略是否仍然启用。被更高优先级的内置规则遮蔽的手工规则，与作为唯一准入的手工规则，是界面看似相同、实则不同的两种配置。

先决定你希望由哪一个来掌控这条路径。如果选的是手工策略，就必须针对该流量停用内置策略，下一项检查正是从这里开始。

停用内置 IPSec 策略会移除它对受影响 VPN 服务的准入，其中也包括你在修某一个移动用户连接时可能没想到的分支隧道。

先规划完整的替代方案：哪些服务需要准入、它们获得哪些源范围，以及变更出错时你如何管理设备。务必保留一条独立的管理与恢复通道，因为这里的失误可能删掉你用来修复它的那条隧道。在变更记录中写明恢复步骤，包括 VPN 路径失效时如何访问设备。然后要测试续期，而不只是首次连接。

活动连接和后续重新协商都可能依赖准入。只在你测试过的那次会话里有效、到下一次密钥更新就失败的变更，是替换准入却不测试续期的典型结果。

地理位置只是为入口决策补充上下文。它不能确定用户是谁，也不应取代网关身份校验、账户授权或 MFA。

如果业务要求只是仅有获批地点中的获批用户，那你需要两项控制。允许整个国家或地区的定位规则不能替代身份验证，而已通过身份验证的用户处在被封禁的国家，属于策略问题而不是缺陷。

写下服务、入口策略、预期的位置范围、例外情况以及恢复负责人。然后在变更后测试移动路径和至少一条站点路径，让这项限制始终绑定在它本就要管控的服务上。

最后，回头再读一遍你最初遇到的那条拒绝。如果它已经从位置拒绝变成身份验证或授权失败，说明入口问题已解决，另一个问题浮现了出来。关于上文所述的环节顺序，WatchGuard 的 IKEv2 拒绝指南就是参考。