Réseau

État actuel du réseau homelab : topologie, adressage, DNS, VPN mesh et certificats TLS.

Par où passe une requête ?

Cette page décrit l'adressage. Pour savoir quel chemin emprunte un accès — depuis le LAN, depuis le tailnet, ou par le Funnel public — voir Accès aux services.

Topologie actuelle

Réseau plat 192.168.1.0/24 derriere une Freebox (gateway 192.168.1.254). Pas de VLANs pour l'instant — la segmentation est prévue dans l'architecture cible. L'acces distant est assure par un mesh VPN Tailscale (WireGuard) superpose au LAN. Il n'y a aucun port forwarde sur la Freebox — tout le trafic inter-devices distant passe par le tunnel WireGuard.

Schéma agrandi

100 %

Machines et adresses

Hostname	Type	Rôle	IP LAN	IP Tailscale
penny (homelab)	RPi 4 (DietPi)	Serveur principal (Docker, Traefik, AdGuard)	192.168.1.28	100.97.239.90
galahad	ZimaBoard (Proxmox)	Hyperviseur (LXC vault + dns-failover)	192.168.1.18	100.98.58.121
lancelot	ZimaBoard (Proxmox)	Hyperviseur (LXC logs)	192.168.1.19	100.69.6.13
dns-failover	LXC 100 (sur galahad)	AdGuard secondaire + healthcheck	192.168.1.30	100.74.145.26
vault	LXC 102 (sur galahad)	Vaultwarden	192.168.1.32	—
logs	LXC 101 (sur lancelot)	Loki + Grafana	192.168.1.31	—
iphone175	iOS	Mobile	—	100.84.188.65
macbook-pro-de-gabin	macOS	Laptop	—	100.68.165.36
a00783	Windows	Desktop	—	100.64.114.40

Les LXC logs (101, sur lancelot) et vault (102, sur galahad) ne sont pas sur Tailscale — accessibles via l'IP LAN de leur host uniquement.

DNS (AdGuard Home)

Architecture DNS

Schéma agrandi

100 %

Les DNS rewrites (la pièce clé)

AdGuard Home utilisé une règle de reecriture conditionnelle dans user_rules pour rediriger les domaines internes vers le RPi sans passer par Internet. Tous les clients (LAN, bridges Docker, Tailscale) résolvent *.home.gabin-simond.fr vers l'IP LAN de penny 192.168.1.28, où écoute Traefik :

||home.gabin-simond.fr^$dnsrewrite=192.168.1.28,client=192.168.1.0/24|172.16.0.0/12|100.64.0.0/10

Client vu par AdGuard	Réponse DNS	Comment il atteint 192.168.1.28
LAN (192.168.1.0/24), Docker (172.16/12)	192.168.1.28	directement sur le LAN
Tailscale (100.64.0.0/10)	192.168.1.28	via route subnet 192.168.1.28/32 advertisée par penny (approuvée console)

Comment les clients VPN atteignent Traefik

Un client Tailscale distant n'est pas sur le LAN. Il atteint 192.168.1.28:443 (Traefik) parce que penny advertise la route subnet 192.168.1.28/32 sur le tailnet (tailscale set --advertise-routes=192.168.1.28/32, approuvée dans la console). Le trafic VPN vers cette IP est routé jusqu'à penny.

Nœuds tailnet RÉSIDENTS du LAN : accept-routes doit rester false

Un nœud Tailscale qui est lui-même sur le LAN 192.168.1.0/24 (cas vécu avec sucre/LXC 105, détruit depuis) et qui a accept-routes: true va router 192.168.1.28 via Tailscale au lieu du LAN direct. Conséquence : quand penny initie vers ce nœud (ssh, ping, health Homepage), le nœud répond via Tailscale → routage asymétrique → le rp_filter de penny droppe la réponse → 100% packet loss (sens penny→nœud uniquement). Vécu 2026-06-25 sur sucre. Fix : tailscale set --accept-routes=false sur les nœuds LAN-résidents (ils joignent penny en direct, ils n'ont pas besoin d'accepter la route). Diagnostic : ip route get 192.168.1.28 sur le nœud doit montrer dev eth0, pas dev tailscale0. galahad/lancelot/dns-failover ne sont pas concernés (pas d'accept-routes).

Ne PAS renvoyer les clients Tailscale vers l'IP Tailscale de penny

Tentation naturelle : client=100.64.0.0/10 → 100.97.239.90 (l'IP Tailscale). Ça casse en TLS : SSL_ERROR_INTERNAL_ERROR_ALERT (alert 80). Raison : l'IP Tailscale:443 de penny est tenue par le Funnel Tailscale (→ ntfy 127.0.0.1:8090), qui n'a de cert que pour penny.tail*.ts.net — pas pour home.*. Traefik ne bind QUE 192.168.1.28 + 127.0.0.1 (le Funnel squatte l'IP Tailscale:443, cf mémoire traefik-tailscale-443-conflict). Un SNI home.* arrivant sur l'IP Tailscale n'a donc aucun cert → abort handshake. Ce piège a été actif jusqu'au 2026-06-25 (corrigé via route subnet + rewrite → IP LAN).

Ne pas utiliser les DNS Rewrites statiques

La section DNS Rewrites d'AdGuard (Filters > DNS Rewrites) ne doit pas contenir d'entrees pour *.home.gabin-simond.fr. Les rewrites statiques sont appliquees avant les user_rules et ne supportent pas le filtrage par client. Elles ecraseraient les règles conditionnelles ci-dessus, renvoyant toujours l'IP LAN, même aux clients Tailscale — rendant les services inaccessibles via VPN.

Seule exception : switch.lan → 192.168.1.2 (équipement HTTP-only, hors du domaine home.* pour éviter le HSTS).

AdGuard en network_mode: host

AdGuard tourne avec network_mode: host — il voit les vraies IPs clients (LAN et Tailscale), pas l'IP du bridge Docker.

Avantages :

• 2 règles DNS au lieu de 4 — plus de bricolage avec le bridge Docker
• Stats par client dans AdGuard — on voit quel device fait quelles requêtes
• Reverse proxy toujours actif via Traefik file provider (dynamic/dns.yml)

Wildcard home.gabin-simond.fr

La règle utilisé ||home.gabin-simond.fr^ — c'est un wildcard. Ca matche :

• home.gabin-simond.fr
• traefik.home.gabin-simond.fr
• adguard.home.gabin-simond.fr
• monservice.home.gabin-simond.fr
• ... tout sous-domaine de home.gabin-simond.fr

Résultat : pas besoin d'ajouter une règle DNS par service. Tout nouveau service avec un sous-domaine *.home.gabin-simond.fr est automatiquement redirige.

Flow complet d'une requête

Depuis le LAN

1. Navigateur → adguard.home.gabin-simond.fr ?
2. AdGuard → rewrite → 192.168.1.28 (regle client=192.168.1.0/24)
3. Navigateur → HTTPS 192.168.1.28:443
4. Traefik → match Host header → forward vers container adguard:3000
5. Reponse ← chiffree TLS (certificat Let's Encrypt)

Depuis Tailscale (distant)

1. Navigateur → adguard.home.gabin-simond.fr ?
2. DNS → resolution publique ou AdGuard via Tailscale
3. Navigateur → HTTPS 100.97.239.90:443 (via tunnel Tailscale)
4. Traefik → match Host header → forward vers container adguard:3000
5. Reponse ← chiffree TLS

DNS upstream

Pour les domaines non locaux (tout sauf *.home.gabin-simond.fr), AdGuard forward vers :

Upstream	Protocole	Adresse
Quad9	DNS-over-HTTPS	https://dns10.quad9.net/dns-query

Bootstrap DNS (pour résoudre dns10.quad9.net lui-même) :

• 9.9.9.10
• 149.112.112.10

Mode : load balance entre les upstreams.

Tailscale

Tailnet

Tailnet	tail8850a4.ts.net
Magic DNS	Actif
HTTPS certs	Actif (cert .ts.net automatique)

Le VPN mesh Tailscale est géré depuis login.tailscale.com.

Tailscale SSH

Mode check (MFA navigateur a chaque connexion) activé sur homelab (penny), galahad, lancelot. Aucun port 22 exposé sur aucun host.

ssh gabins@homelab    # penny via MagicDNS Tailscale
ssh gabins@galahad    # ZimaBoard #1
ssh gabins@lancelot   # ZimaBoard #2

Fallback OpenSSH dispo sur les 3 hosts (ports 2806/2807/2808), clé Ed25519 uniquement.

Politique ACL

La configuration ACL exacte vit dans la console Tailscale et est versionnee par Tailscale (pas dans ce repo). Résumé de la politique :

Groupes

Groupe	Membres
group:admin	[email protected] (proprietaire tailnet)

Pas de compte multi-utilisateur pour l'instant (homelab personnel).

Tags

Tag	Usage
tag:homelab	penny
tag:proxmox	galahad + lancelot
tag:lxc	dns-failover (et futurs LXCs sur Tailscale)
tag:client	iphone, macbook, desktop

Règles d'acces (principe)

• group:admin : acces complet a tous les tags.
• tag:client : acces aux services homelab (ports 80, 443, 53, 3000, 8006) mais pas SSH (sauf via Tailscale SSH).
• tag:homelab / tag:proxmox / tag:lxc : pas d'init d'appels sortants hors du tailnet (serveurs passifs).

SSH ACL

{
  "sshRules": [
    {
      "action": "check",  // MFA navigateur
      "src": ["group:admin"],
      "dst": ["tag:homelab", "tag:proxmox"],
      "users": ["gabins", "root"]
    }
  ]
}

Revocation

Procédure en cas de vol / perte / compromission d'un device :

1. login.tailscale.com > Machines
2. Sélectionner le device > Disable (acces coupe immédiatement)
3. Si perdu definitivement : Remove
4. Rotation globale clés : Settings > Keys > Auth keys > Revoke
5. Les autres devices doivent re-authentifier (sauf ceux avec key expiry disabled)

Voir aussi la politique de sécurité dans politique.md et les mesures de hardening dans hardening.md.

Key expiry

Désactivé sur les serveurs (homelab, dns-failover, galahad, lancelot) pour éviter qu'un serveur headless perde l'acces mesh sans intervention humaine. Les clients (iphone, macbook, desktop) gardent l'expiry par defaut (180 jours) + re-auth interactive.

Commandes utiles

tailscale status            # liste machines et connectivite
tailscale whois <IP>        # qui est connecte sur cette IP
tailscale ping <host>       # ping direct ou relay via DERP
tailscale up --ssh          # reactiver Tailscale SSH si coupe
tailscale netcheck          # diagnostics NAT / DERP

TLS / Certificats

Traefik géré automatiquement les certificats TLS via Let's Encrypt avec le DNS challenge Cloudflare.

Schéma agrandi

100 %

Pourquoi le DNS challenge ?

• Pas besoin d'exposer le port 80 sur Internet
• Fonctionne pour des domaines internes (pas accessibles depuis Internet)
• Cloudflare géré la zone DNS gabin-simond.fr
• Traefik utilisé le token API Cloudflare (CF_DNS_API_TOKEN) pour créer/supprimer les records TXT automatiquement