路由器上的 VPN 还是端口转发：谁更胜一筹？

路由器自己终结了 VPN，但一条旧的转发规则仍把同一个 UDP 端口送往局域网中的某台机器。两者只有一个是真正的终点，而内核并不替它们仲裁。目的地址转换会在查询本机服务之前重写数据包，于是 VPN 进程一直等待已经发往别处的流量。任务就是判断这个端口归谁，然后让规则彼此一致。

一个端口，两个声称的主人

在路由器内部运行的 VPN 服务器需要一条指向自身套接字的入站许可。而同一端口的目的 NAT 条目却通向完全不同的地方：一个局域网地址和一项转发决定。它们是不同的终点，日志不同，失败方式也不同。常见的线索是：一个地址族能用，另一个不能，因为那条遗留条目只为单一地址族而写，此后从未复核。

动手之前先写下主张：地址族、外部地址、传输协议、端口，以及转换后的目标。

转换先于本地检查发生

目的 NAT 在预路由阶段就改变了数据包的目标，早于内核在本地交付与转发之间做选择。一旦目标变成局域网主机，数据包就走转发路径。路由器自身套接字的入站规则根本不会被查询，所以当客户端超时时，VPN 日志仍是空的。

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

这个先后顺序就是全部机制，设备界面把它藏在复选框后面，却并不改变它。数据包走哪条路径，仍由目的地的主人决定。

如果局域网主机才是预期终点，转发就是对的，路由器不应同时监听该端口。

保留一条映射，删掉另一条

列出该端口与该地址族的 NAT 条目，选出留下的那条：

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

同一号码的 TCP 条目与 UDP 故障无关，把它们当成一个对象，就会删错规则。当本机套接字应当胜出时，冲突映射的主人只删除或改写那一条，而路由器自身端口的入站许可原地不动。无关的转发、管理路径和规则集副本都应在这场改动中保留下来。

如果 VPN 住在另一台主机上，转发才是正确对象。容器或虚拟机里的服务，即便盒子被叫作路由器，也可能需要发布端口，所以要追查套接字及其命名空间，而不是外壳上的标签。

从外部确认归属

分别测试每个地址族，因为终结在路由器上的 IPv6 连接，说明不了被旧规则改向的 IPv4 连接。读接收服务的日志，看究竟是哪个终点回应，并把客户端的成功提示当作弱证据。要得出有意义的结论，必须建立新的连接。从外部主机用 nc -zvu 203.0.113.7 1194 发送探测，再用 journalctl -u openvpn@server -n 20 读出胜者的日志。路由器监听器自己记录连接，而局域网主机会在自己的服务里记录。

连接跟踪会把已有流量固定在原映射上，所以一条已建立的会话，可能比你刚修好的规则活得更久。

当预期终点以正常的身份校验作出回应后，再测试隧道后的私有资源。到达外层监听器只是第一跳；内层路由与应用授权是另外的结果。