Su puerta de enlace VPN sigue necesitando una forma de instalar actualizaciones

El túnel funciona para todos los que están detrás, la puerta de enlace reenvía su tráfico y, sin embargo, la máquina en sí no puede instalar una actualización de seguridad. Esta es la forma habitual del problema: se concedió permiso de reenvío a los clientes y las conexiones salientes propias de la puerta de enlace nunca se incluyeron en el plan. El gestor de paquetes abre sus propios sockets, desde la puerta de enlace, hacia un repositorio que probablemente no ha nombrado en ninguna parte de la política del cortafuegos.

Bloquear una puerta de enlace es correcto. Bloquearla de forma tan completa que deje de recibir parches es una decisión distinta, y normalmente accidental.

La salida local no es el reenvío de clientes

Las reglas de reenvío rigen los paquetes que llegan de otro lugar y salen por la puerta de enlace. El tráfico de actualización de la propia puerta de enlace nunca coincide con ellas; se genera localmente y recorre la ruta de salida. Esa distinción explica un fallo que parece imposible mientras el acceso de los clientes funciona perfectamente.

También explica una laguna de política que sobrevive a las pruebas, porque una comprobación rápida desde un portátil detrás del túnel demuestra que la cadena de reenvío funciona y no dice nada sobre las conexiones propias del host. Trate la puerta de enlace como dos sujetos: un enrutador con una cadena de reenvío y un host con una cadena de salida. Ambos necesitan una opinión, y solo uno de ellos suele quedar escrito.

Nombrar la etapa que falló

Los errores de actualización nombran límites distintos, y recurrir a una regla de puerto antes de leer cuál falló desperdicia una tarde. Un nombre de repositorio que no se resuelve es una cuestión de resolución de nombres, no una 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 tiempo de espera agotado tras una resolución correcta desplaza la pregunta al transporte: qué dirección, qué puerto y qué proxy configurado intentó realmente el gestor de paquetes. Un fallo de verificación TLS es algo completamente distinto, y significa que la conexión funcionó lo bastante bien como para negociar. Una queja de autenticación del archivo es la cuarta etapa, y se refiere a metadatos firmados y no a la accesibilidad. Cuatro etapas, cuatro reparaciones distintas, y un ping solo describe un protocolo que ningún gestor de paquetes utiliza.

Lea la lista de fuentes antes de añadir una regla

Enumere los URI reales de las fuentes y la configuración de proxy efectiva en lugar de los que recuerda. Una regla escrita para HTTP simple es inútil cuando la fuente es HTTPS, y un proxy que el shell conoce puede ser invisible para un servicio iniciado al arranque con otro entorno.

La documentación del transporte HTTP de APT cubre los ajustes de proxy del entorno y específicos de APT, incluidas las elecciones por host, y su transporte HTTPS tiene ajustes de verificación propios. El camino que toma un navegador y el que toma el gestor de paquetes son caminos separados, incluso en la misma máquina.

Anote a qué familias resuelven las fuentes. Una regla que solo permite IPv4 seguirá fallando en un host cuyas fuentes prefieren un registro AAAA, y el error parece intermitente porque depende de qué respuesta llegue primero.

Elija una ruta de mantenimiento y manténgala

Existen tres opciones defendibles: el tráfico de mantenimiento por el túnel, por un proxy de actualización gestionado o por una excepción directa estrecha. Elija una a propósito y haga que el resolutor esté de acuerdo con ella, porque una división en la que los nombres se resuelven de una manera y las conexiones van de otra produce fallos que nadie puede explicar.

Elija lo que elija, no debe convertirse en un recurso de reserva sin restricciones. Si el tráfico saliente directo está prohibido cuando el túnel está caído, una excepción de mantenimiento que en silencio lo permite todo es un cambio de política disfrazado de arreglo. Mantenga el propio punto de conexión del túnel y sus necesidades de arranque en una categoría separada del acceso a los repositorios, porque apuntan a destinos distintos y fallan de formas distintas, de modo que una exención no puede cubrir la otra.

Verificar sin debilitar las comprobaciones

Aplique el alcance a través del cortafuegos que ya posee la política, en lugar de añadir un segundo gestor porque una guía lo usó. Después ejecute una actualización de metadatos y una transacción real de paquetes bajo la política mantenida, y lea la salida en lugar del código de salida solamente.

Que el transporte funcione no es permiso para relajar la verificación. La autenticación de archivos y la identidad del servidor TLS son garantías separadas, y desactivar cualquiera de ellas para silenciar un error cambia lo que usted confía, no lo que puede alcanzar.

Termine probando deliberadamente el caso del túnel caído. Saber cómo se comporta la puerta de enlace sin su túnel forma parte del diseño, y descubrirlo durante una interrupción no. Baje el túnel, ejecute la actualización de metadatos y confirme que el host falla de la manera prevista en lugar de recurrir en silencio a una ruta abierta. Mantenga las credenciales de repositorios y proxy fuera de los diagnósticos compartidos, y deje una nota que indique quién es responsable de la ruta de actualización.