La mise à jour de la passerelle VPN échoue : lisez l’étape avant d’ouvrir la sortie
Une mise à jour en échec nomme une étape, pas un port manquant. Rattachez le message à son propriétaire, lisez le chemin du proxy, puis décidez la politique de maintenance en connaissance de cause.
Refuser d’installer les mises à jour de sécurité, c’est à une mauvaise semaine de devenir le problème de quelqu’un d’autre, et une passerelle qui admet des clients est l’endroit le plus facile pour prendre cette habitude. La cause habituelle n’est pas une route manquante mais une décision manquante : personne n’a dit comment l’hôte lui-même doit joindre un dépôt lorsque le transfert des clients est délibérément étroit. Cette décision doit être prise explicitement, et elle doit être plus étroite que couper la politique de sortie pendant un après-midi.
Quatre étapes, quatre propriétaires différents
Un échec de mise à jour est une étape nommée, que le message le dise ou non, et chaque étape appartient à un propriétaire différent. Un nom qui ne se résout pas est une question de résolveur. Une connexion qui expire est une question de transport, de proxy ou d’extrémité distante. Une erreur d’identité TLS est une question de confiance, et des métadonnées de dépôt rejetées sont une question de signature. Quatre étapes, quatre propriétaires, et une règle de port ne répond jamais qu’à l’une d’elles.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
Le ping et la résolution de noms sont les deux tests vers lesquels on se tourne d’abord, et tous deux répondent à des questions que personne n’a posées. Une réponse d’écho exerce un protocole différent de la connexion au dépôt, et une résolution réussie s’arrête à la résolution de noms sans tester la récupération. L’un comme l’autre peut réussir alors que la transaction réelle échoue, et l’un comme l’autre peut échouer pour des raisons sans rapport avec le chemin.
Lisez le chemin que le gestionnaire emprunte réellement
Inspectez les URI de source configurés et la disposition effective du proxy au lieu de supposer l’un ou l’autre. Une règle écrite pour du HTTP simple n’est pas une réparation lorsque le dépôt parle HTTPS, et une organisation qui impose un proxy a déjà choisi le chemin. Les gestionnaires de paquets respectent les variables d’environnement et leur propre configuration, et des réglages propres à l’hôte peuvent remplacer un réglage global. Ce que fait un navigateur interactif n’est pas forcément ce que fait le gestionnaire.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyLa documentation du transport APT décrit quels réglages s’appliquent à quel schéma d’URI et comment s’écrivent les choix propres à l’hôte. Conservez la sortie des commandes avec le ticket, car elle sépare un problème de proxy d’une route manquante plus vite que n’importe quel nombre de résultats de ping. Notez la destination, le port et le protocole exacts que le gestionnaire tente, et faites reposer la modification du pare-feu sur cette trace plutôt que sur une adresse de miroir devinée qui devient obsolète en quelques mois.
Choisissez une politique de maintenance, pas une exception
Trois politiques sont défendables : maintenir via le tunnel, maintenir via un proxy de mise à jour géré, ou maintenir via une route directe étroitement autorisée. Chacune implique une disposition de résolution qui lui corresponde. Ce qui n’est pas défendable, c’est une exception qui devient discrètement un repli sans restriction dès que le tunnel tombe.
Écrivez la politique retenue avec un propriétaire, car le prochain opérateur trouvera la règle et non le raisonnement qui la sous-tend. Appliquez l’autorisation via le pare-feu existant et le propriétaire du réseau au lieu de vider des règles ou d’ajouter un second gestionnaire de politiques pour un seul hôte. Couvrez les familles d’adresses et les points de service qu’utilise la vraie source, et révisez la liste lorsque le dépôt déménage.
Vérifiez sans affaiblir la confiance
Un transport réussi n’est pas la permission de relâcher la vérification : l’authentification des archives et l’identité du serveur TLS sont deux contrôles distincts, et désactiver l’un ou l’autre fait disparaître une erreur tout en changeant ce que l’hôte acceptera. Un proxy d’interception est une décision de confiance du propriétaire du réseau, non une raison de désactiver le contrôle localement, et les identifiants du dépôt n’ont pas leur place dans un diagnostic partagé, car un journal détaillé est l’endroit le plus facile pour les divulguer.
Acceptez le changement sur une récupération de métadonnées contrôlée suivie d’une transaction de paquets approuvée, puis testez ce qui se passe lorsque le tunnel tombe. Un chemin de maintenance qui s’élargit silencieusement pendant une panne est pire qu’un chemin qui échoue en se fermant, et le résultat devrait être un chemin de mise à jour avec un propriétaire nommé et une portée délimitée.