Différences

Ci-dessous, les différences entre deux révisions de la page.

--- commun:proxy_http [2026/08/01 14:33] – francois
+++ commun:proxy_http [2026/09/20 08:47] (Version actuelle) – francois
@@ Ligne 1: / Ligne 1: @@
 ====== Migration proxy HTTP : Raspi → NUC ======
-Migration du reverse proxy depuis un Raspberry Pi (Arch/ARM + Apache2 + Certbot) vers un NUC (Debian 13 + Docker + Caddy).
+Cette page décrit le reverse proxy de la maison. Il tournait auparavant sur un Raspberry Pi (Arch Linux, Apache et Certbot). Il tourne maintenant sur un NUC sous Debian 13, avec le logiciel Caddy dans un conteneur Docker.
-**Objectifs** : maintenabilité, robustesse, open-source, surveillance.
+Le changement visait une machine plus simple à entretenir, plus fiable, entièrement en logiciels libres et plus facile à surveiller.
 ===== 1. Système =====
@@ Ligne 9: / Ligne 9: @@
 ==== Distribution ====
-  * **Debian 13 "Trixie"** (stable depuis le 09/08/2025, support jusqu'en 2030)
+Le NUC fonctionne sous **Debian 13 « Trixie »**, version stable depuis le 9 août 2025 et maintenue jusqu'en 2030. L'installation est minimale : un serveur SSH et les outils habituels, sans interface graphique.
-  * Installation minimale : serveur SSH + utilitaires usuels, pas de GUI
-  * Noyau : ''linux-image-amd64'' (méta-paquet, suit les MAJ de sécurité)
+Le noyau est installé par le paquet ''linux-image-amd64'', qui suit automatiquement les correctifs de sécurité. Le bootloader est GRUB, le choix par défaut de Debian, qui s'entend bien avec LVM.
-  * Bootloader : **GRUB** (défaut Debian, robuste avec LVM)
 ==== Partitionnement ====
-Disque NVMe 250 Go, **LVM + ext4**, pas de chiffrement.
+Le disque est un NVMe de 250 Go, non chiffré. Il est découpé en trois partitions :
 ^ Partition ^ Taille ^ FS ^ Montage ^
@@ Ligne 23: / Ligne 22: @@
 | nvme0n1p3 | ~248 Go | LVM (PV) | — |
-VG ''volumes'' :
+La troisième partition est un volume physique LVM. Elle porte le groupe de volumes ''volumes'', découpé ainsi :
 ^ LV ^ Taille ^ FS ^ Montage ^
@@ Ligne 30: / Ligne 29: @@
 | lv-var | 35 Go | ext4 | /var |
 | lv-opt | 60 Go | ext4 | /opt |
-| //(libre)// | ~93 Go | — | réserve pour extension |
+| //(libre)// | ~93 Go | — | réserve |
+Environ 93 Go restent non alloués dans le VG, pour étendre un LV le jour où il sera plein.
 <note tip>
-Extension à chaud d'un volume si besoin :
+Un LV s'étend à chaud. Par exemple, pour ajouter 20 Go à ''/var'' :
 <code bash>
 lvextend -L +20G /dev/volumes/lv-var
@@ Ligne 44: / Ligne 45: @@
 ==== Adressage ====
-  * Routeur : **OpenWrt** (''192.168.1.90'', fait aussi office de DNS local)
+Le routeur est un OpenWrt à l'adresse ''192.168.1.90''. Il sert aussi de DNS local et résout les noms des machines internes.
-  * NUC : IP fixe **192.168.1.25** via réservation DHCP (MAC ''cc:28:aa:47:ea:ab'')
-  * Cette IP était celle de l'ancien proxy → bascule transparente (redirections de ports et noms internes inchangés)
+Le NUC a toujours l'adresse **192.168.1.25**. Il l'obtient par une réservation DHCP sur le routeur, liée à son adresse MAC ''cc:28:aa:47:ea:ab''.
+Cette adresse était déjà celle de l'ancien proxy. Le remplacement n'a donc demandé aucun changement ailleurs : les redirections de ports du routeur et les noms internes sont restés les mêmes.
 ==== Gestion réseau ====
-  * Interface ''enp1s0'' gérée par **ifupdown** (''/etc/network/interfaces'', ''iface enp1s0 inet dhcp'')
+L'interface ''enp1s0'' est gérée par ifupdown. Elle est déclarée en DHCP dans ''/etc/network/interfaces'' par la ligne ''iface enp1s0 inet dhcp''.
-  * Renouvellement bail DHCP : <code bash>sudo sh -c 'ifdown enp1s0; ifup enp1s0'</code>
+Pour renouveler le bail DHCP :
+<code bash>sudo sh -c 'ifdown enp1s0; ifup enp1s0'</code>
 <note warning>
-**Piège rencontré** : pour qu'une réservation DHCP prenne effet quand l'IP est encore occupée par une autre machine, il faut libérer l'IP (éteindre l'ancienne machine), purger les baux côté OpenWrt puis renouveler :
+**Piège rencontré.** Une réservation DHCP ne prend pas effet tant qu'une autre machine occupe encore l'adresse. Il faut éteindre l'ancienne machine, purger les baux sur OpenWrt, puis renouveler le bail sur le NUC :
 <code bash>
 # Sur OpenWrt
@@ Ligne 65: / Ligne 70: @@
 ==== Pare-feu (UFW) ====
+La politique par défaut refuse le trafic entrant et autorise le trafic sortant. Les ouvertures sont les suivantes :
 <code bash>
 ufw default deny incoming
 ufw default allow outgoing
-ufw allow 22/tcp     # SSH
+ufw allow from 192.168.1.0/24   to any port 22 proto tcp   # SSH depuis LAN1
-ufw allow 80/tcp     # HTTP (ACME challenge)
+ufw allow from 192.168.115.0/24 to any port 22 proto tcp   # SSH depuis le WiFi
+ufw allow from 10.1.100.0/24    to any port 22 proto tcp   # SSH depuis le VPN
+ufw allow 80/tcp     # HTTP (challenge ACME)
 ufw allow 443/tcp    # HTTPS
 ufw allow 443/udp    # HTTP/3
 ufw enable
+</code>
+SSH n'est joignable que depuis les réseaux internes (LAN1, WiFi, VPN). Le port est fermé côté Internet, en IPv4 comme en IPv6.
+Les règles sur les ports 80 et 443 sont là pour la lisibilité. En pratique, Docker publie lui-même ces ports par ses propres règles iptables, en amont d'UFW.
+==== Cloisonnement sortant de Caddy ====
+Le proxy est la seule machine de la maison directement exposée à Internet. Si Caddy était compromis, l'attaquant aurait un pied sur le LAN. Pour limiter les dégâts, le conteneur ne peut joindre, sur les réseaux privés, que les backends qu'il dessert réellement.
+Ce filtrage ne peut pas s'écrire avec les règles UFW habituelles. Caddy est sur un réseau bridge Docker : son trafic vers le LAN est routé par l'hôte et traverse la chaîne FORWARD, pas la chaîne OUTPUT. Les règles ''ufw allow out'' et ''ufw deny out'' ne s'y appliquent donc pas. Docker réserve à cet usage la chaîne ''DOCKER-USER'', évaluée avant ses propres règles.
+Les règles sont écrites à la fin du fichier ''/etc/ufw/after.rules''. UFW les charge à chaque démarrage et à chaque rechargement. Une copie du fichier d'origine est conservée sous le nom ''after.rules.bak''.
+<code>
+# BEGIN CADDY EGRESS
+*filter
+:DOCKER-USER - [0:0]
+-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN
+-A DOCKER-USER -s 172.18.0.0/16 -d 192.168.1.9 -p tcp -m multiport --dports 443,3000,3001,3002,8888,17170 -j RETURN
+-A DOCKER-USER -s 172.18.0.0/16 -d 192.168.1.67 -p tcp --dport 8123 -j RETURN
+-A DOCKER-USER -s 172.18.0.0/16 -d 192.168.1.90 -p udp --dport 53 -j RETURN
+-A DOCKER-USER -s 172.18.0.0/16 -d 192.168.1.90 -p tcp --dport 53 -j RETURN
+-A DOCKER-USER -s 172.18.0.0/16 -d 192.168.0.0/16 -j DROP
+-A DOCKER-USER -s 172.18.0.0/16 -d 10.0.0.0/8 -j DROP
+COMMIT
+# END CADDY EGRESS
+</code>
+Les règles se lisent de haut en bas, et la première qui correspond s'applique. La première laisse passer les connexions déjà établies, c'est-à-dire les réponses de Caddy aux clients du LAN. Les quatre suivantes autorisent les destinations du tableau ci-dessous. Les deux dernières font un DROP vers toutes les autres adresses privées, ce qui couvre LAN1, le WiFi et le VPN.
+^ Destination ^ Port ^ Service ^
+| cahute (.9) | 443 | Apache : blog, dav, musique, nuage, wiki |
+| cahute (.9) | 3000 | Gitea |
+| cahute (.9) | 3001 | Uptime-Kuma |
+| cahute (.9) | 3002 | Homepage |
+| cahute (.9) | 8888 | Dozzle |
+| cahute (.9) | 17170 | LLDAP (interface web) |
+| homeassistant (.67) | 8123 | Home Assistant |
+| routeur (.90) | 53 | DNS local |
+Internet reste accessible au conteneur. Il en a besoin pour ACME et pour joindre le DNS de secours ''1.1.1.1''.
+Trois conséquences sont à connaître :
+  * Un ''reverse_proxy'' ajouté au Caddyfile vers une adresse ou un port absent de ce tableau ne fonctionnera pas. Rien ne le signalera : la connexion part en timeout et le client reçoit un 502. Il faut d'abord ajouter la règle correspondante dans ''after.rules''.
+  * Les règles filtrent par IP, pas par nom. Home Assistant doit donc garder l'adresse ''.67'', ce qui suppose une réservation DHCP sur le routeur.
+  * La source ''172.18.0.0/16'' est le sous-réseau du bridge Docker. Il est figé dans le compose (voir §4), sans quoi il pourrait changer et rendre ces règles inopérantes.
+<code bash>
+# Recharger après une modification du bloc
+sudo ufw reload
+# Afficher la chaîne telle qu'elle est chargée
+sudo iptables -S DOCKER-USER
+# Vérifier que le blocage fonctionne : Cockpit (port 9090) n'est pas autorisé,
+# la commande doit échouer au bout de 3 secondes
+docker exec proxy-caddy-1 wget -T 3 -qO- http://192.168.1.9:9090 ; echo "code=$?"
 </code>
 ==== Fail2ban ====
-''/etc/fail2ban/jail.local'' :
+Fail2ban surveille les tentatives de connexion SSH. Une adresse qui échoue cinq fois en dix minutes est bannie pendant une heure. Le réglage se trouve dans ''/etc/fail2ban/jail.local'' :
 <code>
 [DEFAULT]
@@ Ligne 91: / Ligne 160: @@
 ==== SSH durci ====
-  * Clé SSH (ed25519) poussée via ''ssh-copy-id'' **avant** durcissement
+La connexion SSH se fait uniquement par clé (de type ed25519). Les mots de passe sont refusés (''PasswordAuthentication no'') et le compte root ne peut pas se connecter directement (''PermitRootLogin no'').
-  * ''PermitRootLogin no''
-  * ''PasswordAuthentication no''
+La clé a été copiée sur le NUC avec ''ssh-copy-id'' **avant** de désactiver les mots de passe. Dans l'ordre inverse, on se serait enfermé dehors.
 ==== Mises à jour automatiques ====
-  * ''unattended-upgrades'' activé (sécurité)
+Le paquet ''unattended-upgrades'' installe tout seul les correctifs de sécurité de Debian.
 ===== 4. Stack proxy =====
@@ Ligne 103: / Ligne 172: @@
 ==== Docker ====
-  * Docker 29 + Compose v5 (install via ''get.docker.com'')
+Le NUC utilise Docker 29 et Compose v5, installés avec le script officiel ''get.docker.com''. Tout ce qui concerne le proxy est rangé dans ''/opt/proxy/''.
-  * Projet dans ''/opt/proxy/''
 ==== Caddy ====
-Reverse proxy + **TLS automatique** (Let's Encrypt), remplace Apache2 + Certbot.
+Caddy fait office de reverse proxy et gère le TLS automatiquement : il obtient et renouvelle seul les certificats Let's Encrypt. Il remplace à lui seul Apache et Certbot.
+Le conteneur est décrit dans ''/opt/proxy/docker-compose.yml'' :
-''/opt/proxy/docker-compose.yml'' :
 <code yaml>
 services:
@@ Ligne 117: / Ligne 186: @@
     restart: unless-stopped
     dns:
-      - 192.168.1.90    # DNS local OpenWrt (résout les noms internes : cahute, etc.)
+      - 192.168.1.90    # DNS local OpenWrt : résout les noms internes (cahute, etc.)
       - 1.1.1.1         # secours public
     ports:
@@ Ligne 131: / Ligne 200: @@
   caddy_data:
   caddy_config:
+networks:
+  default:
+    ipam:
+      config:
+        - subnet: 172.18.0.0/16   # figé : référencé par les règles DOCKER-USER (§3)
 </code>
+<note>
+**Pourquoi figer le sous-réseau.** Sans le bloc ''networks'', Docker attribue le sous-réseau au moment où il crée le réseau. Un ''docker compose down'' suivi d'un ''up'' peut lui en donner un autre. Les règles ''DOCKER-USER'' du §3 ne correspondraient alors plus à rien, et Caddy retrouverait un accès libre à tout le LAN sans aucun symptôme.
+</note>
 <note important>
-**Deux pièges DNS rencontrés** :
+**Deux pièges rencontrés avec le DNS.**
-  - Le résolveur interne Docker (''127.0.0.11'') n'avait aucun nameserver amont → **SERVFAIL** sur les serveurs ACME. Résolu en forçant ''dns:'' dans le compose.
-  - En forçant un DNS **public** uniquement, les backends internes (''cahute.beafrancois.fr'') ne résolvaient plus → **502**. Résolu en mettant le DNS OpenWrt en premier.
+Au début, le résolveur interne de Docker (''127.0.0.11'') n'avait aucun serveur amont. Les requêtes vers les serveurs ACME renvoyaient SERVFAIL et Caddy n'obtenait pas ses certificats. Le problème a été réglé en forçant ''dns:'' dans le compose.
+Ensuite, avec un DNS public seul, les backends internes comme ''cahute.beafrancois.fr'' ne résolvaient plus, et les vhosts renvoyaient un 502. C'est pourquoi le DNS OpenWrt est placé en premier.
 </note>
 ==== Caddyfile ====
-  /opt/proxy/caddy/Caddyfile
+La configuration des vhosts se trouve dans ''/opt/proxy/caddy/Caddyfile''. Voici le modèle d'un vhost, dans le cas le plus courant d'un proxy HTTPS vers HTTPS en direction de ''cahute'' :
-Modèle d'un vhost (cas proxy HTTPS→HTTPS vers cahute) :
 <code>
 blog.beafrancois.fr {
@@ Ligne 158: / Ligne 238: @@
 <note tip>
-**''header_up Host <nom-public>''** est essentiel : équivalent du ''ProxyPreserveHost On'' d'Apache. Sans lui, Caddy transmet le Host de l'upstream (''cahute'') et le backend renvoie des URLs/redirections vers ''cahute'', cassant la navigation depuis l'extérieur.
+La directive ''header_up Host'' transmet au backend l'en-tête Host demandé par le client. Sans elle, Caddy envoie le Host de l'upstream (''cahute''), et le backend génère des URL et des redirections vers ce nom, qui ne résout pas depuis l'extérieur. C'est l'équivalent du ''ProxyPreserveHost On'' d'Apache.
-**''tls_insecure_skip_verify''** : équivalent de ''SSLProxyVerify none'' (backend en cert auto-signé/non vérifié).
+La directive ''tls_insecure_skip_verify'' désactive la vérification du certificat du backend, parce que celui de ''cahute'' est auto-signé. C'est l'équivalent du ''SSLProxyVerify none'' d'Apache.
 </note>
@@ Ligne 166: / Ligne 246: @@
 ^ Domaine ^ Backend ^ Particularité ^
-| blog | cahute/blog | redir → /blog/ |
+| blog | cahute/blog | redirection de / vers /blog/ |
-| dav | cahute/dav/html/ | redir → /dav/html/ |
+| dav | cahute/dav/html/ | redirection de / vers /dav/html/ |
 | git | cahute:3000 | — |
-| musique | cahute/musique/ | redir → /musique/ |
+| musique | cahute/musique/ | redirection de / vers /musique/ |
-| nuage | cahute/nextcloud | redirects .well-known (carddav/caldav/webfinger/nodeinfo) |
+| nuage | cahute/nextcloud | redirections .well-known (carddav, caldav, webfinger, nodeinfo) |
-| wiki | cahute/dokuwiki/ | redir → /dokuwiki/ |
+| wiki | cahute/dokuwiki/ | redirection de / vers /dokuwiki/ |
-| service | homeassistant:8123 (HTTP) | WebSocket natif Caddy |
+| service | homeassistant:8123, en HTTP | WebSocket géré nativement par Caddy |
-<note>''shell.beafrancois.fr'' retiré : pas d'enregistrement DNS (NXDOMAIN).</note>
+Le vhost ''shell.beafrancois.fr'' n'a pas été repris, car il n'a plus d'enregistrement DNS (NXDOMAIN).
+<note warning>
+Un nouveau vhost qui pointe vers une adresse ou un port absent du bloc ''CADDY EGRESS'' (§3) ne fonctionnera pas tant que la ligne correspondante n'aura pas été ajoutée dans ''/etc/ufw/after.rules''.
+</note>
 ==== Limite de taille des logs ====
-''/etc/docker/daemon.json'' :
+Les logs des conteneurs sont limités à cinq fichiers de 50 Mo chacun, pour ne pas remplir le disque. Le réglage est dans ''/etc/docker/daemon.json'' :
 <code json>
 {
@@ Ligne 186: / Ligne 271: @@
 </code>
-''/etc/systemd/journald.conf'' : <code>SystemMaxUse=2G</code>
+Le journal systemd est limité à 2 Go par la ligne ''SystemMaxUse=2G'' dans ''/etc/systemd/journald.conf''.
 ===== 5. Mise à jour de l'image Caddy =====
-Opération **manuelle**, faite sur le proxy. Aucune mise à jour automatique de conteneur (pas de Watchtower) : une régression ne doit jamais arriver sans avoir été déclenchée.
+La mise à jour de Caddy se fait **à la main**, sur le proxy. Aucun outil ne met à jour le conteneur automatiquement : si une nouvelle version casse quelque chose, il faut que ce soit au moment où on l'a décidé, pas par surprise.
 <code bash>
 cd /opt/proxy
-# 1. Sauvegarder la config avant toute manip
+# 1. Sauvegarder la configuration avant de toucher à quoi que ce soit
 sudo cp -a /opt/proxy /root/proxy-$(date +%F)
-# 2. Noter la version en cours (pour le rollback)
+# 2. Noter la version en cours, pour pouvoir y revenir
 docker compose exec caddy caddy version
@@ Ligne 204: / Ligne 289: @@
 docker compose pull
-# 4. Recréer le conteneur
+# 4. Recréer le conteneur avec cette image
 docker compose up -d
-# 5. Contrôler
+# 5. Contrôler les logs, puis chaque vhost
 docker compose logs --tail 40 caddy | grep -Ei "obtained|error|panic"
 for h in blog dav git musique nuage wiki service; do
@@ Ligne 214: / Ligne 299: @@
 </code>
-**Rollback** : remettre le tag de version précis de l'ancienne version dans le compose (''image: caddy:2.x.y-alpine''), puis ''docker compose up -d''. Les certificats sont dans le volume ''caddy_data'' et ne sont pas perdus : le retour arrière est immédiat.
+**Rollback.** Dans le compose, on remplace ''caddy:alpine'' par le tag exact de l'ancienne version (par exemple ''image: caddy:2.x.y-alpine''), puis on relance ''docker compose up -d''. Les certificats sont conservés dans le volume ''caddy_data'', donc le rollback est immédiat.
 <note tip>
-Consulter le changelog Caddy avant une mise à jour de version mineure : des directives du Caddyfile peuvent changer. En cas de doute, valider la config avant de recréer le conteneur :
+Avant une mise à jour, il vaut mieux lire le changelog de Caddy, car des directives du Caddyfile changent parfois. En cas de doute, on peut vérifier la configuration avant de recréer le conteneur :
 <code bash>docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile</code>
 </note>
 <note warning>
-Le tag ''alpine'' suit la dernière version : un ''docker compose pull'' peut donc ramener une version majeure sans prévenir. Le rollback exige de connaître la version qui tournait — d'où l'étape 2.
+Le tag ''alpine'' suit toujours la dernière version publiée. Un ''docker compose pull'' peut donc installer une version majeure sans prévenir. Le rollback exige de connaître la version qui tournait avant : c'est la raison de l'étape 2.
 </note>
-===== 6. Procédure de bascule (rollback-friendly) =====
+===== 6. Procédure de bascule =====
-  - Baisser le TTL DNS à 60s (J-24h)
+Cette procédure est celle qui a servi à passer du Raspberry Pi au NUC. À chaque étape, il restait possible de revenir à l'ancien proxy.
-  - Démarrer Caddy sur le NUC (échecs ACME normaux tant que le trafic n'arrive pas)
-  - Basculer la réservation DHCP / redirection routeur vers le NUC
+  - La veille, abaisser le TTL DNS à 60 secondes, pour qu'un changement se propage rapidement.
-  - Vérifier l'obtention des certificats : <code bash>docker compose logs -f caddy | grep -E "obtained|error"</code>
+  - Démarrer Caddy sur le NUC. Les challenges ACME échouent tant qu'il ne reçoit pas le trafic, c'est normal.
-  - Tester chaque service (''curl -sI'')
+  - Sur OpenWrt, basculer la réservation DHCP vers le NUC, ou pointer vers lui la redirection de ports.
-  - **Rollback** : remettre l'ancienne IP/redirection sur OpenWrt → retour immédiat au Raspi
+  - Vérifier que les certificats sont obtenus : <code bash>docker compose logs -f caddy | grep -E "obtained|error"</code>
-  - Après 48 h de stabilité : éteindre le Raspi
+  - Tester chaque vhost avec ''curl -sI''.
+  - Pour un rollback, remettre l'ancienne réservation ou l'ancienne redirection sur le routeur : le Raspberry Pi reprend aussitôt la main.
+  - Après 48 heures sans incident, éteindre le Raspberry Pi.
 ===== 7. Commandes utiles =====
 <code bash>
-# Recharger la config après modif du Caddyfile
+# Prendre en compte une modification du Caddyfile, sans couper les connexions en cours
 docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile
-# Recharger la config après modif du Caddyfile (avec coupure des connexions)
+# Même chose en redémarrant le conteneur (coupe les connexions en cours)
 docker compose restart caddy
@@ Ligne 247: / Ligne 334: @@
 docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile
-# Suivre les logs
+# Suivre les logs en direct
 docker compose logs -f caddy
-# État des conteneurs
+# État du conteneur
 docker compose ps
-# Espace disque / LVM
+# Chaîne DOCKER-USER telle qu'elle est chargée
+sudo iptables -S DOCKER-USER
+# Place disponible sur le disque et dans les volumes
 df -h && vgs && lvs
 </code>
-===== TODO / pistes =====
+===== Ce qui reste à faire =====
-  * Épingler le tag Caddy sur une version exacte plutôt que ''alpine''
+  * Épingler le tag Caddy sur une version exacte plutôt que ''alpine'', pour maîtriser les mises à jour de Caddy.
-  * Surveillance : Grafana + Prometheus + Loki + cAdvisor (prévu, non encore déployé)
+  * Mettre en place la surveillance prévue (Grafana, Prometheus, Loki, cAdvisor), qui n'est pas encore déployée.
-  * Sauvegarde du volume ''caddy_data'' (certificats) — ex. restic
+  * Sauvegarder le volume ''caddy_data'', qui contient les certificats, par exemple avec restic.
-  * Optionnel : logwatch, rkhunter
+  * Éventuellement, installer logwatch et rkhunter.
-  * Créer l'enregistrement DNS ''shell'' si ce service doit revenir
+  * Recréer l'enregistrement DNS ''shell'' si ce service doit revenir.