Dernière mise à jour : juillet 2026

Vue d'ensemble de l'infrastructure, du général au particulier : segments réseau, machines, services, flux, puis détails de configuration et particularités connues.

Le LAN1 filaire porte l'infrastructure, deux PC tour et un Raspberry Pi 5. Les portables, eux, sont exclusivement en WiFi sur un segment séparé.

                          Internet
                             |
                             v
        +----------------------------------------------+
        |  ROUTEUR OpenWrt        192.168.1.90          |
        |  NAT · pare-feu · DNS local (dnsmasq)         |
        |  serveur WireGuard · admin LuCI :8443         |
        +----------------------------------------------+
           |                |                     |
   LAN1 filaire           WiFi              VPN WireGuard
  192.168.1.0/24    192.168.115.0/24        10.1.100.0/24
   (infra + fixes)     (portables)          (accès distant)
           |                |                     |
           |                +----------+----------+
           |                           |
   +-------+--------+-----------+      |
   |       |        |           |      |
   |  [2 PC tour]  [RPi5 « homeassistant »]
   |                                   |
   v                                   |
   +------------------+                |
   | PROXY Caddy .25  | <--------------+  (web des 3 segments)
   | TLS · reverse    |
   |  proxy · filtre  |      [Docker]
   +--------+---------+
            |  HTTP interne
            v
   +------------------------------------------+
   | SERVEUR « cahute »        192.168.1.9    |
   | Debian 13 · RAID 2 To                    |
   | UFW : accès restreint à 192.168.1.0/26   |
   |  - Auth      : LLDAP          [Docker]   |
   |  - Surveillance : Uptime-Kuma, Dozzle,   |
   |                   Homepage    [Docker]   |
   |  - Services  : Nextcloud, Wiki, Blog,    |
   |     Ampache, Gitea, MariaDB, Cockpit     |
   |                            [bare-metal]  |
   |  - Partages  : NFS / Samba [bare-metal]  |
   +------------------------------------------+
            ^
            |  WiFi  : sssd (LDAPS 6360) · web via proxy
            |  VPN   : partages NFS / Samba
   +------------------------------------------+
   | PORTABLES  (Debian GNOME, CachyOS…)      |
   | WiFi uniquement · home local             |
   | cache offline sssd · WireGuard pour les  |
   | partages                                 |
   +------------------------------------------+

⚠ Ne pas confondre : le LAN est bien un /24. Le 192.168.1.0/26 que l'on retrouve dans plusieurs règles n'est pas un masque réseau — c'est une plage d'autorisation UFW sur le serveur, qui limite l'accès aux adresses .1 à .62.

Le segment WiFi est déclaré comme zone invite côté OpenWrt : les règles de redirection et les autorisations UFW couvrent cette zone, d'où l'accès des portables au web et à LDAPS.

Client (LAN / wifi invité / VPN / Internet)
   |  résolution DNS : sous-domaine -> 192.168.1.25
   v
[ Routeur .90 ]   DNAT 443 -> .25   (règle par zone : wan, lan, invite)
   v
[ Caddy .25 ]     terminaison TLS (Let's Encrypt ou tls internal)
                  filtre @denied par remote_ip
   v
[ Serveur .9 ]    port applicatif interne (ex. 3001, 3002, 8888, 17170)

Portable (online)   --> sssd --> ldaps://auth.beafrancois.fr:6360 --> LLDAP (.9)
Portable (offline)  --> sssd --> cache local chiffré (sans expiration)
Navigateur          --> ldap.beafrancois.fr / auth.beafrancois.fr --> UI LLDAP
Serveur (NSS-only)  --> sssd --> LLDAP     (résolution UID/GID pour NFS)

Portable en WiFi      --X-- pas d'accès direct aux partages
Portable (WiFi ou 5G) --> tunnel WireGuard --> NFS / Samba --> /mnt/stockage (.9)

Les partages ne sont jamais montés directement depuis le segment WiFi : le tunnel WireGuard est le seul chemin, à la maison comme à l'extérieur.

Point d'entrée unique. Assure NAT, pare-feu de zones, DNS local et terminaison VPN.

• Admin web : https://aiguilleur.beafrancois.fr:8443 ou https://192.168.1.90:8443 (uhttpd déplacé de 443 vers 8443)
• ⚠ Le port est obligatoire. aiguilleur.beafrancois.fr résout directement vers le routeur (.90), et non vers le proxy. Sans le :8443, la requête part sur le 443 du routeur, qui est justement redirigé vers Caddy (.25) — lequel n'a pas de bloc pour ce nom.
• Nom : aiguilleur (anciennement router, qui ne résout plus)
• DNS : dnsmasq, entrées ciblées par sous-domaine (pas de wildcard)
• VPN : serveur WireGuard, interface wg1 (et wg0)

uci add_list dhcp.@dnsmasq[0].address='/nuage.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/wiki.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/blog.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/musique.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/surveillance.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/status.beafrancois.fr/192.168.1.25'
uci add_list dhcp.@dnsmasq[0].address='/logs.beafrancois.fr/192.168.1.25'
uci commit dhcp
/etc/init.d/dnsmasq restart

dnsmasq écoute sur l'interface du tunnel (wg1), ce qui permet la résolution depuis le VPN.

Machine physique dédiée (NUC), hostname proxyhttp — distincte du serveur principal. Seule machine exposée au trafic entrant 443.

• Terminaison TLS : Let's Encrypt pour les noms publics, tls internal (auto-signé) pour les noms internes
• Reverse proxy vers les ports applicatifs du serveur
• Restriction d'accès par IP source sur les services d'administration
• Projet dans /opt/proxy, Caddy lui-même en conteneur

surveillance.beafrancois.fr {
    @denied not remote_ip 192.168.1.0/24 192.168.115.0/24 10.1.100.0/24
    respond @denied 403
    tls internal
    reverse_proxy 192.168.1.9:3002
}

Rechargement : docker compose exec caddy caddy reload –config /etc/caddy/Caddyfile

• OS : Debian Trixie (13), kernel 6.x
• Matériel : AMD x86, 8 Go RAM, 2 To en soft-RAID mdadm
• Conteneurisation : Docker CE (dépôt officiel), Compose v2
• Stockage : /mnt/stockage (multimedia, famille, partage, homes, system, docker)
• Jamais exposé directement à Internet

La conteneurisation est partielle sur le serveur. Situation actuelle :

• Sous Docker : LLDAP, stack surveillance (Dozzle, Uptime-Kuma, Homepage)
• Encore en bare-metal : Apache (vhosts web, :443), Nextcloud, DokuWiki, Blog, Ampache, Gitea, MariaDB, Cockpit, NFS

Caddy, lui, ne tourne pas sur ce serveur : il est en conteneur sur la machine proxy dédiée (.25), voir §4.2.

Les dossiers compose/ et data/ des services restants sont déjà créés, mais les stacks ne sont pas déployées.

/mnt/stockage/docker/
├── compose/          ← un dossier par stack (lldap, surveillance, + à venir)
└── data/             ← données persistantes (bind mounts vers le RAID)

• Portables Linux (Debian/GNOME, CachyOS/Arch)
• Connexion en WiFi exclusivement (192.168.115.0/24)
• Authentification système via sssd sur LLDAP, cache_credentials = True, cache offline sans expiration (offline_credentials_expiration = 0)
• Home local sur chaque poste (pas de NFS) — condition du fonctionnement hors ligne
• WireGuard obligatoire pour les partages : les montages NFS/Samba ne passent que par le tunnel (10.1.100.0/24), y compris depuis le WiFi de la maison. Le client pousse DNS = 192.168.1.90

• Postes fixes raccordés en filaire sur le LAN1
• Adresses dans la plage .1–.62, donc couvertes par les règles UFW du serveur : accès direct aux services et aux partages, sans VPN

• Domotique, raccordé en filaire sur le LAN1
• ⚠ Son adresse (.67) est hors de la plage .1–.62 couverte par les règles UFW en /26. Le serveur lui refuse donc SSH (22), HTTPS (443), NFS (111/2048/2049/4045), Gitea (3000) et Cockpit (9090).
• Ce qui lui reste accessible : les services via le proxy Caddy (.25, machine distincte, dont le filtre autorise tout le 192.168.1.0/24), et LDAPS 6360 (règle en /24).
• Comportement observé depuis cette machine : le serveur répond au ping, mais refuse la connexion sur ces ports.

Le port 3000 est occupé par Gitea, d'où Homepage sur 3002. Le port 3890 (LDAP en clair) n'est pas ouvert au pare-feu : usage interne au serveur.

• Annuaire : LLDAP (conteneur Docker), remplace Kanidm (abandonné : offline cassé)
• Clients : sssd (PAM + NSS) sur les portables et sur le serveur (mode NSS-only, pour que NFS applique les identités LLDAP)
• Compte bind en lecture seule déclaré dans sssd.conf (permissions 600)
• UID forcés 1000–1003, groupes : partage (GID 301), famille (GID 302), multimedia
• Pas de Kerberos : la cohérence des UID/GID suffit pour NFS

• Le serveur n'est joignable depuis Internet que par l'intermédiaire du proxy — sauf le port 8329 (Gitea SSH), ouvert à tous
• MariaDB (3306) et le LDAP en clair (3890) ne sont pas ouverts
• Le WiFi est autorisé sur LDAPS (6360) et Cockpit (9090), pas sur NFS : les partages ne sont joignables que depuis le filaire .1–.62 ou par le VPN

Lecture de ces règles :

• NFS n'est pas ouvert au WiFi — ce qui confirme que les portables ne peuvent monter les partages que via WireGuard. Côté VPN, seul 2049/tcp est autorisé : cela suffit en NFSv4 (pas de portmapper), mais interdit NFSv3.
• Samba n'est pas ouvert (ni 445, ni 139). Les partages se font donc en NFS uniquement, malgré la présence du service.
• 6360 est en /24, contrairement aux autres règles en /26 : l'authentification reste donc possible depuis toute machine du LAN filaire, y compris au-delà de .62.
• 8329 est ouvert à Anywhere, IPv6 compris : c'est le SSH de Gitea, seule exposition directe du serveur à Internet (accès Git distant).
• Le 443 correspond à Apache, en bare-metal sur le serveur ; sa racine affiche encore la page par défaut. Le proxy (.25) étant dans la plage /26, il peut le joindre — c'est par là que passent les services web non conteneurisés.
• Les règles portant sur 17170, 6360, 3001, 3002 et 8888 visent des conteneurs Docker : elles sont inopérantes en l'état (voir ci-dessous).

Docker insère ses règles iptables (chaînes FORWARD / DOCKER) en amont d'UFW. Les règles ufw allow from 192.168.1.25 to any port … ne s'appliquent donc pas aux ports publiés par des conteneurs (LLDAP, Dozzle, Uptime-Kuma, Homepage). Constat vérifié : Dozzle (:8888, conteneur) reste joignable depuis le VPN, alors que Cockpit (:9090, bare-metal) est bien filtré.

Ce qui protège malgré tout : le binding sur 192.168.1.9 (et non 0.0.0.0), et le filtre par IP source de Caddy sur les sous-domaines.

ufw-docker (règles dans la chaîne DOCKER-USER) n'est pas installé.

• Le /26 n'est pas un sous-réseau — c'est une plage d'autorisation dans les règles UFW du serveur (ufw allow from 192.168.1.0/26 …), qui ne couvre que .1–.62. Toute machine du LAN adressée au-delà de .62 est silencieusement refusée par le serveur alors que le réseau, lui, fonctionne. Cas avéré : homeassistant en .67.
• Redirection 443 par zone — une règle limitée à src=wan casse l'accès web interne. Les zones lan et invite ont donc chacune leur règle.
• Admin OpenWrt sur 443 — entrait en conflit avec la redirection ; déplacé sur 8443.
• Pas de wildcard DNS /beafrancois.fr/… — un wildcard casserait Gitea SSH (un nom ne peut pas résoudre vers deux IP selon le protocole). Chaque service est donc déclaré individuellement.
• dnsmasq et le VPN — sans écoute sur wg1 (et localservice adapté), la résolution depuis le tunnel ne fonctionnait pas.
• HOMEPAGE_ALLOWED_HOSTS — Homepage rejette tout Host non listé (« Host validation failed »). Valeurs séparées par des virgules, sans espace.
• Bits spéciaux et NFSv4 — setuid/setgid sur les dossiers de partage bloquaient l'accès malgré l'appartenance au bon groupe. Corrigé par chmod -R a-s,a-t partage.
• Renommage router → aiguilleur — l'ancien nom ne résout plus du tout. Tout ce qui le référence est cassé : la sonde Ping « Routeur » d'Uptime-Kuma (hôte router), et l'éventuel bloc router.beafrancois.fr du Caddyfile, désormais orphelin. À l'époque, ce nom résolvait vers le proxy (.25) qui reverse-proxifiait vers le routeur (.90:8443) — sans boucle, ce sont deux machines distinctes. Le nouveau nom pointe directement vers .90, sans passer par Caddy.