封禁 VPN 出口，封的是地址，不是人

有人把一个 VPN 服务商的出口地址加进拒绝列表，滥用确实停了一天。接着，一位恰好也用这家服务商的客户提了工单，规则比任何人描述的都要宽。封禁从来都是关于地址的决定；问题在于它被当成关于身份的决定来卖。写下一条规则之前，先把这两件事分开。

你能执行的规则，针对的是源地址

防火墙规则匹配的是数据包中的某个字段，而你匹配的字段是源地址。这条规则能可靠地拒绝来自该地址的流量，这是真实而有用处的效果。但它无法告诉你包是谁发的、用了哪个账户，也无法说明这个人是不是昨天制造问题的那个人。写规则很容易；讲清它到底证明了什么，才是团队出错的地方。

如果目标是阻止某种特定行为，地址规则只是一件恰好手边有的钝器。如果目标是识别某个用户，地址就是错误的证据，应用的认证才是正确的证据。在下规则上线之前，先决定你要的是哪个目标。

注册信息查询究竟告诉了你什么

注册库查询返回的是某个网络的分配块和登记联系人。它不会列出每个地址上运行的服务，也不会告诉你请求来自哪个租户。即便是很小的登记块，也可能包含不同客户互不相关的工作负载。

dig +short exit.example.net
whois 203.0.113.0 | head -40

解析出口主机名，得到的是那一刻返回的地址，那是一次快照，而不是一份清单。把一个答案扩展到整个托管前缀，是另一个影响范围更大的决定，而不是同一份证据的更完整版本。如果你使用维护中的分类数据源，它的标签只是一种猜测，两个方向都有已知误差。它不是认证，也不是人员名单。

如果拟定的规则仅凭一次查询就成立，那就停下。快照不是范围决定。

共享出口与附带伤害

共享出口承载许多用户，而共享地址空间意味著一个公网地址可能代表一整组订户。封掉它会影响所有人，包括与滥用毫无关系的人。扩大到周边前缀会让这一影响成倍放大，也更容易误伤无关服务。附带伤害不是事后再补记的副作用；它是这条规则定义的一部分。

数据包证据也有自己的边界。孤立 SYN 中的源地址可以被伪造，因此数据包并不能确定是谁发起了什么。半开连接状态只说明握手开始了，并不说明对端对反射攻击负有责任。已完成的连接所说明的，与应用日志并不相同；而经过认证的会话所指明的账户，两者都指不出来。

在策略允许的范围内选最窄的一档，并写下预计会被误伤的人是谁。

该记录的证据，以及用户的回来之路

每条地址规则都应带上使它成立的那次观察、日期、范围和一个复核时间点。正是这份记录，让下一个人可以收窄规则，而不是去猜它为什么存在。没有它，临时封禁就会变成永久设施。

nft list ruleset | grep -n 203.0.113
ss -tn state syn-recv '( dport = :443 )'

在部署封禁之前，先定下正当用户如何恢复访问，因为支持队列不是恢复方案。申诉通道、有记录的例外，或者另一种接入方式都可以；叫人别用 VPN 则不行。把网络规则与贴合行为的控制配对：速率限制、更严的账户权限，或在服务内部执行。VPN 出口封禁可以减少不需要的流量，而不必假装自己是一份用户名录。

要盯住的症状，是规则实际做的事与人以为它做的事之间的落差。封禁拒绝的是一个地址。账户识别的是一个用户。把这两句话在工单里分开写，下一条规则会更容易辩护。