Différences

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

--- commun:architecture_serveur [2026/06/17 18:24] – créée francois
+++ commun:architecture_serveur [2026/09/20 12:22] (Version actuelle) – francois
@@ Ligne 1: / Ligne 1: @@
 ====== Architecture complète du serveur ======
-Dernière mise à jour : juin 2026
+Dernière mise à jour : septembre 2026
+Cette page donne la vue d'ensemble de l'infrastructure telle qu'elle fonctionne aujourd'hui. Le détail du reverse proxy se trouve sur la page « Migration proxy HTTP : Raspi → NUC », et le détail des flux et des règles de filtrage sur la page « Architecture du réseau — beafrancois.fr ».
 ===== Vue d'ensemble =====
-Infrastructure à trois machines sur un LAN1 filaire, avec un réseau wifi (LAN2) isolé. Tous les services tournent sous Docker sur le serveur principal.
+L'infrastructure repose sur trois machines d'infrastructure placées sur le LAN1 filaire : le routeur OpenWrt, le reverse proxy ''proxyhttp'' et le serveur principal ''cahute''. Les postes fixes sont sur LAN1, les portables sur le WiFi (LAN2) ou, hors de la maison, sur le VPN WireGuard.
+Les applications web historiques tournent en bare-metal sur ''cahute'', derrière Apache. Docker n'héberge que l'annuaire et les outils de supervision.
 <code>
 Internet
-    |  443/80
+    |  443                             |  8329 (SSH Gitea)      |  WireGuard (UDP)
-    v
+    v                                  |                        v
-[ Routeur ]  ──(isolé)──>  [ LAN2 wifi ]
+[ Routeur OpenWrt .90 ] ── DNS local, DHCP, VPN 10.1.100.0/24, LAN2 WiFi 192.168.115.0/24
-    |
+    |                                  |
-    v  LAN1
+    v  LAN1 192.168.1.0/24             |
-[ Proxy — Caddy ]   TLS · Let's Encrypt · reverse proxy · forward_auth
+[ proxyhttp .25 — Caddy ]              |
-    |
+    |  TLS Let's Encrypt, reverse proxy, filtre remote_ip sur les vhosts d'admin
-    v  LAN1 (ports internes)
+    v  ports autorisés uniquement      v
-[ Serveur principal ]
+[ cahute .9 — serveur principal ]
-    |── Auth       : Kanidm · Authelia
+    |── Bare-metal : Apache (Nextcloud, DokuWiki, Ampache, blog, dav) · Gitea · MariaDB
-    |── Services   : Nextcloud · Blog · DokuWiki · Ampache · MariaDB
+    |                NFS 4.2 · Cockpit · sssd
-    |── Surveillance : Cockpit · Uptime Kuma · Dozzle · CrowdSec · Homepage
+    |── Docker     : LLDAP · Uptime-Kuma · Homepage · Dozzle · Diun · imaginary
-    └── Stockage   : Soft-RAID mdadm 2 To (volumes Docker bindés)
+    └── Stockage   : soft-RAID mdadm 2 To (/mnt/stockage)
-[ Portables ×4 ]
+[ homeassistant .67 ]  Raspberry Pi 5, Home Assistant, publié par Caddy
-    |── kanidm-unixd  (cache offline · PAM)
-    |── Home local    (pas de NFS)
+[ 2 PC tour LAN1 ]     sssd → LLDAP (LDAPS) · partages en NFS 4.2
-    |── Client Nextcloud · Client Ampache · Navigateur web (SSO)
+[ Portables ]          WiFi · sssd → LLDAP (LDAPS, cache offline) · home local · NFS par le VPN
 </code>
-===== Les trois machines =====
+===== Réseaux =====
-==== Routeur ====
+^ Réseau ^ Plage ^ Rôle ^
+| LAN1 | 192.168.1.0/24 | Réseau filaire : routeur, proxy, serveur, postes fixes, Home Assistant |
+| LAN1, zone de confiance | 192.168.1.0/26 | Sous-plage (.0 à .63) autorisée sur ''cahute'' pour NFS, SSH et Cockpit |
+| LAN2 | 192.168.115.0/24 | WiFi des portables, zone ''invite'' d'OpenWrt |
+| VPN | 10.1.100.0/24 | Tunnel WireGuard terminé sur OpenWrt, routé vers LAN1 |
-  * NAT entrant : ports 80 et 443 redirigés vers Caddy
+Le proxy (.25) se trouve dans la plage /26, mais une règle ''deny'' placée en tête de l'UFW de ''cahute'' lui ferme NFS, rpcbind, SSH et Cockpit. La seule machine exposée à Internet ne fait donc pas partie de la zone de confiance, bien que son adresse y soit.
-  * Pare-feu : LAN2 wifi isolé du LAN1 filaire
-  * Le serveur principal n'est jamais exposé directement à Internet
-==== Proxy — Caddy ====
+Home Assistant (.67) est hors de la plage /26 : il n'a accès à aucun de ces services.
-  * Terminaison TLS et gestion des certificats Let's Encrypt
+===== Les trois machines =====
-  * Reverse proxy vers les services du serveur principal
-  * ''forward_auth'' vers Authelia pour chaque requête entrante
-  * Machines : proxy dédié sur LAN1, indépendant du serveur
-==== Serveur principal ====
+==== Routeur ====
-  * **OS :** Debian Trixie (13), kernel 6.x
+Le routeur est un OpenWrt à l'adresse ''192.168.1.90''. Il assure le DHCP, avec une réservation pour le proxy (.25), et sert de DNS local : c'est lui qui résout les noms internes comme ''cahute.beafrancois.fr''.
-  * **Matériel :** AMD x86, 8 Go RAM, 2 To en soft-RAID (mdadm)
-  * **Conteneurisation :** Docker CE (dépôt officiel), Docker Compose v2
-  * Cockpit installé en bare-metal (hors Docker), accessible LAN uniquement sur '':9090''
-===== Services Docker =====
+Il redirige le 443 vers le proxy, le 6360 et le 9090 vers ''cahute'' pour les zones internes, et le 8329 vers ''cahute'' pour le SSH de Gitea. Il termine aussi le tunnel WireGuard, dont le sous-réseau ''10.1.100.0/24'' est autorisé à joindre LAN1.
-==== Authentification ====
+==== Proxy — Caddy ====
-^ Service     ^ Rôle                                    ^ Port exposé         ^ RAM estimée ^
+Le proxy est un NUC sous Debian 13, à l'adresse ''192.168.1.25''. Caddy y tourne dans un conteneur Docker. Il termine le TLS avec des certificats Let's Encrypt et relaie les requêtes vers ''cahute'' et vers Home Assistant.
-| Kanidm      | Source de vérité : comptes, groupes     | LAN interne         | ~50 Mo      |
-| Authelia    | SSO web, règles d'accès par groupe      | LAN interne :9091   | ~50 Mo      |
-**Flux d'authentification :**
+Les vhosts d'administration (''ldap'', ''surveillance'', ''status'', ''logs'') sont protégés par un filtre ''remote_ip'' : toute source hors LAN1, LAN2 et VPN reçoit un 403. Le filtre porte sur l'adresse réelle de la connexion TCP et non sur un en-tête, il n'est donc pas falsifiable. Ces vhosts utilisent ''tls internal'' : ils n'ont pas de certificat public et n'apparaissent pas dans les journaux de transparence des certificats.
-  * **Login système portable** : kanidm-unixd → Kanidm (cache local si offline)
+Le conteneur Caddy est cloisonné en sortie par des règles ''DOCKER-USER'' : sur les réseaux privés, il ne peut joindre que ses backends et le DNS. SSH n'est ouvert sur le proxy que depuis LAN1, LAN2 et le VPN.
-  * **Services web (navigateur)** : Caddy → forward_auth Authelia → Kanidm
-  * **Client Nextcloud desktop/mobile** : Nextcloud → LDAP → Kanidm directement
-  * **Changement de mot de passe** : interface web Kanidm → propagation au prochain sync
-**Gestion des droits :**
+==== Serveur principal ====
-  * Groupes définis dans Kanidm (ex. ''music_users'', ''wiki_editors'', ''admin'')
+  * **OS :** Debian Trixie (13)
-  * Règles d'accès par groupe dans le fichier de config Authelia (YAML statique)
+  * **Matériel :** AMD x86, 8 Go de RAM, 2 To en soft-RAID ''mdadm'' monté sur ''/mnt/stockage''
-  * Modification des droits → édition YAML + redémarrage Authelia
+  * **Interface :** ''enp3s0'', adresse ''192.168.1.9'', sans IPv6 globale
+  * **Conteneurisation :** Docker CE et Docker Compose ; composes et données sous ''/mnt/stockage/docker''
-==== Services applicatifs ====
+''cahute'' n'a pas d'adresse IPv6 globale. Les règles UFW marquées « v6 » n'exposent donc rien à Internet.
-^ Service     ^ Rôle                    ^ Auth                            ^ Exposition     ^
+===== Services en bare-metal =====
-| Nextcloud   | Stockage et sync fichiers | LDAP → Kanidm + Authelia devant | Port interne → Caddy |
-| Blog        | Site web                  | Authelia devant                 | Port interne → Caddy |
-| DokuWiki    | Wiki                      | Authelia devant                 | Port interne → Caddy |
-| Ampache     | Streaming musical         | Authelia devant                 | Port interne → Caddy |
-| MariaDB     | Base de données           | Réseau Docker interne uniquement | Non exposé    |
-**Nextcloud — deux chemins d'auth :**
+^ Service ^ Rôle ^ Port ^ Accès ^
+| Apache | Nextcloud, DokuWiki, Ampache, blog, dav | 443 | Publié par Caddy |
+| Gitea | Forge Git | 3000 | Publié par Caddy |
+| Gitea, SSH intégré | Accès Git par SSH | 8329 | Toute source (UFW) |
+| MariaDB | Base de données des applications | local | Non exposé |
+| NFS | Partages et dossiers personnels | 2049/tcp | Plage /26 et VPN |
+| Samba | Présent, non ouvert dans UFW | — | Aucun |
+| Cockpit | Système, RAID, journaux, terminal web | 9090 | Plage /26 et LAN2 |
+| sssd | Résolution des identités LLDAP pour NFS | — | Local |
-  - Navigateur web : Authelia intercepte, puis Nextcloud vérifie aussi via LDAP/Kanidm
+Le port 8329 est le seul port de ''cahute'' que son UFW accepte depuis toute source. Le serveur SSH intégré à Gitea n'accepte que l'authentification par clé publique, pour des clés enregistrées dans un compte Gitea, et ne donne pas de shell. L'inscription est fermée (''DISABLE_REGISTRATION = true'') et la consultation exige une connexion (''REQUIRE_SIGNIN_VIEW = true'').
-  - Clients desktop/mobile : Nextcloud → LDAP → Kanidm directement (pas via Authelia)
-==== Surveillance et sécurité ====
+===== Services Docker =====
-^ Outil        ^ Rôle                                 ^ Accès         ^ RAM estimée ^
+^ Conteneur ^ Rôle ^ Port publié ^ Sources autorisées ^
-| Cockpit      | Système, RAID, journaux, terminal web | LAN :9090     | bare-metal  |
+| lldap | Annuaire LDAP : comptes et groupes | 17170 (interface web) | Proxy uniquement |
-| Uptime Kuma  | Disponibilité des services, alertes   | LAN interne   | ~50 Mo      |
+| lldap | LDAPS | 6360 | LAN1, LAN2, VPN |
-| Dozzle       | Logs Docker en temps réel             | LAN interne   | ~10 Mo      |
+| lldap | LDAP en clair | 3890 | Aucune depuis le réseau |
-| Homepage     | Page d'accueil unifiée, liens, statuts | LAN interne  | ~20 Mo      |
+| uptime-kuma | Disponibilité des services, alertes | 3001 | Proxy uniquement |
-| CrowdSec     | Détection intrusions, brute force     | LAN interne   | ~100 Mo     |
+| homepage | Page d'accueil, liens, statuts | 3002 | Proxy uniquement |
-| AIDE         | Intégrité des fichiers système        | Passif        | négligeable |
+| dozzle | Logs Docker en temps réel, avec authentification | 8888 | Proxy uniquement |
+| diun | Signalement des nouvelles versions d'images | aucun | — |
+| imaginary | Génération d'aperçus pour Nextcloud | 127.0.0.1:9000 | Local |
-===== Portables (×4) =====
+Les ports sont publiés sur ''192.168.1.9'' et non sur ''0.0.0.0''. Docker applique un DNAT avant les chaînes d'UFW : les règles ''ufw allow'' et ''ufw deny'' n'ont aucun effet sur ces ports. Le filtrage se fait dans la chaîne ''DOCKER-USER'', par le bloc ''DOCKER INGRESS'' de ''/etc/ufw/after.rules''. Les règles y filtrent sur le port publié d'origine (''--ctorigdstport''), car à ce stade le paquet porte déjà le port interne du conteneur.
-Chaque portable dispose de :
+Deux conséquences découlent de ce bloc. Un nouveau conteneur qui publie un port est bloqué par défaut tant qu'aucune règle n'y est ajoutée. Les processus locaux de ''cahute'' ne sont pas concernés, parce que leur trafic vers un port publié ne traverse pas la chaîne FORWARD : c'est ce qui permet au port 3890 de rester utilisable en local tout en étant fermé au réseau.
-  * ''kanidm-unixd'' : daemon de cache credentials, authentification PAM
+===== Authentification =====
-  * **Home local** sur le disque du portable (pas de NFS)
-  * Au moins un login réseau réussi requis pour initialiser le cache offline
-**Mode offline** : après le premier login, kanidm-unixd maintient un cache chiffré local. L'authentification fonctionne sans réseau. En cas de changement de mot de passe hors réseau, la resynchronisation se fait au prochain contact avec le serveur.
+LLDAP est la source unique des comptes et des groupes. Kanidm, prévu à l'origine, a été abandonné parce que son mode offline ne fonctionnait pas. Les UID sont forcés de 1000 à 1003, et les groupes sont ''partage'' (GID 301), ''famille'' (GID 302) et ''multimedia''.
-**Exposition Kanidm vers l'extérieur** : pour provisionner un nouveau portable hors LAN, Kanidm doit être accessible depuis Internet via Caddy sur un sous-domaine dédié, avec MFA activé (TOTP ou passkey).
+Sur les postes fixes et les portables, ''sssd'' interroge LLDAP en LDAPS sur le port 6360, avec un compte de bind en lecture seule dont le mot de passe est stocké dans ''sssd.conf'' (droits 600). Sur ''cahute'', ''sssd'' tourne en mode NSS seul et résout les mêmes identités, ce qui permet au serveur NFS d'appliquer les groupes LLDAP aux partages.
-===== Stockage =====
+L'interface web de LLDAP est publiée par Caddy sur le vhost ''ldap'', réservé aux réseaux internes.
-  * Soft-RAID ''mdadm'' sur le serveur principal, 2 To
+===== Partages NFS =====
-  * Toutes les données persistantes (fichiers Nextcloud, base MariaDB, musique Ampache) sont montées via **bind mounts** ou **volumes nommés** vers le RAID
-  * Les données ne vivent jamais dans les couches des conteneurs Docker
-  * Fichiers réseau (Samba/NFS) : hors Docker, accessibles uniquement sur le LAN1
-===== Plan de déploiement par étapes =====
+''cahute'' exporte cinq arborescences en NFS 4.2 sur TCP : ''/export/famille'', ''/export/multimedia'', ''/export/partage'', ''/export/home/beatrice'' et ''/export/home/francois''. Chaque export est ouvert à la plage ''192.168.1.0/26'' et au VPN ''10.1.100.0/24'', avec les options ''rw,secure,root_squash,no_subtree_check''.
-Principe : chaque étape est fonctionnelle et stable avant de passer à la suivante. Retour arrière possible à tout moment.
+L'authentification est en ''sec=sys'' : le serveur fait confiance à l'UID annoncé par le client. L'option ''secure'' impose un port source inférieur à 1024, ce qui réserve le montage au root du client et empêche un processus utilisateur de forger un UID. L'option ''root_squash'' ramène le root distant à ''nobody''. Un root sur un poste de la zone de confiance peut en revanche se présenter sous n'importe quel UID ordinaire ; seul Kerberos fermerait cette possibilité.
-==== Étape 1 — Socle de surveillance ====
+NFS 4 n'utilise que le port 2049 en TCP. Le port 111 (rpcbind) et le 2049 en UDP sont fermés dans UFW.
-**Objectif :** avoir de la visibilité sur le serveur avant de toucher aux services.
+LAN2 ne figure pas dans les exports : un portable accède aux partages par le VPN.
-  - Installer Cockpit en bare-metal (''apt install cockpit'')
+===== Portables =====
-  - Déployer Dozzle (logs Docker)
-  - Déployer Uptime Kuma (surveillance services)
-  - Déployer Homepage (page d'accueil)
-  - Vérifier l'état du RAID via Cockpit
-**Risque :** quasi nul — outils de lecture uniquement, aucun impact sur l'existant.
+Les portables sont exclusivement en WiFi. Leur home est local, et ''sssd'' garde un cache des identifiants sans expiration (''cache_credentials = True'', ''offline_credentials_expiration = 0'') : l'ouverture de session fonctionne sans réseau. Chaque portable porte une clé WireGuard, seul chemin vers les partages NFS, à la maison comme à l'extérieur. Depuis LAN2, un portable atteint LDAPS, Cockpit, le SSH du proxy et les vhosts publiés par Caddy.
-==== Étape 2 — Services applicatifs ====
+===== Stockage =====
-**Objectif :** migrer les services actuels (bare-metal) vers Docker, un par un.
+Les données vivent sur le soft-RAID ''mdadm'' de 2 To, monté sur ''/mnt/stockage''. Les partages NFS y sont rangés, ainsi que les composes et les données persistantes des conteneurs, sous ''/mnt/stockage/docker''. Aucune donnée ne vit dans les couches des images Docker.
-Ordre recommandé (du moins critique au plus critique) :
-  - DokuWiki (pas de base de données, migration simple)
-  - Blog (selon stack : WordPress ou statique)
-  - MariaDB (conteneurisation de la base, snapshot avant migration)
-  - Nextcloud (le plus complexe : permissions, config, clients existants)
-  - Ampache (dépend du volume de fichiers musique à monter)
-**Règle :** conserver l'ancien service bare-metal actif jusqu'à validation complète du conteneur.
-**Risque :** moyen — planifier une fenêtre de maintenance par service.
-==== Étape 3 — Authentification centralisée (Kanidm) ====
-**Objectif :** déployer Kanidm et connecter les portables, sans toucher aux services web.
-  - Déployer Kanidm en conteneur
-  - Créer les 4 comptes et les groupes
-  - Installer ''kanidm-unixd'' sur chaque portable
-  - Tester le login système + cache offline (couper le réseau et vérifier)
-  - Connecter Nextcloud en LDAP vers Kanidm
-**Risque :** moyen — tester le fallback offline avant de valider. Garder les comptes locaux sur les portables en parallèle pendant la période de test.
-==== Étape 4 — SSO web (Authelia) ====
-**Objectif :** protéger tous les services web derrière un portail de login unique.
-  - Déployer Authelia
-  - Configurer ''forward_auth'' sur Caddy (côté proxy)
-  - Définir les règles d'accès par groupe dans le YAML Authelia
-  - Tester service par service (DokuWiki en premier, Nextcloud en dernier)
-**Risque :** moyen à élevé — une mauvaise config Authelia peut bloquer l'accès à tous les services. Prévoir un accès de secours direct (bypass temporaire sur une IP LAN fixe).
-==== Étape 5 — Sécurité (optionnel) ====
-**Objectif :** renforcer la détection d'intrusions sans surcharger le serveur.
-  - Déployer CrowdSec (analyse logs Caddy, SSH, Nextcloud)
-  - Installer AIDE (intégrité fichiers système)
-  - Configurer les alertes (mail ou webhook)
-**Risque :** faible — outils passifs ou bloquants uniquement sur les IPs malveillantes connues.
-===== Estimation ressources =====
-^ Service          ^ RAM estimée ^
-| Nextcloud        | 200–400 Mo  |
-| MariaDB          | 200–400 Mo  |
-| Ampache          | 100–200 Mo  |
-| Blog             | 50–100 Mo   |
-| DokuWiki         | 50 Mo       |
-| Kanidm           | 50 Mo       |
-| Authelia         | 50 Mo       |
-| Uptime Kuma      | 50 Mo       |
-| Dozzle           | 10 Mo       |
-| CrowdSec         | 100 Mo      |
-| Homepage         | 20 Mo       |
-| **Total estimé** | **~900 Mo – 1,4 Go** |
-Marge disponible sur 8 Go : confortable. Surveiller MariaDB et Nextcloud en charge réelle.
 ===== Principes de sécurité =====
-  * MariaDB n'est jamais exposé hors du réseau Docker interne
+  * Le web n'entre depuis Internet que par le proxy. Sur ''cahute'', seul le SSH de Gitea (8329) accepte toute source, par clé uniquement.
-  * Cockpit accessible uniquement depuis le LAN (port 9090 bloqué au routeur)
+  * Le proxy, seule machine exposée en HTTP, est traité comme non fiable : son conteneur est cloisonné en sortie, et ''cahute'' lui refuse NFS, rpcbind, SSH et Cockpit.
-  * Kanidm exposé vers Internet uniquement pour le provisionnement des portables, avec MFA obligatoire
+  * Les ports des conteneurs de ''cahute'' sont filtrés dans ''DOCKER-USER'', parce qu'UFW ne les voit pas.
-  * Les fichiers réseau (Samba/NFS) restent hors Docker, LAN1 uniquement
+  * Les interfaces d'administration ne sont servies qu'aux réseaux internes, par le filtre ''remote_ip'' de Caddy en premier rideau et par l'authentification propre à chaque outil en second. Homepage n'a pas d'authentification propre.
-  * LAN2 wifi isolé : aucun accès direct au serveur principal
+  * MariaDB n'écoute qu'en local.
+  * LDAP ne circule sur le réseau qu'en LDAPS.