Los sitios web cargan con la VPN, pero apt no llega al repositorio

La VPN se conecta, la wiki interna carga en el navegador y apt update sigue colgado en un espejo al que no puede llegar. Nada del túnel está roto en esa imagen. El navegador y el gestor de paquetes tomaron dos decisiones de proxy separadas, y solo una de ellas estaba configurada.

Cuál de las dos decisiones falló es lo único que merece establecerse primero.

Lea el error antes de tocar un ajuste

Cada etapa deja un mensaje distinto. Un nombre que nunca se resuelve es DNS, una conexión que nunca se completa es enrutamiento o un cortafuegos, un 407 inmediato es autenticación del proxy, una queja sobre el certificado es verificación TLS y un aviso de firma son los metadatos del repositorio. Esos cinco fallos necesitan cinco arreglos distintos, y una línea de proxy pegada encima de un problema de DNS solo traslada el cuelgue.

Copie la línea exacta y el repositorio que nombra antes de cambiar nada. Un recuerdo vago de «se agotó el tiempo» es lo que convierte un diagnóstico de diez minutos en una tarde entera.

APT guarda sus propios ajustes de proxy

APT lee /etc/apt/apt.conf.d/, el apt.conf principal y cualquier archivo nombrado por APT_CONFIG. No lee un perfil de proxy del escritorio, un ajuste de red de GNOME ni una extensión del navegador. El transporte sí respeta las variables de entorno de proxy, y por eso un export https_proxy=... que funciona en su shell no demuestra nada sobre un temporizador que se ejecuta en otro entorno.

Vuelque lo que el proceso que falla ve realmente: apt-config dump | grep -i proxy.

Ejecute eso como el usuario con el que corre la operación que falla. Si root lee un conjunto de archivos distinto, o un temporizador de systemd arranca con otro entorno, el volcado será diferente, y esa diferencia es su respuesta. Dos valores de proxy que no coinciden son peores que un valor ausente, porque el transporte sigue la coincidencia más específica que encuentra.

Defina el proxy donde el dueño de la configuración lo espera

Para un proxy explícito aprobado por el administrador, basta un fragmento pequeño en un archivo nuevo:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

La tercera línea es la parte que más ejemplos omiten. Una clave por host anula el valor genérico, así que un espejo interno accesible por el túnel puede saltarse el proxy mientras todo lo demás sigue pasando por él. DIRECT es el valor documentado para eso, no una cadena vacía.

Añada el fragmento como un archivo nuevo numerado, por ejemplo /etc/apt/apt.conf.d/95proxy. Sobrescribir un archivo de la distribución significa que la siguiente actualización de paquetes revierte su cambio en silencio.

Las credenciales quedan fuera del URI

La referencia del transporte de APT apunta a apt_auth.conf para la autenticación, y ahí es donde van el usuario y la contraseña. Incrustarlos en el URI del proxy los pone en los listados de procesos, en el historial del shell y en cada volcado de configuración que se pega en un ticket. El archivo de autenticación necesita permisos restrictivos, porque es un almacén de credenciales.

Compruebe también el esquema. Un repositorio HTTPS puede seguir alcanzándose a través de un proxy HTTP; el transporte es una elección distinta de la del esquema del URI del espejo.

Un centro de software gráfico es una interfaz aparte. Si usa PackageKit o un backend snap, el fragmento de APT no cambia nada para él, así que confirme qué proceso hizo la petición fallida.

Confirme la ruta, no solo el código de salida

Con el fragmento instalado, observe la petición en lugar de fiarse de un resultado en verde. apt-get -o Debug::Acquire::http=true update imprime el intento de conexión, el proxy que eligió y el código de respuesta, lo que separa un proxy equivocado de un proxy que le rechazó.

A continuación, pruebe el caso que no debería funcionar. Desconecte la VPN y confirme que el espejo interno deja de responder; si sigue descargando, algo está enrutando por fuera del túnel o una caché obsoleta le está sirviendo. Confirme que la ruta permitida sigue verificando TLS y sigue comprobando las firmas del repositorio, porque un proxy que inspecciona el tráfico no es motivo para desactivar ninguna de las dos cosas. Confirme también que un cliente sin autenticar recibe una denegación clara en lugar de un tiempo de espera silencioso.

Guarde juntos el fragmento que funciona y la salida que falla en el registro de cambios. La próxima persona que choque con el mismo cuelgue reconocerá la diferencia de dos líneas más rápido que con cualquier explicación.