Architecture complète du serveur

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 ».

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.

Internet
    |  443                             |  8329 (SSH Gitea)      |  WireGuard (UDP)
    v                                  |                        v
[ Routeur OpenWrt .90 ] ── DNS local, DHCP, VPN 10.1.100.0/24, LAN2 WiFi 192.168.115.0/24
    |                                  |
    v  LAN1 192.168.1.0/24             |
[ proxyhttp .25 — Caddy ]              |
    |  TLS Let's Encrypt, reverse proxy, filtre remote_ip sur les vhosts d'admin
    v  ports autorisés uniquement      v
[ cahute .9 — serveur principal ]
    |── Bare-metal : Apache (Nextcloud, DokuWiki, Ampache, blog, dav) · Gitea · MariaDB
    |                NFS 4.2 · Cockpit · sssd
    |── Docker     : LLDAP · Uptime-Kuma · Homepage · Dozzle · Diun · imaginary
    └── Stockage   : soft-RAID mdadm 2 To (/mnt/stockage)

[ homeassistant .67 ]  Raspberry Pi 5, Home Assistant, publié par Caddy

[ 2 PC tour LAN1 ]     sssd → LLDAP (LDAPS) · partages en NFS 4.2
[ Portables ]          WiFi · sssd → LLDAP (LDAPS, cache offline) · home local · NFS par le VPN

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.

Home Assistant (.67) est hors de la plage /26 : il n'a accès à aucun de ces services.

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.

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.

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.

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.

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.

• OS : Debian Trixie (13)
• Matériel : AMD x86, 8 Go de RAM, 2 To en soft-RAID mdadm monté sur /mnt/stockage
• Interface : enp3s0, adresse 192.168.1.9, sans IPv6 globale
• Conteneurisation : Docker CE et Docker Compose ; composes et données sous /mnt/stockage/docker

cahute n'a pas d'adresse IPv6 globale. Les règles UFW marquées « v6 » n'exposent donc rien à Internet.

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).

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.

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.

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.

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.

L'interface web de LLDAP est publiée par Caddy sur le vhost ldap, réservé aux réseaux internes.

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.

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é.

NFS 4 n'utilise que le port 2049 en TCP. Le port 111 (rpcbind) et le 2049 en UDP sont fermés dans UFW.

LAN2 ne figure pas dans les exports : un portable accède aux partages par le VPN.

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.

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.

• Le web n'entre depuis Internet que par le proxy. Sur cahute, seul le SSH de Gitea (8329) accepte toute source, par clé uniquement.
• 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.
• Les ports des conteneurs de cahute sont filtrés dans DOCKER-USER, parce qu'UFW ne les voit pas.
• 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.
• MariaDB n'écoute qu'en local.
• LDAP ne circule sur le réseau qu'en LDAPS.