Votre passerelle VPN a toujours besoin d’un moyen d’installer les mises à jour

Le tunnel fonctionne pour tout ce qui se trouve derrière, la passerelle achemine leur trafic, et pourtant la machine elle-même ne parvient pas à installer une mise à jour de sécurité. C’est la forme habituelle du problème : l’autorisation de transfert a été accordée aux clients, et les connexions sortantes de la passerelle n’ont jamais été intégrées au plan. Le gestionnaire de paquets ouvre ses propres sockets, depuis la passerelle, vers un dépôt que vous n’avez probablement nommé nulle part dans la politique du pare-feu.

Verrouiller une passerelle est correct. La verrouiller si étroitement qu’elle cesse de recevoir des correctifs est une autre décision, et généralement une décision accidentelle.

La sortie locale n’est pas le transfert des clients

Les règles de transfert régissent les paquets qui arrivent d’ailleurs et repartent par la passerelle. Le trafic de mise à jour de la passerelle elle-même ne les rencontre jamais ; il est généré localement et emprunte le chemin de sortie. Cette distinction explique une panne qui semble impossible alors que l’accès des clients fonctionne parfaitement.

Elle explique aussi une lacune de politique qui survit aux tests, car une vérification rapide depuis un ordinateur portable derrière le tunnel prouve que la chaîne de transfert fonctionne et ne dit rien des connexions propres de l’hôte. Considérez la passerelle comme deux sujets : un routeur avec une chaîne de transfert et un hôte avec une chaîne de sortie. Les deux ont besoin d’un avis, et un seul d’entre eux est généralement consigné.

Nommer l’étape qui a échoué

Les erreurs de mise à jour désignent des frontières différentes, et se précipiter sur une règle de port avant d’avoir lu laquelle a échoué coûte un après-midi. Un nom de dépôt qui ne se résout pas est une question de résolveur, pas une question de transport.

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 délai d’attente après une résolution réussie déplace la question vers le transport : quelle adresse, quel port et quel proxy configuré le gestionnaire de paquets a réellement essayés. Un échec de vérification TLS est une troisième chose tout à fait différente, et il signifie que la connexion a fonctionné suffisamment pour négocier. Une plainte d’authentification d’archive est la quatrième étape, et elle concerne des métadonnées signées plutôt que la joignabilité. Quatre étapes, quatre réparations différentes, et un ping ne décrit jamais qu’un protocole qu’aucun gestionnaire de paquets n’utilise.

Lire la liste des sources avant d’ajouter une règle

Énumérez les URI réelles des sources et la configuration proxy effective, pas celles dont vous vous souvenez. Une règle écrite pour du HTTP simple est inutile quand la source est en HTTPS, et un proxy que le shell connaît peut être invisible pour un service démarré au démarrage avec un autre environnement.

La documentation du transport HTTP d’APT couvre les réglages de proxy liés à l’environnement et propres à APT, y compris les choix par hôte, et son transport HTTPS possède ses propres réglages de vérification. Le chemin qu’emprunte un navigateur et celui qu’emprunte le gestionnaire de paquets sont des chemins distincts, même sur la même machine.

Notez les familles vers lesquelles les sources se résolvent. Une règle qui n’autorise qu’IPv4 continuera d’échouer sur un hôte dont les sources préfèrent un enregistrement AAAA, et l’erreur semble intermittente parce qu’elle dépend de la réponse qui arrive en premier.

Choisir un chemin de maintenance et s’y tenir

Trois options défendables existent : le trafic de maintenance par le tunnel, par un proxy de mise à jour géré, ou par une exception directe étroite. Choisissez-en une délibérément et faites en sorte que le résolveur soit d’accord, car une séparation où les noms se résolvent d’une manière et les connexions vont d’une autre produit des pannes que personne ne peut expliquer.

Quel que soit votre choix, il ne doit pas devenir une solution de repli sans restriction. Si le trafic sortant direct est interdit lorsque le tunnel est coupé, une exception de maintenance qui autorise discrètement tout est un changement de politique déguisé en correctif. Gardez le point de terminaison propre du tunnel et ses besoins d’amorçage dans une catégorie distincte de l’accès aux dépôts, car ils pointent vers des destinations différentes et échouent de manières différentes, si bien qu’une exemption ne peut pas couvrir l’autre.

Vérifier sans affaiblir les contrôles

Appliquez la portée via le pare-feu qui détient déjà la politique, plutôt que d’ajouter un second gestionnaire parce qu’un guide l’a utilisé. Exécutez ensuite une actualisation des métadonnées et une véritable transaction de paquets sous la politique maintenue, et lisez la sortie plutôt que le seul code de retour.

Un transport réussi n’est pas une autorisation d’assouplir la vérification. L’authentification des archives et l’identité du serveur TLS sont des garanties distinctes, et désactiver l’une ou l’autre pour faire taire une erreur change ce que vous faites confiance, pas ce que vous pouvez atteindre.

Terminez en testant délibérément le cas du tunnel coupé. Savoir comment la passerelle se comporte sans son tunnel fait partie de la conception ; le découvrir pendant une panne, non. Coupez le tunnel, lancez l’actualisation des métadonnées et confirmez que l’hôte échoue de la manière prévue plutôt que de retomber silencieusement sur un chemin ouvert. Gardez les identifiants des dépôts et du proxy hors des diagnostics partagés, et laissez une note indiquant à qui appartient le chemin de mise à jour.