A atualização do gateway VPN falha: leia o estágio antes de abrir a saída
Uma atualização falhada nomeia um estágio, não uma porta em falta. Associe a mensagem ao seu dono, leia o caminho do proxy e depois decida a política de manutenção de propósito.
Recusar instalar atualizações de segurança está a uma má semana de se tornar o problema de outra pessoa, e um gateway que admite clientes é o local mais fácil para desenvolver esse hábito. A causa habitual não é uma rota em falta mas uma decisão em falta: ninguém disse como o próprio host deve chegar a um repositório quando o encaminhamento de clientes é deliberadamente estreito. Essa decisão tem de ser tomada explicitamente, e tem de ser mais estreita do que desligar a política de saída durante uma tarde.
Quatro estágios, quatro donos diferentes
Uma falha de atualização é um estágio nomeado, quer a mensagem o diga quer não, e cada estágio pertence a um dono diferente. Um nome que não resolve é uma questão do resolvedor. Uma ligação que expira é uma questão do transporte, do proxy ou do extremo remoto. Um erro de identidade TLS é uma questão de confiança, e metadados de arquivo rejeitados são uma questão de assinatura. Quatro estágios, quatro donos, e uma regra de porta só responde a um deles.
| 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 |
O ping e a resolução de nomes são os dois testes a que as pessoas recorrem primeiro, e ambos respondem a perguntas que ninguém fez. Uma resposta de eco exercita um protocolo diferente do da ligação ao repositório, e uma consulta bem-sucedida para na resolução de nomes sem testar a obtenção. Qualquer um deles pode passar enquanto a transação real falha, e qualquer um pode falhar por motivos sem relação com o caminho.
Leia o caminho que o gestor realmente toma
Inspecione os URI de origem configurados e a disposição efetiva do proxy em vez de assumir qualquer um deles. Uma regra escrita para HTTP simples não é uma reparação quando o repositório fala HTTPS, e uma organização que exige um proxy já escolheu o caminho. Os gestores de pacotes respeitam as variáveis de ambiente e a sua própria configuração, e definições específicas do host podem sobrepor-se a uma global. O que um navegador interativo faz não tem de ser o que o gestor faz.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyA documentação do transporte APT descreve que definições se aplicam a cada esquema de URI e como se escrevem as escolhas específicas do host. Guarde a saída dos comandos com o ticket, porque separa um problema de proxy de uma rota em falta mais depressa do que qualquer número de resultados de ping. Anote o destino, a porta e o protocolo exatos que o gestor tenta, e deixe a alteração da firewall assentar nesse registo em vez de num endereço de espelho suposto que fica obsoleto em poucos meses.
Escolha uma política de manutenção, não uma exceção
Três políticas são defensáveis: manter através do túnel, manter através de um proxy de atualização gerido ou manter através de uma rota direta estreitamente autorizada. Cada uma implica uma disposição do resolvedor que lhe corresponde. O que não é defensável é uma exceção que se torna silenciosamente num recurso ilimitado sempre que o túnel cai.
Anote a política escolhida com um dono, porque o próximo operador encontrará a regra e não o raciocínio por trás dela. Aplique a permissão através da firewall existente e do dono da rede em vez de limpar regras ou acrescentar um segundo gestor de políticas para um único host. Cubra as famílias de endereços e os pontos de serviço que a fonte real usa, e reveja a lista quando o repositório se mudar.
Verifique sem enfraquecer a confiança
O sucesso do transporte não é permissão para relaxar a verificação: a autenticação do arquivo e a identidade do servidor TLS são duas verificações distintas, e desativar qualquer uma delas faz desaparecer um erro ao mesmo tempo que muda o que o host aceitará. Um proxy que interceta é uma decisão de confiança do dono da rede e não um motivo para desligar a verificação localmente, e as credenciais do repositório não pertencem a diagnósticos partilhados, porque um registo detalhado é o local mais fácil para as divulgar.
Aceite a alteração com uma obtenção controlada de metadados seguida de uma transação de pacotes aprovada, e depois teste o que acontece quando o túnel cai. Um caminho de manutenção que se alarga silenciosamente durante uma interrupção é pior do que um que falha fechado, e o resultado deve ser um caminho de atualização com um dono nomeado e um âmbito delimitado.