⚠️ Disclaimer
La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.
Le problème : des erreurs 503 mystérieuses
Lorsque j’ai commencé à déployer des machines virtuelles dans le cadre de ma formation, j’ai rencontré un problème récurrent que je n’avais jamais eu auparavant, à l’époque où je n’utilisais ni pfSense ni le proxy associé.
En effet, lors de l’installation, le système propose normalement une mise à jour automatique des paquets. Or, à chaque tentative, cette étape échouait systématiquement avec des erreurs 503, rendant impossible l’installation de certains paquets essentiels, notamment OpenSSH.
J’ai passé une journée complète à chercher la cause avant de finalement comprendre d’où venait le problème.
⸻
⸻
Comprendre d’où vient le blocage
Après investigation, le coupable était clair : SquidGuard. Plus précisément, sa configuration par défaut ultra-restrictive qui bloquait tout avec une simple directive pass none dans l’ACL.
Mais pourquoi Ubuntu et Debian en particulier ? Parce que leurs systèmes de dépôts sont plus complexes qu’il n’y paraît. Quand APT contacte archive.ubuntu.com, il peut être redirigé vers des miroirs géographiques comme :
fr.archive.ubuntu.com(miroir français)us.archive.ubuntu.com(miroir américain)azure.archive.ubuntu.com(CDN Azure)
Cette architecture distribuée est excellente pour les performances, mais cauchemardesque pour une whitelist de proxy qui ne gère que le domaine principal.
La fausse bonne idée : ajouter les domaines dans l’interface Web
Première tentative logique : créer une catégorie “System_Updates” dans l’interface PFSense et y ajouter tous les domaines Ubuntu/Debian. Simple, non ?
Sauf que… SquidGuard utilise une syntaxe spéciale pour les wildcards : un point devant le domaine. .archive.ubuntu.com signifie “ce domaine ET tous ses sous-domaines”. Sans le point, seul le domaine exact est autorisé.
Le problème ? L’interface Web PFSense refuse cette syntaxe avec un message d’erreur du genre “Item ‘.archive.ubuntu.com’ is not a domain”. C’est une limitation de la validation du formulaire, pas une erreur de syntaxe SquidGuard.
Frustrant.
La solution hybride qui fonctionne
Après avoir lu la documentation officielle de Squid, j’ai compris qu’il fallait contourner l’interface Web. Voici la solution en deux étapes :
Étape 1 : Créer le fichier de domaines en SSH
Connexion SSH à PFSense et création manuelle du fichier avec la bonne syntaxe :
| |
Notez que chaque domaine apparaît deux fois : avec et sans le point. C’est pour assurer une compatibilité maximale entre les différentes versions de SquidGuard.
Étape 2 : Activer la catégorie via l’interface Web
Maintenant que le fichier existe, il faut dire à SquidGuard de l’utiliser. Dans l’interface PFSense :
Services > SquidGuard Proxy Filter > Target Categories
→ Créer une catégorie System_Updates
→ Dans “Domain List”, mettre un seul domaine simple accepté par la validation (par exemple ubuntu.com)
→ Save
Services > SquidGuard Proxy Filter > Common ACL
→ Cocher System_Updates et sélectionner “allow”
→ Save puis Apply Changes
Pourquoi cette solution fonctionne
C’est l’astuce clé : même si l’interface Web n’affiche qu’un domaine simple, PFSense génère une configuration qui pointe vers le fichier /var/db/squidGuard/System_Updates/domains que nous avons créé en SSH.
Dans /usr/local/etc/squidGuard/squidGuard.conf, on trouve maintenant :
dest System_Updates {
domainlist System_Updates/domains
}
acl {
default {
pass System_Updates all
}
}
SquidGuard lit le fichier domains créé en SSH (qui contient les wildcards corrects), pas la liste affichée dans l’interface Web. C’est pourquoi tous les sous-domaines fonctionnent magiquement.
Vérification et debugging
Pour confirmer que tout fonctionne, j’utilise ces commandes :
Vérifier le fichier de domaines :
| |
Vérifier que la catégorie est bien activée :
| |
Surveiller les blocages en temps réel :
| |
Pendant que vous lancez apt-get update, vous devriez voir “PASS” dans les logs au lieu de “REDIRECT”.
Les pièges à éviter
Quelques erreurs classiques que j’ai rencontrées :
❌ Oublier le point devant les domaines → Les sous-domaines ne matcheront pas
❌ Ne pas définir la catégorie dans l’interface Web → Le fichier SSH sera ignoré
❌ Ordre des ACL incorrect → Si une règle de blocage est évaluée avant l’autorisation, ça ne passera jamais
❌ Ne pas redémarrer Squid → Les changements ne seront pas appliqués
Implications et maintenance
Cette solution fonctionne parfaitement, mais elle a quelques implications :
Maintenance manuelle : si vous reconfigurez SquidGuard entièrement via l’interface, vos modifications SSH seront écrasées. Gardez une sauvegarde du fichier domains.
Extension progressive : à chaque nouvel outil (Docker, Kubernetes, PyPI, NPM…), vous devrez ajouter les domaines correspondants. Le fichier peut vite grossir.
Surface d’attaque : en autorisant de nombreux domaines avec wildcards, vous élargissez la surface d’attaque potentielle. C’est un compromis entre fonctionnalité et sécurité stricte.
Conclusion
Ce qui devait être une simple whitelist s’est transformé en une petite odyssée technique, mais j’en sors avec plusieurs leçons :
- Les interfaces Web ont leurs limites : parfois, il faut mettre les mains dans les fichiers de config
- La documentation officielle est votre amie : la doc Squid m’a sauvé la mise, lire la doc, toujours lire la doc !
- Les wildcards, c’est puissant : mais il faut connaître la syntaxe exacte de chaque outil
- Toujours surveiller les logs :
tail -fest votre meilleur ami pour le debugging
Mon homelab peut maintenant mettre à jour ses VMs en toute tranquillité, avec le proxy activé en permanence. Mission accomplie ! 🎉
Point d’amélioration : J’aimerais quand même revoir un peu la méthode avec le proxy, notamment pour être moins permissif et mettre en place correctement des whitelists et des ACL plus propre pour un prochain projet.