你的 VPN 网关仍然需要一条安装更新的路径

隧道对位于其后的所有人都在工作，网关转发他们的流量，然而这台机器本身却无法安装安全更新。这是该问题的常见形态：转发权限授予了客户端，而网关自身的出站连接从未被纳入规划。软件包管理器从网关打开了它自己的套接字，指向一个你很可能从未在防火墙策略中提及的仓库。

把网关锁紧是正确的。把它锁到不再接收补丁的程度则是另一个决定，而且往往是无意中做出的。

本地出站不是客户端转发

转发规则管的是从别处到达、经网关离开的数据包。网关自身的更新流量从不匹配这些规则；它在本地生成，走的是出站路径。这一区别解释了一个看似不可能的故障，而客户端访问却完全正常。

它也解释了为何一种策略缺口能逃过测试：在隧道后面的笔记本上快速检查一次，只能证明转发链有效，对主机自身的连接毫无说明。请把网关视为两个主体：一个带转发链的路由器，以及一个带出站链的主机。两者都需要一个说法，而通常只写下一个。

指出失败的环节

更新报错指向的是不同边界，在弄清究竟哪一环失败之前就去抓端口规则，会白白耗掉一个下午。无法解析的仓库名是解析器的问题，不是传输的问题。

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

在成功查询之后出现的超时，会把问题移到传输层：软件包管理器究竟尝试了哪个地址、哪个端口、哪个已配置的代理。TLS 校验失败则是第三件事，完全不同，它意味着连接好到足以完成协商。 关于归档认证的报错是第四个环节，它关乎签名元数据，而不是可达性。四个环节，四种不同的修复，而 ping 只能描述一种没有任何软件包管理器使用的协议。

先读源列表，再加规则

列出真实的源 URI 和实际生效的代理配置，而不是你记得的那些。当源是 HTTPS 时，为纯 HTTP 写的规则毫无用处；而 shell 知道的代理，对以另一套环境在启动时运行的服务可能是不可见的。

APT 的 HTTP 传输文档 涵盖环境与 APT 专属的代理设置，包括按主机选择，其 HTTPS 传输也有自己的校验设置。浏览器走的路径和软件包管理器走的路径是两条不同的路，即使在同一台机器上也是如此。

注意源解析到哪些地址族。只允许 IPv4 的规则，在源偏好 AAAA 记录的主机上会持续失败，而错误看起来时有时无，因为它取决于哪个应答先到。

选定一条维护路径并坚持下去

存在三种站得住脚的选择：经由隧道的维护流量、经由受管更新代理，或经由一条窄范围直连例外。请有意识地选定其中一种，并让解析器与之保持一致，因为名字解析走一边、连接走另一边的分裂会产生没人能解释的故障。

无论你选什么，都不能变成无限制的兜底通道。如果在隧道断开时禁止直连出站流量，那么一条悄悄放行一切的维护例外，就是伪装成修复的策略变更。把隧道自身的端点与引导需求放在与仓库访问不同的类别里，因为它们指向不同的目的地、以不同的方式失败，所以一个豁免无法覆盖另一个。

在不削弱校验的前提下验证

通过已经掌握策略的那道防火墙来实施范围，而不是因为某份指南用过就再加一个管理器。然后在维持的策略下运行一次元数据刷新和一次真实的软件包事务，并且读输出，而不只是看退出状态。

传输成功并不等于可以放松校验。归档认证与 TLS 服务器身份是两项独立的保证，为了让报错消失而关掉其中任何一项，改变的是你信任什么，而不是你能到达什么。

最后要有意测试隧道断开的情形。知道网关在没有隧道时如何表现是设计的一部分，在故障期间才发现则不是。断开隧道，运行元数据刷新，确认主机按你预期的方式失败，而不是悄悄回落到一条开放路径。把仓库与代理的凭据排除在共享诊断之外，并留下一条说明，写明谁负责这条更新路径。