Ça fait un moment que je n'avais rien cassé ici, que ce soit sur le site, les conteneurs ou le serveur qui héberge lesdits conteneurs. Il était temps de mettre un peu d'ordre et d'essayer des choses.

Version courte : je n'ai pas lu la documentation et ç'a tout planté.

Version plus longue ci-dessous :

Le problème est le suivant : impossible d'accéder à mes applications depuis l'internet, les navigateurs web affichent en boucle une erreur de communication avec la destination, ou une erreur TLS (soit les ciphers, soit la méthode).

J'utilise les outils Docker et Traefik dans une VM Debian 12, Cloudflare pour le registraire et diverses applications conteneurisées pour mes besoins.

En faisant des mises à jour des images des conteneurs que j'utilise, j'ai modifié les déclarations effectuées dans les différents fichiers docker-compose.yml. Entre les versions d'images, le formatage dans les variables ou le passage d'un volume monté à un volume docker, il y a eu beaucoup de manutention. Pour couronner le tout, j'ai mis à jour les différents paramètres DNS, TLS et WAF de Cloudflare. J'utilise leurs services depuis plusieurs mois avec succès, sans contrepartie ni régression. Passons le côté sécurité (entendez ici le MITM de tous les flux), leurs outils fonctionnent, sont hautement disponibles et répondent à mes besoins.

Après avoir importé le domaine hommet.net chez eux, j'ai décidé de laisser les options par défaut proposées par Cloudflare sur le DNS. Ça fonctionnait très bien depuis plus mois tel quel, rien à redire. Pour aller plus loin et comprendre ce qui était configuré, j'ai cliqué à divers endroits, activé/désactivé des options... sans voir véritablement des effets de bords.

Vous avez le contexte et l'environnement dans lequel j'étais - maintenant entrons dans le sujet, le DNS. J'aime avoir un certificat SSL par enregistrement DNS. Je construis mes enregistrements DNS de la sorte :


[...]
enregistrement1 A 192.168.10.22
enregistrement2 A 192.168.0.21
enregistrement99 CNAME enregistrement1
[...]
sous.domaine.net A 192.168.12.55
home.sous.domaine.net A 192.168.12.55
app1.prive.domaine.net A 192.168.12.55
app.prive.domaine.net CNAME app1.prive.hommet.net
app2.lab.domaine.net A 192.168.12.55
app3.domaine.net A 192.168.32.98

Je suis loin d'avoir la culture de S. BORTZMEYER côté DNS, je me débrouille avec ce genre d'enregistrements selon les besoins persos et pros. En ajoutant ce genre d'enregistrement dans la console Cloudflare (en cochant la case "proxy" pour bénéficier de la protection Cloudflare), tout fonctionne à un détail près, une icône "attention" à côté des enregistrements ayant la forme w.x.domaine.net. Je n'y prête pas attention, puisque l'erreur spécifie "il n'y a pas de certificat valide pour ce domaine".

Continuant les mises à jour des images et des configurations pour les différentes applications, je remarque que Traefik génère beaucoup de logs en "WARN", souvent causé par des problèmes d'exécution des middlewares. Rien d'anormal (passant de Traefik v2 à v3, j'ai eu quelques corrections à apporter dans les fichiers de configuration), mais à force d'avancer, je perdais l'accès à mes applications depuis le web. En redémarrant les conteneurs, toujours pas d'accès. Pire encore, lorsque je repassais sur d'anciennes versions d'images de conteneur, les applications étaient complètement HS. Joie.

Entre temps, j'avais sauvegardé mes configurations et les données de chaque application. J'étais serein sur ma capacité à restaurer les services en dernier recours, la procédure a déjà été testée et est rodée. La preuve en est avec cet article, qui s'ajoute sur une pile d'autres articles provenant d'une sauvegarde journalière :).

Dans les logs des conteneurs, rien d'anormal, pas d'erreur "qui saute aux yeux". Je continue de regarder côté docker et de la machine hôte, en m'apercevant qu'il y a quelques blocages et des erreurs de configuration entre iptables, les docker bridge et les déclarations de réseau dans mes fichiers docker-compose. Encore de longues minutes frustrantes, à essayer de modifier les paramètres, hélas sans succès.

Après des heures à redémarrer les services, les conteneurs, mettre à jour tout et n'importe quoi, activer/désactiver des options dans la console Cloudflare, utiliser les outils de test de connectivité, éplucher chaque ligne de log (il y a eu beaucoup de surprises d'ailleurs)... Je capitule, plus rien ne fonctionne, aucun accès web et pourtant tous les services sont "up".

🤨
J'en ai marre !

Aller, on arrête tout, les sauvegardes sont faites et la restauration fonctionne, c'est parti pour détruire la machine.

Toujours chez Contabo, je loue un nouveau VPS plus léger en ressources, amplement suffisant pour mon besoin. Je réinstalle cette fois Ubuntu 22 LTS, me disant que c'était la faute à l'image Debian 11 mise à jour en Debian 12, fournie par Contabo, que je ne maîtrise pas et qui a sans doute eu un problème de mise à jour (non ce n'était pas l'image ni la faute de Contabo). En réinstallant les outils et en créant les conteneurs de mes applications, je retrouve les mêmes problèmes qu'avant, impossible d'accéder aux applications via le web. Cette fois, c'est trop, je mets les logs en "debug", un bon café et on analyse.

La résolution du problème

Premier indice, c'est grâce à Traefik que je comprends le problème. Après avoir réécrit l'ensemble des configurations, je vois qu'il y a des boucles et des incompatibilités entre les paramètres que je sélectionne. Une fois en ordre, les certificats se génèrent bien via Cloudflare/Let's Encrypt, et pourtant je vois toujours ces erreurs de communication dans les navigateurs web…

Je trouve la réponse sur cette page :

Limitations for Universal SSL · Cloudflare SSL/TLS docs
Universal SSL certificates are limited by the hostnames they cover and the browsers they support.
Cloudflare Docs

Pour rappel, j'utilise Traefik et Cloudflare pour gérer mes enregistrements DNS et créer des certificats SSL Let's Encrypt de type w.x.domaine.net.

Épilogue

Le souci, c'est que j'ai des noms de domaine trop "complexe" pour l'offre gratuite de Cloudflare, tout simplement… Je cite :

To enable SSL support on second, third, and fourth-level subdomains such as dev.www.example.com or app3.dev.www.example.com, you can: "Purchase Advanced Certificate Manager to order advanced certificates" or "Upgrade to a Business or Enterprise plan to upload custom certificates."

Fini les enregistrements "app.prive.domaine.net", obligé de faire "app.domaine.net" pour que ça fonctionne. Vous n'imaginez pas comment j'ai hurlé quand j'ai lu et compris le problème. C'est TOUJOURS la faute du DNS (sort of).

L'autre solution serait peut-être de faire des CNAME et éviter cette limitation, avec ce genre de configuration :

srv A 192.168.100.1
app1.prive.domaine.net CNAME srv
app2.domaine.net CNAME srv

J'ai recréé tous les enregistrements DNS, tout est désormais fonctionnel sans erreurs, avec un joli certificat SSL. Tss…

Morale : lisez cette satanée documentation et faites des sauvegardes, tout le temps, partout ! Le problème venait en partie de mon utilisation de Cloudflare.

Share this post