临时 IP 允许名单链接：授权究竟放行了什么

把一次点击变成一条临时防火墙规则很方便，但它同时构建了一套决定谁能访问服务的授权体系。它签发的是地址而不是人，一旦两个人共用同一个 NAT，这个区别就立刻重要起来。要界定授权范围、要求有意识的确认，并在构建链接之前让过期真正有意义。你面前的选择是把边界放在哪里，而不是要不要有边界。

先决定这项授权回答哪个问题

从需求出发。如果必须让某个具名的人访问服务，而应用已经对该人完成认证，那么经过认证的网关能把身份保留在执法点上，根本不需要放行地址。如果目标是构建代理、管理跳板端口，或者无法参与用户登录的设备，那么范围受限的地址授权可能是唯一可行的控制手段。

为面向用户的应用选择地址放行，只会把真正的授权问题挪到别处，门户最后替它从未补上的缺口背锅。

在服务端限定请求范围

浏览器不得自行选择目标、端口或前缀。门户依据自身记录解析服务，并用服务端测试核验权限，这与 OWASP 的授权指南 对每个请求所采用的原理相同。地址推导同样属于受保护的边界：反向代理报告客户端地址时，只接受已配置的代理链及其有据可查的头部处理方式。访客自行提供的转发头是对来源的声称，而不是来源的证据。

随后要确认门户与服务看到的是同一个来源。分离隧道、一次代理跳转，以及 IPv4 与 IPv6 的差异，都可能让两个目标拿到两个不同的地址，因此从一条路径激活的授权也许覆盖不了随后的请求。

安装之前先把授权摆出来

打开链接时应当展示拟授予的服务、观测到的来源与时长，而暂时什么都不改。正是这一步把邮件里的链接从一次动作变成一份提议，也让预览机器人或邮件扫描器无法仅凭抓取链接就授予访问。

确认应当是一个变更状态的请求，并带有通常的跨站与来源防护。令牌应当一次性使用，并在规则安装的那一刻原子地消耗；记录应当留下所有者、服务、地址、授权标识与过期时间，且绝不记录原始令牌。

令牌的投递值得和规则本身一样当心。已经过期或已被消耗的链接若仍能生成规则，那就是用同一把钥匙装上的第二扇门。

授权存续期间，地址依然是共享的

办公 NAT、运营商 NAT 和共享 VPN 出口，各自都把好几个人放在同一个地址后面。放行这个地址，就是放行它背后的所有人——就服务下一道边界而言——，而对究竟谁持有服务所期待的账号，什么也证明不了。

删除规则也不是一刀切的断连。已建立的连接、缓存的应用程序令牌和长寿命会话，可能比规则多活几分钟甚至久得多，因此你选择的寿命应当反映服务在放行之后会做什么，而不只是规则存在多久。

测试四种情形，以及两个地址族

授权的好坏只取决于它能否扛住四种情形：新获得允许的请求、未获批准的请求方、同一链接的重放，以及过期之后的同一请求。

然后要分别测试两个地址族，因为服务观测到的源地址在两者之间可能不同。

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

有用的结果是：在常规用户授权之下、有一份临时的、可审计的放行决定，而不是一个永久的开口，上面写着最先点击者的名字。