VPN 网关更新失败：先读阶段，再开出口

拒绝安装安全更新，只差一个糟糕的星期就会变成别人的问题，而放行客户端通过的网关是最容易养成这个习惯的地方。常见原因不是缺少路由，而是缺少决定：当客户端转发被故意收窄时，没有人说明主机自身该如何到达仓库。这个决定必须明确做出，而且必须比关掉出口策略一整个下午更窄。

四个阶段，四个不同的负责人

更新失败是一个有名字的阶段，无论消息是否明说，而每个阶段属于不同的负责人。无法解析的名字是解析器的问题。连接超时是传输、代理或远端的问题。TLS 身份错误是信任问题，而被拒绝的归档元数据是签名问题。四个阶段、四个负责人，而一条端口规则永远只回答其中一个。

The failure text mentions	Which component owns it	What you check first	What you must not change
a name that will not resolve	the resolver policy for this host	which resolver is used, and whether its path is permitted	nothing in the firewall: no repository packet has left yet
a connection that times out	routing, proxy or the far end	the destination, port and proxy the manager actually attempts	the egress policy, before you know that destination
a TLS identity mismatch	trust configuration and the server's identity	the chain the manager is presented with	verification settings, which only hide the mismatch
rejected archive metadata	the repository's signing metadata	whether the source carries valid, trusted metadata	the signature check, which is not a routing question

ping 和名称解析是人们最先拿起的两个测试，两者都回答了没人提出的问题。回显应答运行的协议与仓库连接不同，而成功的查询停在名称解析，并未测试抓取。两者都可能在真实事务失败时通过，也都可能因与路径无关的原因失败。

检查已配置的源 URI 和实际生效的代理安排，而不是假定其中之一。为纯 HTTP 写的规则在仓库使用 HTTPS 时并不是修复，而强制使用代理的组织早已选定了路径。包管理器遵循环境变量和自身配置，主机专属设置可以覆盖全局设置。交互式浏览器的行为不必等同于管理器的行为。

apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxy

APT 传输文档说明了哪些设置适用于哪种 URI 方案，以及主机专属选择如何书写。把命令输出与工单放在一起，因为它比任何数量的 ping 结果都更快地把代理问题与缺失路径分开。记下管理器尝试的确切目的地、端口和协议，让防火墙变更依据这份记录，而不是一个几个月就会过时的猜出来的镜像地址。

有三种策略站得住脚：通过隧道维护、通过受管更新代理维护，或通过严格授权的直连路径维护。每一种都意味着与之匹配的解析器安排。站不住脚的，是每当隧道断开就悄悄变成无限制回退的例外。

把选定的策略连同负责人一起写下来，因为下一个运维者会找到规则，却找不到背后的理由。通过现有防火墙和网络负责人来授权，而不是清空规则，或为一个主机再加一个策略管理器。覆盖真实源站使用的地址族和服务端点，并在仓库迁移时复查清单。

传输成功不是放宽验证的许可：归档认证和 TLS 服务器身份是两项不同的检查，关掉任何一项都会让错误消失，却改变了主机将接受什么。拦截型代理是网络负责人的信任决定，而不是在本地关掉检查的理由；仓库凭据不该出现在共享诊断里，因为详细日志是最容易泄露它们的地方。

用一次受控的元数据获取，再接一次已批准的软件包事务来接受这次变更，然后测试隧道断开时会发生什么。在故障期间悄悄变宽的维护路径，比直接闭合失败的路径更糟；结果应当是一条有具名负责人、范围受限的更新路径。