Les sites se chargent avec le VPN, mais apt n’atteint pas le dépôt

Le VPN se connecte, le wiki interne s’affiche dans le navigateur, et apt update reste bloqué sur un miroir qu’il ne peut pas joindre. Rien n’est cassé dans le tunnel sur cette image. Le navigateur et le gestionnaire de paquets ont pris deux décisions de proxy distinctes, et une seule d’entre elles avait été configurée.

Laquelle a échoué est la seule chose qu’il vaut la peine d’établir d’abord.

Lisez l’erreur avant de toucher à un réglage

Chaque étape laisse un message différent. Un nom qui ne se résout jamais, c’est du DNS ; une connexion qui ne s’achève jamais, c’est du routage ou un pare-feu ; un 407 immédiat, c’est l’authentification du proxy ; une plainte sur le certificat, c’est la vérification TLS ; et un avertissement de signature, ce sont les métadonnées du dépôt. Ces cinq défaillances demandent cinq correctifs différents, et une ligne de proxy collée par-dessus un problème DNS ne fait que déplacer le blocage.

Copiez la ligne exacte et le dépôt qu’elle nomme avant de changer quoi que ce soit. Un souvenir vague de « ça a expiré » est ce qui transforme un diagnostic de dix minutes en un après-midi entier.

APT garde ses propres réglages de proxy

APT lit /etc/apt/apt.conf.d/, le apt.conf principal et tout fichier désigné par APT_CONFIG. Il ne lit pas un profil de proxy du bureau, un réglage réseau de GNOME ni une extension de navigateur. Le transport, lui, respecte les variables d’environnement de proxy, ce qui explique qu’un export https_proxy=... qui fonctionne dans votre shell ne prouve rien pour un minuteur qui s’exécute dans un autre environnement.

Videz ce que le processus en échec voit réellement : apt-config dump | grep -i proxy.

Lancez cela en tant qu’utilisateur sous lequel tourne l’opération en échec. Si root lit un autre ensemble de fichiers, ou si un minuteur systemd démarre avec un autre environnement, le vidage différera, et cette différence est votre réponse. Deux valeurs de proxy qui se contredisent sont pires qu’une valeur manquante, parce que le transport suit la correspondance la plus spécifique qu’il trouve.

Définissez le proxy là où le propriétaire de la configuration l’attend

Pour un proxy explicite approuvé par l’administrateur, un petit fragment dans un nouveau fichier suffit :

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

La troisième ligne est la partie que la plupart des exemples omettent. Une clé par hôte prime sur la valeur générique, si bien qu’un miroir interne joignable par le tunnel peut contourner le proxy pendant que tout le reste y passe encore. DIRECT est la valeur documentée pour cela, pas une chaîne vide.

Ajoutez le fragment sous forme de nouveau fichier numéroté, par exemple /etc/apt/apt.conf.d/95proxy. Écraser un fichier de la distribution signifie que la prochaine mise à jour de paquets annulera votre changement sans rien dire.

Les identifiants restent hors de l’URI

La référence du transport APT renvoie à apt_auth.conf pour l’authentification, et c’est là que doivent aller le nom d’utilisateur et le mot de passe. Les intégrer dans l’URI du proxy les place dans les listes de processus, l’historique du shell et chaque vidage de configuration collé dans un ticket. Le fichier d’authentification a besoin de permissions restrictives, car c’est un magasin d’identifiants.

Vérifiez aussi le schéma. Un dépôt HTTPS peut toujours être joint via un proxy HTTP ; le transport est un choix distinct de celui du schéma d’URI du miroir.

Un centre de logiciels graphique est une interface distincte. S’il utilise PackageKit ou un backend snap, le fragment APT ne change rien pour lui, alors vérifiez quel processus a fait la requête en échec.

Vérifiez le chemin, pas seulement le code de sortie

Une fois le fragment en place, observez la requête au lieu de vous fier à un résultat vert. apt-get -o Debug::Acquire::http=true update affiche la tentative de connexion, le proxy choisi et le code de réponse, ce qui distingue un mauvais proxy d’un proxy qui vous a refusé.

Testez ensuite le cas qui ne devrait pas fonctionner. Déconnectez le VPN et vérifiez que le miroir interne cesse de répondre ; s’il télécharge encore, quelque chose contourne le tunnel ou un cache périmé vous sert. Vérifiez que le chemin autorisé valide toujours TLS et contrôle toujours les signatures du dépôt, car un proxy qui inspecte le trafic n’est pas une raison de désactiver l’un ou l’autre. Vérifiez aussi qu’un client non authentifié reçoit un refus clair plutôt qu’un délai silencieux.

Conservez ensemble le fragment qui fonctionne et la sortie qui échoue dans le journal des changements. La prochaine personne confrontée au même blocage reconnaîtra plus vite la différence de deux lignes que n’importe quelle explication.