A vosa pasarela VPN aínda necesita unha maneira de instalar actualizacións

O túnel funciona para todos os que están detrás, a pasarela reenvía o seu tráfico e, aínda así, a propia máquina non pode instalar unha actualización de seguridade. Esta é a forma habitual do problema: o permiso de reenvío concedéuselles aos clientes, e as conexións saíntes propias da pasarela nunca se incluíron no plan. O xestor de paquetes abre os seus propios sockets, desde a pasarela, cara a un repositorio que probablemente non nomeou en ningún sitio na política da devasa.

Bloquear unha pasarela é correcto. Bloqueala tan a fondo que deixe de recibir parches é outra decisión, e normalmente accidental.

A saída local non é o reenvío de clientes

As regras de reenvío rexen os paquetes que chegan doutro lugar e saen pola pasarela. O tráfico de actualización propio da pasarela nunca coincide con elas; xérase localmente e percorre o camiño de saída. Esta distinción explica unha falla que parece imposible mentres o acceso dos clientes funciona perfectamente.

Tamén explica unha lagoa de política que sobrevive ás probas, porque unha comprobación rápida desde un portátil detrás do túnel demostra que a cadea de reenvío funciona e non di nada sobre as conexións propias do host. Tratade a pasarela como dous suxeitos: un encamiñador cunha cadea de reenvío e un host cunha cadea de saída. Ambos necesitan unha opinión, e normalmente só se escribe unha.

Nomeade a etapa que fallou

Os erros de actualización nomean límites diferentes, e recorrer a unha regra de porto antes de ler cal fallou custa unha tarde. Un nome de repositorio que non se resolve é unha cuestión de resolutor, non unha cuestión 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

Un tempo de espera após unha resolución correcta despraza a pregunta cara ao transporte: que enderezo, que porto e que proxy configurado probou realmente o xestor de paquetes. Unha falla de verificación TLS é unha terceira cousa, completamente diferente, e significa que a conexión funcionou abondo ben para negociar. Unha queixa de autenticación do arquivo é a cuarta etapa, e refírese a metadatos asinados e non á accesibilidade. Catro etapas, catro reparacións diferentes, e un ping sempre describe só un protocolo que ningún xestor de paquetes usa.

Lede a lista de fontes antes de engadir unha regra

Enumerade os URI reais das fontes e a configuración efectiva de proxy, non os que recordades. Unha regra escrita para HTTP simple é inútil cando a fonte é HTTPS, e un proxy que a shell coñece pode ser invisible para un servizo iniciado no arranque con outro contorno.

A documentación do transporte HTTP de APT abrangue os axustes de proxy da contorna e os específicos de APT, incluíndo as escollas por host, e o seu transporte HTTPS ten axustes de verificación propios. O camiño que toma un navegador e o que toma o xestor de paquetes son camiños separados, mesmo na mesma máquina.

Fixádevos en que familias resolven as fontes. Unha regra que só permite IPv4 continuará fallando nun host cuxas fontes prefiren un rexistro AAAA, e o erro parece intermitente porque depende de que resposta chegue primeiro.

Escollede un camiño de mantemento e mantédeo

Existen tres opcións defendibles: tráfico de mantemento polo túnel, por un proxy de actualizacións xestionado ou por unha excepción directa estreita. Escollede unha deliberadamente e facede que o resolutor estea de acordo, porque unha división na que os nomes se resolven dunha maneira e as conexións van doutra produce fallas que ninguén pode explicar.

Escollades o que escollades, non debe converterse nun recurso de reserva sen restricións. Se o tráfico saínte directo está prohibido cando o túnel está caído, unha excepción de mantemento que permite en silencio todo é un cambio de política disfrazado de corrección. Mantede o punto final propio do túnel e as necesidades de arranque nunha categoría separada do acceso aos repositorios, porque apuntan a destinos distintos e fallan de maneiras distintas, de xeito que unha exención non pode cubrir a outra.

Verificade sen debilitar as comprobacións

Aplicade o alcance a través da devasa que xa posúe a política, en lugar de engadir un segundo xestor porque unha guía o usou. Despois executade unha actualización de metadatos e unha transacción real de paquetes baixo a política mantida, e lede a saída en lugar do código de saída só.

Un transporte correcto non é permiso para relaxar a verificación. A autenticación do arquivo e a identidade do servidor TLS son garantías separadas, e desactivar calquera delas para silenciar un erro cambia aquilo en que confiades, non aquilo que podedes acadar.

Rematade probando deliberadamente o caso sen túnel. Saber como se comporta a pasarela sen o seu túnel forma parte do deseño, descubrilo durante unha interrupción non. Baixade o túnel, executade a actualización de metadatos e confirmade que o host falla da maneira prevista en lugar de recuar en silencio cara a un camiño aberto. Mantede as credenciais dos repositorios e do proxy fóra dos diagnósticos compartidos e deixade unha nota que indique quen é responsable do camiño de actualización.