← Journal technique

networking

Cloudflare comme périmètre extérieur

Cloudflare comme périmètre extérieur

Se trouve devant tout — le DNS se résout via Cloudflare, et avec le proxying activé, tout le trafic passe par le réseau de Cloudflare avant d'atteindre le serveur. Je l'ai ajouté une fois que l'échelle réelle attendue — beaucoup d'organisations, beaucoup d'utilisateurs simultanés — a rendu la couche supplémentaire justifiée, et non dans le cadre de l'installation simple d'origine.

Ce que ça apporte :

  • Un DNS via un réseau anycast est plus rapide qu'un unique serveur de noms d'origine, et rend la résolution elle-même résiliente à une origine hors service.
  • La protection DDoS absorbe le trafic malveillant à la périphérie de Cloudflare avant qu'il n'atteigne l'origine. Une attaque volumétrique qui submergerait une petite VM est absorbée sur une infrastructure qu'un serveur auto-hébergé unique ne peut pas espérer répliquer.
  • La mise en cache CDN sert les ressources statiques depuis des emplacements de périphérie proches de l'utilisateur plutôt qu'un aller-retour vers l'origine à chaque fois — une latence sensiblement plus basse pour une plateforme consultée depuis toute une région.
  • Le masquage de l'IP d'origine — avec le proxying activé, la vraie IP de l'origine n'est pas directement exposée ; le trafic semble se terminer chez Cloudflare. Ça bloque le contournement bien connu qui consiste à attaquer l'IP d'origine directement, tant que l'origine est aussi pare-feutée pour n'accepter que les plages connues de Cloudflare.
Utilisateur → Cloudflare (DNS, DDoS, cache CDN, TLS) → Caddy (route par domaine) → conteneurs d'application

La mauvaise configuration à connaître

Deux couches de HTTPS existent dans une installation complète — Cloudflare termine avec le client, puis rechiffre (ou pas, selon le mode SSL) vers Caddy, qui termine à nouveau. Se tromper de mode SSL Cloudflare — Flexible vs Full vs Full (strict) — est une erreur facile et courante qui peut dégrader silencieusement la connexion à l'origine en HTTP simple pendant que la connexion côté utilisateur s'affiche toujours comme sécurisée.

C'est exactement le genre d'infrastructure invisible quand elle marche et catastrophique quand elle manque. Une plateforme qui attend une vraie croissance veut cette couche en place avant d'être sous charge ou sous attaque, pas mise en position dans l'urgence pendant le pic réel.