封禁 IPsec 而不中断手机的 Wi-Fi 通话

这类请求的形式总是一样：在边缘关掉 IPsec，因为它承载了没人审批的隧道；而第一条投诉来自某个人——他手机上的 Wi-Fi 通话停了。两件事同时成立，但哪一件都不足以支撑撤掉管控。防火墙真正需要的，是一条写清功能名称、来源范围、目的地清单与责任人的服务例外。五步之后，它就成了明年陌生人也能复核的规则。

先给服务命名，再给协议命名

SIP 服务上的座机与走运营商 Wi-Fi 通话的手机并不共享同一套网络画像，而 VoIP 作为防火墙术语，两者都没说到。端口与目的地数据必须来自运营该服务的厂商或运营商，而不是照搬另一套电话系统里记下的端口表。这就是保护一项功能的规则与保护一个词的规矩之间的差别。

Apple 的 服务端口参考 列出 Wi-Fi 通话使用 UDP 500 与 4500，恰好就是多数一刀切 IPsec 封禁顺手丢掉的那一对。把功能名称写进变更记录，紧挨着这两个端口。再加一句所用参考的版本或日期，因为厂商的表格会改。写明存在理由的规则可以复核，只写协议类别的规则不行。

把例外写成契约，而不是人情

例外要写明允许的功能、使用它的设备类别、所需的传输方式，以及责任方记录在案的目的地。它还要带上责任人与复核日期，因为运营商端点和手机型号会变，而防火墙团队不会收到通知。复核要落到具体的人，而不是一个比团队活得更久的团队名。措辞要具体到陌生人仅凭记录就能重新推导出这条规则。

把例外放进与其他边缘策略相同的周期，这样运营商搬走目的地、或者机队更换手机型号时，问题会在复核中被发现，而不是等到下一次故障。把闭环交回给报告通话中断的人，因为只有他能在不重新打开那道被封的隧道的前提下确认修复。这条确认连同日期，也要进记录。

一条被标成临时修手机的永久放行，两年后就说不通了。绑定到已识别服务的放行，其到期时间是刻意续上的。

诚实地界定来源范围

把例外限定在受管设备网段，比向楼里每台笔记本开放协议要强得多。如果网络识别不出这个网段，就把这句话写下来，而不是暗示规则认得设备。最省钱的好结果，是复用一条因其他原因已经存在的边界，让例外继承一项管控，而不是另造一项。按地址过滤并不等于设备认证，变更记录不该暗示相反的意思。

源地址或硬件地址都不是实体手机的证明。它们有没有意义，完全取决于该网段内的其他管控。如果这条规则的理由挂在 MAC 地址上，先查清是什么阻止用户改掉它，再把规则发出去。

接受端口规则说不了的事

端口标识的是传输端点，不是业务意图。当已批准的呼叫服务和未批准的隧道都走同一个 UDP 4500 时，没有任何基于端口的规则能把两者分开。声称能做到的规则看上去很精确，其实并不能，这比承认自身形状的规则更糟。这是机制的边界，不是写规则的人的失误。

把这句话写在规则旁边，并把例外与网络现有的执行手段配套，例如设备管理或目的地白名单。然后把例外写得尽量窄，例如用 nftables 规则点明网段和端口对，再把通用拒绝放在其后：

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables 按顺序求值，命中第一条就停，所以限定范围的放行必须排在通用拒绝之上。把两条对调，例外就会悄无声息地什么都不做。

验证功能与封禁

用普通 Wi-Fi 通话执行已批准的验证，从例外所针对的设备类别发起，并确认被排除的客户端仍然失败。任何情况下都不要把紧急呼叫当作测试用例。然后检查真正下发的规则，因为计数器停在零，就是例外从未匹配过的最快证据：

nft -a list chain inet edge forward

测试里要包含重连或换网，并从冷启动重来一次——让手机加入网络，而不是已经连着。如果计数器在动而通话仍然失败，问题已经离开防火墙，属于运营商的目的地清单。