O seu gateway VPN continua a precisar de uma forma de instalar atualizações

O túnel funciona para todos os que estão atrás dele, o gateway encaminha o respetivo tráfego e, ainda assim, a própria máquina não consegue instalar uma atualização de segurança. Esta é a forma habitual do problema: a permissão de encaminhamento foi concedida aos clientes e as ligações de saída do próprio gateway nunca foram incluídas no plano. O gestor de pacotes abre os seus próprios sockets, a partir do gateway, para um repositório que provavelmente nunca nomeou em lado nenhum na política da firewall.

Bloquear um gateway é correto. Bloqueá-lo de forma tão completa que deixe de receber patches é uma decisão diferente, e normalmente acidental.

A saída local não é o encaminhamento de clientes

As regras de encaminhamento regem os pacotes que chegam de outro lugar e saem pelo gateway. O tráfego de atualização do próprio gateway nunca as corresponde; é gerado localmente e percorre o caminho de saída. Esta distinção explica uma falha que parece impossível enquanto o acesso dos clientes funciona na perfeição.

Explica também uma lacuna de política que sobrevive aos testes, porque uma verificação rápida a partir de um portátil atrás do túnel prova que a cadeia de encaminhamento funciona e não diz nada sobre as ligações do próprio host. Trate o gateway como dois sujeitos: um router com uma cadeia de encaminhamento e um host com uma cadeia de saída. Ambos precisam de uma opinião, e normalmente só um deles fica registado.

Nomear a etapa que falhou

Os erros de atualização nomeiam fronteiras diferentes, e recorrer a uma regra de porta antes de ler qual delas falhou desperdiça uma tarde. Um nome de repositório que não resolve é uma questão de resolução de nomes, não uma questão de transporte.

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

Um tempo limite após uma resolução bem-sucedida desloca a questão para o transporte: que endereço, que porta e que proxy configurado o gestor de pacotes realmente tentou. Uma falha de verificação TLS é uma terceira coisa completamente diferente, e significa que a ligação funcionou suficientemente bem para negociar. Uma queixa de autenticação do arquivo é a quarta etapa, e diz respeito a metadados assinados e não à acessibilidade. Quatro etapas, quatro reparações diferentes, e um ping descreve apenas um protocolo que nenhum gestor de pacotes utiliza.

Ler a lista de fontes antes de acrescentar uma regra

Enumere os URI reais das fontes e a configuração de proxy efetiva, em vez dos que recorda. Uma regra escrita para HTTP simples é inútil quando a fonte é HTTPS, e um proxy que a shell conhece pode ser invisível para um serviço iniciado no arranque com um ambiente diferente.

A documentação do transporte HTTP do APT cobre as definições de proxy do ambiente e específicas do APT, incluindo escolhas por host, e o seu transporte HTTPS tem definições de verificação próprias. O caminho de um navegador e o caminho do gestor de pacotes são caminhos separados, mesmo na mesma máquina.

Anote para que famílias as fontes resolvem. Uma regra que só permite IPv4 continuará a falhar num host cujas fontes preferem um registo AAAA, e o erro parece intermitente porque depende de qual resposta chega primeiro.

Escolher um caminho de manutenção e mantê-lo

Existem três opções defensáveis: tráfego de manutenção através do túnel, através de um proxy de atualização gerido ou através de uma exceção direta estreita. Escolha uma deliberadamente e faça com que o resolvedor concorde com ela, porque uma divisão em que os nomes resolvem de uma forma e as ligações vão de outra produz falhas que ninguém consegue explicar.

Independentemente da sua escolha, esta não deve tornar-se uma alternativa irrestrita. Se o tráfego de saída direto é proibido quando o túnel está em baixo, uma exceção de manutenção que permite tudo silenciosamente é uma alteração de política disfarçada de correção. Mantenha o próprio endpoint do túnel e as suas necessidades de arranque numa categoria separada do acesso aos repositórios, porque apontam para destinos diferentes e falham de formas diferentes, pelo que uma isenção não pode cobrir a outra.

Verificar sem enfraquecer as verificações

Aplique o âmbito através da firewall que já detém a política, em vez de acrescentar um segundo gestor porque um guia o usou. Depois execute uma atualização de metadados e uma transação real de pacotes sob a política mantida, e leia a saída em vez do estado de saída apenas.

O sucesso do transporte não é permissão para relaxar a verificação. A autenticação dos arquivos e a identidade do servidor TLS são garantias separadas, e desativar qualquer uma delas para silenciar um erro altera aquilo em que confia, não aquilo que consegue alcançar.

Termine testando deliberadamente o caso de túnel em baixo. Saber como o gateway se comporta sem o seu túnel faz parte do projeto; descobri-lo durante uma interrupção não. Desligue o túnel, execute a atualização de metadados e confirme que o host falha da forma pretendida em vez de recuar silenciosamente para um caminho aberto. Mantenha as credenciais dos repositórios e do proxy fora dos diagnósticos partilhados e deixe uma nota que indique quem é responsável pelo caminho de atualização.