游戏服务器放进了 VPN，外面却没人进得来

服务器在跑，VPN 也连上了，可外面的人一个都进不来。隧道里的所有人都能进，于是它看起来像访问规则的问题。缺的不是权限，而是一条路径：一个玩家够得着的地址和端口，以及让回包原路返回的路由。VPN 的出口地址并不是入站托管功能。

玩家连到服务器的四种方式

真正的选择在于你的受众是谁、他们的数据包从哪里进来，这里值得命名的形态有四种。

私有方案最简单，也最不方便：被授权的玩家加入一个受限网络，通过游戏的私有地址访问它。给他们的是游戏服务的访问权，而不是一个可以在你名下每台主机上到处游走的共享身份。

中转方案是最容易被低估的一种。一台可被访问的网关接收公网流量，再通过私有隧道转给主机，于是玩家从不加入后端 VPN。中转必须承载游戏的传输层，而 HTTP 代理并不是通用的 UDP 中转。

像关注到达一样关注回程

对任何做转换的入口，记录四件事：外部地址、协议、端口和内部目标。Netgate 的端口转发参考讲清了一个容易绊倒人的区别，把目标地址转换与放行后续流量的防火墙规则分开。只配置其中一项，你得到的就是看起来正确、却什么都不放行的映射。

然后检查回程。被转发的请求可以完美到达，却因为主机从另一个出口回包而失败。中转可以对后端流的源地址做转换，也可以保留源地址、依赖路由；这是两套不同设计，也决定了游戏主机看到的玩家地址是什么。

加密救不回一条坏掉的回程。它保护的是一个区段，而不是一张拓扑。

隧道并没能让什么变得私有

游戏的认证、更新和准入策略仍各干各的。私有后端隧道并不会把有意公开的入口变成私有，也完全没有加密玩家到公开入口这一段。那是两段不同的路程、两种不同的暴露，而一句「游戏跑在 VPN 上」的设计说明，描述的恰好只是其中之一。

在把地址告诉任何人之前，先写下哪一段受保护、哪一段不受。

先定受众，再定地址

先决定谁该进得来，再挑匹配的方案。只给朋友，就是私有隧道，或者带白名单的中转。面向公开社区，就是带真实暴露的中转或直接入口，外加管理。定下来之后，在选定的方案里使用游戏文档中写明的端口，以及它对外公布地址的行为。

在一次测试通过之前，不要重排 VPN 网卡。那样会得到一个能用的服务器，却留下一条没人能在下次更新后重建的、没有记录的路径。

测试是两名玩家，一名在隧道内、一名在隧道外，两人都要完成一次加入和一轮流量。比这更少的验证，都不足以证明入口可用。