VPN 的云安全组：只开监听端口，而不是全部

VPN 服务器在运行，客户端却超时，第一反应往往是给安全组加一条全放通规则。这样有时能通，而这正是最糟的结果，因为现在没人知道究竟哪一道边界被关上了。客户端与守护进程之间有四道彼此独立的过滤器，安全组只是其中之一。

先确定协议，再写规则

一条规则由协议、端口范围和来源组成。WireGuard 监听 UDP，通常是 51820。OpenVPN 通常按配置走 UDP 或 TCP 1194。IPsec 需要 UDP 500 和 4500 上的 IKE 交换，还需要 ESP 协议本身，它是协议号而不是端口。因为其他规则是 TCP 就猜 TCP，正是得到一条看起来正确、却什么都匹配不上的规则的原因。

监听端口要从正在运行的服务里读，而不是从教程里抄。绑定在一个地址上的守护进程不会接受发往另一个地址的流量。

把来源限制在设计允许的客户端范围，而不是整个互联网。

安全组是有状态的，子网 ACL 不是

安全组是有状态且只允许的：放行的入站流量会自动获得回包，也没有需要推理的拒绝规则。子网 ACL 无状态，且双向评估，所以只有入站放行、没有对应出站临时端口范围时仍然不通。这个差别解释了很多在控制台里看起来正确的规则。

还要确认正在运行的端点绑定的是哪条策略，因为一个实例可以挂多个安全组，而挂在未绑定组里的规则什么也改变不了。

生效的策略是已绑定规则的并集，而不是你编辑的那个文件。

主机防火墙是另一道边界

云上的策略把流量放行到网卡，之后由操作系统决定守护进程是否看得到它。默认拒绝策略的主机防火墙 会丢掉安全组已经放行的包，而云控制台不会显示任何拒绝，因为它从来没有表过态。两处都要查，顺序按数据包实际经过的先后。

如果主机使用发行版防火墙的前端，要确认底层规则而不是配置文件名，因为配置文件可能处于启用状态而端口是关的。

在接口上抓包能告诉你哪一道边界丢掉了包。

放行监听端口并不等于为客户端做路由

转发客户端流量的 VPN 网关需要的不只是一个打开的端口。它需要 IP 转发、一条允许从隧道接口到目标网络流量的策略，而且往往要在接口上关闭源/目标检查，以免平台丢弃不是发给它的流量。这些都不是监听规则能创建的。

握手正常而数据路径不通的分界就在这里，也是隧道状态看起来健康、却什么都加载不出来的原因。

把路由当作一次独立的变更来修，并配自己的验证；同时注意转发网关还需要一条允许目标网段的出站策略。

先留好回退通道，再收窄规则

改动远程防火墙策略之前，先确认存在独立的管理通道，例如会话管理器、串口控制台或带外网络。如果唯一的管理通道正好经过你要改的那条规则，你就没有恢复手段。然后应用收窄后的规则，用真实客户端测试，并把这次尝试与服务端证据对照。同一台机器上另一个服务的响应，并不能证明监听端口被访问到了。

窄规则一旦生效，就删掉任何实验性的宽放通，并记下这条规则为什么存在。AWS 记录了安全组的有状态行为，当有人提议用宽范围走捷径时，该引用的正是那份文档。

把绑定关系也写进文档，否则更换网卡时会悄无声息地丢掉策略。