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 pièges connus.

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 doivent donc systématiquement couvrir cette zone, sinon les portables perdent l'accès (web, LDAPS, partages).

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://router.beafrancois.fr ou https://192.168.1.90:8443 (déplacé de 443 vers 8443)
• 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 doit écouter sur l'interface du tunnel (wg1) pour que la résolution fonctionne depuis le VPN.

Machine dédiée (NUC), hostname proxyhttp. 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. Situation actuelle :

• Sous Docker : LLDAP, stack surveillance (Dozzle, Uptime-Kuma, Homepage) — et Caddy sur le proxy .25
• Encore en bare-metal : Apache (vhosts web, :443), Nextcloud, DokuWiki, Blog, Ampache, Gitea, MariaDB, Cockpit, NFS

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).
• Symptôme typique en cas de besoin d'accès direct : « ça pingue, mais la connexion est refusée ». Correctif : sudo ufw allow from 192.168.1.67 to any port <port>, ou élargir la règle concernée en /24.

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

Points à retenir :

• 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). À durcir si possible (clés uniquement, fail2ban).
• 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.

Correctif à mettre en place : ufw-docker (règles dans la chaîne DOCKER-USER). À faire en session dédiée : ré-autoriser explicitement LLDAP (6360) en priorité, sinon toute l'authentification du parc casse. Garder un compte local de secours.

• 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. À vérifier pour tout nouvel équipement filaire, et à surveiller si le DHCP distribue dans la plage haute.
• Redirection 443 par zone — une règle limitée à src=wan casse l'accès web interne. Prévoir aussi lan et invite.
• Admin OpenWrt sur 443 — entrait en conflit avec la redirection ; déplacé sur 8443.
• Pas de wildcard DNS /beafrancois.fr/… — casserait Gitea SSH (un nom ne peut pas résoudre vers deux IP selon le protocole). Déclarer chaque service.
• dnsmasq et le VPN — sans écoute sur wg1 (et localservice adapté), aucune résolution depuis le tunnel.
• 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.
• Caddy → routeur — router.beafrancois.fr résolu vers le proxy qui reverse-proxie vers le routeur : pas de boucle, ce sont deux machines distinctes.