你的 IPv4 VPN 规则对 IPv6 流量只字未提

一次审计发现，同一块网卡上，隧道对 IPv4 被严格过滤，对 IPv6 却完全敞开。并不是哪里配错了、打错了字；规则集只描述了一个协议族，而所有人都假定另一个会跟着走。它很少会跟着走。三个条件决定你的规则是否真的覆盖两者，而第一条关乎平台，而非策略。

条件一：平台只有一张表，还是两张

有些包过滤器把 IPv4 与 IPv6 放在完全独立的规则集里，因此加到其中一张表上的规则，在有人复制之前对另一张毫无作用。另一些产品提供一个同时匹配两者的协议族，并逐包转换地址。第三类产品保留同一套策略语言，但在背后按协议族分别存储对象。

阅读你实际运行的那个过滤器的文档，然后列出存在哪些表、你的改动碰到了哪一张。数 IPv4 表里的规则，回答的是一个没人问过的问题。然后再列出存在哪些表、你的改动碰到了哪一张。

条件二：策略在哪里生效

有三处地方容易被混为一谈：接受隧道的监听端、把流量继续转发的路径，以及隧道没有承载流时客户端使用的普通网卡。网关可以接受会话，却丢弃从它转发出去的一切，这看起来像隧道坏了，而不是过滤器。写任何东西之前先消除这种混淆，因为这三处各有不同的负责人和不同的日志。把它们写进变更记录，才能避免修复落在离故障差一层的地方。

写下你的规则究竟要管这三处中的哪一处。保护监听端的规则并不保护转发路径，而这两者都不会封死客户端的直连路由。留意每一处归谁管，因为在多数组织里答案都是另一个团队。

条件三：IPv6 应该怎么办

决定 IPv6 是走隧道、在没有保护时被封堵，还是遵循有明文记录的例外。每种答案都会产生不同的规则集，而把问题悬着不决，正是客户端带着原生 IPv6 时，能在外网访问到它经 IPv4 在隧道内才能访问的目的地的原因。

在写规则之前，把答案大声说出来。对于不承载 IPv6 的隧道，封堵是正当选择，前提是有意为之并经过测试，而不是空表的意外结果。任何没有记录在案的事，都会被下一个动规则的人重新决定，而且通常很匆忙。

ICMPv6 是控制流量

邻居发现与路径反馈都跑在 ICMPv6 上，所以照搬 IPv4 习惯的一刀切丢弃，会同时破坏寻址和大流量传输。一刀切放行也不是答案，因为它交出了一条无人盯防的通道。

对重要的报文类型遵循过滤指引，其余的一律给出理由拒绝。最常被误诊的故障是缺少 Packet Too Big 报文，它表现为连接建立后卡住。

去证明它，一次一个协议族

分别在每个协议族上测试一次已授权的请求，如果策略本应在会话之后继续有效，就在重连后再测一次。只在 IPv4 网络上的测试无法验证 IPv6 路由，所以通过与否，对你想要堵住的泄漏毫无说明。测试运行时盯着计数器，因为一条从不命中的规则，并没有做它注释里声称的事。

每次只改一条限定范围的规则，并把之前的配置放在手边。如果策略由受管配置文件掌管，在本地修改前先联系它的管理员，因为下一次签入会覆盖本地修复，并把泄漏还原回去。