Vous l’avez peut-être remarqué, le journal a fait peau neuve. Comme je l’ai déjà expliqué, l’ancien thème était vieillissant (ChatGPT l’a même qualifié de 2015 😠) et surtout les performances d’affichage étaient catastrophiques. L’objectif de cette nouvelle version était donc de proposer quelque chose de plus léger et plus maintenable (je ne vais pas revenir dessus, je l’ai déjà détaillé ailleurs).

L’autre objectif était d’améliorer les performances. Pour cela, j’ai abandonné Jetpack Boost, efficace mais limité pour un usage avancé, au profit de W3 Total Cache. Je me suis d’ailleurs largement inspiré de cet excellent article pour le configurer.

Mais si j’écris aujourd’hui, c’est surtout pour parler de Cloudflare. J’avais en effet envie de migrer vers Cloudflare pour plusieurs raisons :

• améliorer les performances grâce à un CDN plus robuste que celui de Jetpack,
• masquer les IP derrière mes services,
• renforcer globalement la sécurité.

Déjà, c’est quoi Cloudflare ?

Cloudflare est un service qui se place entre vos utilisateurs et votre infrastructure (reverse proxy). Il fournit plusieurs briques : un CDN pour accélérer la distribution de contenu, une protection DDoS, un pare-feu applicatif (WAF), ainsi que des fonctionnalités DNS. Concrètement, le trafic passe par les serveurs de Cloudflare, qui peuvent mettre en cache, filtrer ou sécuriser les requêtes avant de les relayer vers votre backend.

Étape 1 : basculer ses DNS chez Cloudflare

L’interface Cloudflare est assez efficace : il suffit d’ajouter (connecter) un domaine et de suivre les instructions.

Dans mon cas, j’ai subi une interruption de service temporaire pendant la propagation DNS. C’est un point à anticiper : même si la bascule est simple, elle n’est pas instantanée.

À noter également que je suis sur l’offre gratuite qui dans mon cas est suffisante :

Étape 2 : gestion des DNS

Je suis parti de l’import automatique de Cloudflare, que j’ai ensuite complété car il était incomplet. J’ai également fait le ménage des enregistrements spécifiques à Infomaniak (notamment _domainkey).

En revanche, j’ai conservé la gestion des emails et d’autres éléments (autoconfig et autodiscover) chez Infomaniak, tandis que le reste est passé en mode « proxifié » via Cloudflare.

Le choix dépend donc du service exposé : web → orange, autres protocoles → gris.

Étape 3 : SSL / TLS

Je ne souhaitais pas dépendre entièrement de Cloudflare pour les certificats. Je continue donc à utiliser Let’s Encrypt, généré via Traefik & acme.sh (j’ai plusieurs serveurs et plusieurs stacks).

Cependant, cela introduit un point d’attention : les challenges ACME (de type DNS-01) ne passent plus par l’API d’Infomaniak mais par celle de Cloudflare, puisque la zone DNS est désormais gérée chez eux. J’ai donc dû adapter la configuration de Lego (Traefik) ainsi que celle du DNS API (acme.sh) pour que tout fonctionne correctement… Et ça je l’avais zappé jusqu’au moment de renouveler un certificat 😉.

Sur l’illustration ci-dessus le certificat entre Cloudflare et le(s) serveur(s) d’origine(s) est un certificat Lets’encrypt classique. Dans cette configuration, il est toujours possible d’accéder directement à l’IP du serveur si elle est connue. Dans ce cas, on contourne Cloudflare et on revient au fonctionnement précédent.

curl -v https://blog.kulakowski.fr --resolve blog.kulakowski.fr:443:<IP_SERVER>

Pour éviter cela, il est recommandé de filtrer les accès entrants (firewall) afin de n’autoriser que les IP de Cloudflare et, en complément, d’activer une vérification du certificat client présenté par Cloudflare (on y viendra prochainement).

Étape 4 : CDN / cache

Pour la gestion du cache (CDN), j’ai mis en place une règle afin de ne mettre en cache que le blog :

(http.host ne "blog.kulakowski.fr") => Contourner le cache

Le reste est géré directement par W3 Total Cache, je rappelle juste que la configuration de Cloudflare est accessible depuis les extensions W3TC.

Étape 5 : sécurité

J’ai activé un maximum de fonctionnalités de sécurité côté Cloudflare, même si une grande partie était déjà gérée par mes serveurs. Je n’ai donc pas rencontré de problème majeur, mais j’ai dû ajouter deux règles spécifiques.

Cas 1 : Python-urllib (seedboxsync)

Certaines requêtes étaient bloquées à cause du user-agent. J’ai donc ajouté une règle pour autoriser Python-urllib :

(http.host eq "sub.domain.ltd" and http.user_agent contains "Python-urllib")

Composants ignorés :

• Règles personnalisées
• Mode « Super Bot Fight »
• Vérification de l’intégrité du navigateur

Cas 2 : Home Assistant avec Google Assistant

Même logique pour certaines routes utilisées par Home Assistant :

(http.host eq "sub.domain.ltd" and http.request.uri.path in {"/api/google_assistant" "/auth/token" "/auth/authorize"})

Composants ignorés :

• Règles personnalisées
• Limitation de débit (rate limiting)
• Règles gérées
• Mode « Super Bot Fight »
• Blocage d’agents utilisateurs
• Vérification de l’intégrité du navigateur

Ce que je n’avais pas anticipé

Premier point, comme évoqué plus haut : j’avais complètement oublié de reconfigurer Traefik et acme.sh. En pratique, ce n’est pas compliqué : il suffit de consulter la documentation pour identifier les variables à définir et générer un jeton d’API dans votre profil Cloudflare. Il existe même un template dédié : « Modifier le DNS de la zone ».

Autre point important : dans sa version gratuite (en tout cas au moment où j’écris ces lignes), Cloudflare ne proxifie que le trafic HTTP/HTTPS.

Conséquence directe :

• les services non HTTP (comme SSH) ne fonctionnent pas via un domaine configuré en mode « proxifié » (nuage orange),
• il est toujours possible de les faire fonctionner en mode « DNS only » (nuage gris), mais on perd alors les bénéfices du proxy Cloudflare.

Il existe néanmoins des alternatives selon les besoins :

• Cloudflare Tunnel (cloudflared) pour exposer certains services comme SSH,
• Spectrum (offre payante) pour proxyfier du TCP/UDP.

Autre point que j’avais oublié : j’utilisais un domaine avec Prometheus pour scraper des métriques via une authentification mTLS. Cette configuration a cessé de fonctionner, car Cloudflare termine la connexion TLS côté edge. J’ai dû utiliser un composant spécifique de Cloudflare pour corriger cela, mais ce sera le sujet d’un prochain article.

Conclusion

La migration vers Cloudflare apporte un vrai gain en performance et en sécurité, mais elle introduit aussi des effets de bord qu’il faut anticiper : mTLS, accès SSH, gestion des certificats ACME ou encore exposition réelle de l’IP d’origine.

Rien d’insurmontable, mais il vaut mieux le savoir avant de se lancer.