隧道已建立却没有互联网：转发在哪里停下

客户端连接成功，隧道能把 ping 送到网关，而网关之外没有任何响应。对于只用于访问受保护网络的网关，这种状态是正常的；对于宣称提供全隧道出口的网关，这就是故障。在修改规则之前，先确认当初承诺的是哪种服务。然后沿请求可能停下的四个位置，跟踪一个公网请求。一个请求加一次抓包，比一整页猜测更有用。

确认互联网出口是否本来就是设计

拆分隧道配置文件只把受保护的子网导入 VPN，因此公网浏览仍走本地链路，从不经过网关。全隧道配置文件会在隧道里安装默认路由，于是网关要为整条路径负责。两者都是合理设计，混淆它们只会在没有问题的地方生成故障报告。在测试其他任何东西之前，先读客户端通告的路由，因为路由表能回答工单通常问错的那个问题。

客户端实际安装的内容，并不总是配置文件的本意。推送的路由可能被度量值更低的本地路由覆盖，而保留 LAN 路由同时添加默认路由的客户端，对该子网而言就像拆分隧道。

跟踪一个公网请求

选择一个目标，从客户端向外跟踪。在客户端上确认数据包是否真的选择隧道，以及使用哪个本地地址作为源。然后检查网关：数据包是否到达，是否从公网接口发出。这些答案中的每一个都能排除一整类原因。

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

如果网关从未看到数据包，那么客户端路由或隧道选择有误。如果数据包到达却没有发出，问题就在网关，剩下的三项检查适用。

检查转发、路由和地址转换

strongSwan 随附的转发指南适用于任何隧道类型的网关：必须允许内核在接口之间移动数据包，并且必须有一条可用的路由指向互联网。接下来防火墙策略必须放行流量，源地址必须是公网侧能够回复的地址。未经修改就转发到互联网的私有客户端地址，永远收不到回复。

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

源地址转换是常见的缺失环节。有了它，网关会把客户端源地址改写为自己的公网地址并跟踪流；没有它，回复就无处可去。云平台会增加第二道边界，实例的路由表或安全组可能会丢弃访客防火墙允许的流量。这道边界很容易被忽略，因为从内部看访客系统配置得完全正确。

在非对称部署中，反向路径过滤也可能丢弃有效数据包。要读那条规则的计数器，而不是想当然地认为没问题，因为公网接口上的严格设置会拒绝从与路由表预测不同的路径到达的流量。

回程路径和解析器是两个不同的答案

不仅要看请求，也要看回复。如果请求经过转换发出、回复又回到转换后的流，那么即使应用仍然失败，转发也是通的，下一步该查应用或 DNS。

返回 HTTP 错误的站点证明互联网转发在工作。地址访问正常但域名解析不了，这是解析器问题，不是 NAT 问题。

做完精准修正后，重新测试客户端，以及任何故意受限的私有资源。开放互联网访问不应悄悄扩大到网关连接的所有网络。