把所有流量转发到一台主机，还是连端口也改写？

把一切转发到 VPN 服务器，可能对应两条截然不同的规则。一条只改目标地址、保留入站端口；另一条连端口也改写到单一监听者。两者的暴露面并不相同，决定取决于三个条件，而不是路由器界面上的标签。

条件一：规则改的是哪些字段？

目标地址转换与目标端口转换是两项独立的操作。规则可以只做前者，也可以两者都做，区别在于目标主机上哪些服务可达。多数厂商界面把这层选择藏在一个标签背后。只有读底层规则，才知道自己拿到的是哪一种。

要看实际规则，而不是菜单标签。写着 DMZ 或全端口的界面描述的是意图，不是报文路径。Netfilter NAT 文档把两种转换分开来讲，即使眼前的路由器是家用设备，这也仍是正确的思维模型。

两个字段，两个不同的问题。

条件二：被保留的端口上有什么在监听？

如果规则保留入站端口，每个到达的端口都会被送到 VPN 主机上相同的号码，并受该主机入站策略的约束。这包括你可能忘了仍在监听的服务。规则并未创造这些服务，但它现在成了通往它们的路径。

如果规则改写端口，情况正好相反：大量外部端口被收敛到一个监听者上，主机上其他任何服务都无法通过该规则到达。固定端口改写不会因为一段很宽的外部端口范围匹配了它，就变成对所有本地服务的访问。两种设计的失败方向不同，而你选择的正是失败方式。选一个其失败你能接受的设计。

先清点监听者，再做选择。

条件三：外部入口有多宽？

只发布一个选定的端口，比发布一个范围更窄；两者又都比接受全部更窄。外部宽度与内部转换是彼此独立的选择，多数混乱来自改了一个却在描述另一个。

对普通的 VPN 入口，发布设计真正需要的传输协议和监听者。然后再检查三件事：路由器实际生效的映射、目标主机自身的入站规则，以及 IPv6 监听者是否发布了同一服务。在一个地址族里看起来窄的规则，在另一个地址族里可能很宽。

把转换后的端点完整写出来：协议、外部端口、内部地址、内部端口。

两条规则都给不了你的东西

两种设计都不能证明服务没有漏洞，也都不能保护可用性。无论端口映射多窄，认证、更新和恢复始终在范围内。窄映射减少的是可达面，并不能让监听者变安全。

一条已经在支撑另一项正当服务的宽规则属于依赖，而不只是错误。先清点，再通过其所有者替换，然后才移除；否则这次改动看起来就像安全修复引发的故障。同样的谨慎也适用于某个东西悄悄依赖的固定端口改写。

暴露面分析关心的是什么能到达什么，而不是屏幕上的标签。

拿着转换后的端点做决定

把规则的结果写成一句话：公网 UDP 端口 X 到达地址 Y 的端口 Z。然后问：Y 上哪些服务能在 Z 上应答，它们归谁所有。

nft list ruleset

如果答案是你预期的那一个监听者，规则就在履行职责。

如果答案是多个，那么无论界面怎么称呼，你选的其实是整机转发。