Architecture v3 : Caddy, de l’autre côté du miroir

Dans l'article précédent, j'avais retrouvé mon indépendance avec FRP et Caddy. Mais Caddy tournait encore sur le VPS, et chaque nouveau service nécessitait d'y modifier la config. Cette troisième itération règle ce problème — et simplifie radicalement l'ensemble.

Le déclencheur : migrer le domaine chez Infomaniak

Tout a commencé par un calcul comptable. En migrant mon VPS chez Infomaniak, j'ai réalisé qu'en y transférant aussi mon nom de domaine et mes mails (auparavant chez Amen), la facture globale était plus légère. Mais au-delà du coût, c'est un détail technique qui a tout changé : Infomaniak expose une API robuste pour la gestion DNS.

Le challenge DNS : pourquoi tout bascule

Jusqu'ici, Caddy tournait sur le VPS parce qu'il avait besoin d'un port 80 accessible depuis internet pour générer ses certificats Let's Encrypt via challenge HTTP.

Avec l'API Infomaniak, j'ai pu passer au challenge DNS : plutôt que Let's Encrypt vérifie un fichier sur mon serveur, Caddy écrit directement un enregistrement temporaire dans ma zone DNS via l'API pour prouver la possession du domaine. Plus besoin d'exposer Caddy sur le web.

Conséquence directe : Caddy peut tourner en local, dans mon réseau domestique.

FRP réduit à un passe-plat TCP

Ce déplacement de Caddy a radicalement simplifié le tunnel.

Le VPS ne fait plus qu'acheminer le trafic brut sur les ports 80 et 443 vers mon réseau local, sans connaître ni interpréter ce qui transite. Deux proxies TCP, c'est tout. Le VPS ne sait plus rien de mes services.

Caddy en local : toute la puissance retrouvée

Avec Caddy rapatrié, toute la configuration des services est centralisée dans un seul fichier local. C'est là que réside la vraie force de cette architecture : ajouter un nouveau service se résume à quelques lignes dans ce fichier, sans aucune intervention sur le VPS.

Caddy gère nativement plusieurs cas de figure que j'ai rencontrés :

• Les services compatibles OIDC, qui délèguent directement l'authentification à Authentik
• Les services sans support OIDC, protégés par Authentik via forward auth
• Les services qui n'ont aucune gestion d'authentification moderne, pour lesquels Caddy injecte automatiquement les credentials dans les headers

La pièce manquante : ADGuard Home

Il reste un problème à régler. Authentik est lié à mon domaine. Depuis l'extérieur, tout passe par le VPS (c'est le but). Mais depuis l'intérieur du réseau, ces noms de domaine résolvaient aussi vers le VPS, obligeant chaque requête locale à sortir sur internet avant de revenir.

La solution : un serveur DNS interne. J'ai déployé ADGuard Home avec une réécriture DNS qui pointe tous mes sous-domaines directement vers Caddy en local. Toutes les requêtes restent désormais sur le réseau domestique, Authentik inclus. C'est la pièce sans laquelle le SSO ne fonctionne pas correctement en local.

Pourquoi cette architecture est la bonne

• Sécurité : les certificats SSL sont stockés chez moi, pas sur un serveur exposé
• Simplicité : un seul fichier Caddy local pour gérer tous les services
• Résilience : si le VPS est indisponible, les services restent accessibles en local
• Souveraineté : aucun géant du cloud dans la chaîne, pour moins cher qu'un abonnement Netflix

Conclusion sur ces différentes étapes

D'XTNA et Azure à un passthrough TCP sur un VPS Infomaniak, Caddy en local et ADGuard Home comme DNS interne, l'infrastructure a parcouru du chemin. La prochaine série d'articles portera sur les nouveaux serveurs, l'IaC avec OpenTofu et Ansible, et je reveindrai sur chacun des services pertinents pour montrer leur configuration.