WireGuard服务器能与客户端握手，客户端却访问不了后面的内网。这通常需要沿数据路径检查，而不是重新生成全部密钥。握手抵达的是网关本机；穿过网关访问另一台机器，还要满足转发、过滤和回程条件。
01 / 区分本机接收与穿越网关
客户端访问网关的隧道 IP 属于本机接收路径，访问网关背后的内网则属于转发路径。nftables 的 input、forward、output 对应不同处理环节，放行监听 UDP 端口的 input 规则不会自动放行内层 IP 的 forward 流量。WireGuard 的 AllowedIPs 也不能替代这些过滤规则。
先确认实际接口名、网段、目标服务和管理工具。出口可能是物理网卡、桥接接口或 VLAN，不一定叫 eth0。开始前按服务器网络准备清单记录当前状态，并确认网络策略由 nftables、iptables、ufw、firewalld 还是其他程序管理，避免多套工具互相覆盖。
02 / 只读检查建立基线
ip -brief address
ip route show
ip rule show
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding
sudo nft -a list ruleset以上命令展示检查思路，并不修改系统。规则输出和备份可能包含内部地址，应在受控位置保存。IPv4 的 ip_forward 与 IPv6 的 forwarding 需要分别评估；启用内核转发不代表防火墙就允许通过。IPv6 路由器通告的接收行为也可能受转发设置影响，须结合当前网络配置核对。
03 / 让过滤规则准确描述访问
确定 wg0 到真实目标接口的方向、客户端来源网段和目标网段，再审阅对应 forward 链。状态跟踪可以允许已建立连接的返回流量，但规则的顺序、优先级、默认策略以及其他 base chain 都影响最终结果。某条链显示 accept，不代表后续其他链绝不会丢弃。
# 示意片段：必须合并到现有、经过审阅的规则链
# TUNNEL_IF / LAN_IF / SOURCE_NET / TARGET_NET 均须替换
iifname "TUNNEL_IF" oifname "LAN_IF" ip saddr SOURCE_NET ip daddr TARGET_NET accept
ct state established,related accept这个片段不是可直接导入的完整 ruleset，也没有替你设计 SSH 和本机服务策略。不要执行 flush ruleset，不要关闭整个防火墙。采用现有管理工具支持的验证与回滚方式，规则语法检查通过后仍要确认运行效果；留出控制台恢复入口，再做小范围变更。
04 / 先问目标怎样把包送回来
若目标设备收到来源为客户端隧道地址的请求，它需要一条返回该地址的路由。这条路由可能配置在目标自身，也可能由其默认网关提供。站点互联可以通过双向静态或动态路由保留原始来源，未必需要 NAT。查看路由与地址选择指南时，应把目标侧返回路径一并画出来。
当目标网络无法添加回程路由，且需求允许隐藏客户端来源时，才考虑受限 SNAT 或 masquerade。SNAT 明确指定转换后的源地址，masquerade 使用出口接口当前地址，是一种特殊的源地址转换。它们需要放在合适的 NAT 链及 hook 中，不能拿普通过滤链的 accept 当地址转换。
05 / NAT 要有范围，也有代价
把 NAT 限定到真实来源、目的和出口，避免给无关流量统一转换。客户端通过服务器访问互联网与访问私有内网的需求不同，不能一律套用全隧道加 masquerade。地址转换会让目标端难以直接区分原始设备身份，应评估日志和访问控制需求。
在一次受控请求中对照接口收发和规则计数：包有没有进入 wg0、有没有从目标接口出去、响应有没有回来。不要高频扫描目标。若外层握手本身也不稳定，先阅读UDP、Endpoint 与 NAT 保活排查，区分外层映射与内层网关转发。最后仍要验证目标应用自己的监听地址和访问规则。
