Retour aux projets

Étude de cas · projet personnel

Mon homelab : trois sites reliés par VPN

Depuis 2022 · seul, de la conception à l'exploitation · moins de dix utilisateurs

Chez moi, un serveur TrueNAS stocke mes données et fait tourner une vingtaine de services dans Docker. Deux autres lieux y sont reliés par un VPN WireGuard : un mini-PC Proxmox qui diffuse la médiathèque, et une petite VM Linux sur une box.

Pourquoi j'héberge mes services moi-même

Tout est parti de besoins précis, auxquels aucun service ne répondait, ou alors très cher. En cherchant, j'ai découvert les logiciels libres et l'auto-hébergement, puis je me suis intéressé à la protection des données et à la souveraineté numérique. Je préfère que mes photos, mes mots de passe et mes conversations restent chez moi : j'héberge donc ce que j'utilise au quotidien.

  • messagerie et appels (Matrix)
  • photos (Immich)
  • mots de passe, passkeys et TOTP (Vaultwarden)
  • fichiers et bureautique (Nextcloud)
  • domotique (Home Assistant)
  • DNS filtrant (AdGuard Home)
  • VPN (WireGuard, Headscale)
  • automatisations (n8n)

Architecture

Site principal

Serveur TrueNAS SCALE

  • Ancienne tour HP, Intel Core i3, 32 Go de RAM
  • Deux disques de 4 To en miroir (RAID 1) et services Docker
  • Reverse proxy HTTPS et SSO
  • DNS filtrant privé, commun aux trois sites
  • Coordination du VPN

Site distant n°1

Mini-PC sous Proxmox

  • VM Docker : Jellyfin (diffusion et transcodage), médiathèque partagée par le NAS en NFS à travers le VPN
  • Flux RTSP d'une caméra converti pour HomeKit (Scrypted)
  • VM Home Assistant : domotique du site
  • VM sauvegardées sur le NAS principal

Site distant n°2

VM Linux sur la box

  • Relie ce réseau local au mien, dans les deux sens (Tailscale)
  • Utilise le DNS commun, à travers le VPN
  • Accès aux services sans client VPN

VPN maillé WireGuard · clients Tailscale, serveur de coordination Headscale auto-hébergé

Je ne publie ni adresses ni noms d'hôtes : c'est voulu.
Extrait du tableau de bord du homelab : TrueNAS SCALE (charge, durée de fonctionnement, 0 alerte), AdGuard Home, What's Up Docker (32 conteneurs, 0 mise à jour), Nginx Proxy Manager, WireGuard, Pocket ID, Home Assistant et Homebridge. (agrandir l'image)
Extrait de mon tableau de bord (Homepage) : état du serveur TrueNAS, services d'infrastructure et de domotique.

Sécurité et exploitation

Qui accède à quoi

  • Mots de passe, NAS, photos et domotique ne sont accessibles qu'en local ou par VPN.
  • Les services publiés passent par un reverse proxy HTTPS (Nginx Proxy Manager), avec authentification unique par passkeys (Pocket-ID) pour ceux qui la gèrent.
  • Les partages NFS sont limités à l'adresse VPN de la seule machine autorisée.

Comment je surveille

  • Netdata supervise les serveurs et envoie les alertes critiques sur Telegram.
  • Chaque dimanche, un scrub ZFS et un test SMART long vérifient les disques.
  • Les nouvelles versions des conteneurs sont détectées automatiquement.
  • Un workflow n8n m'envoie par SMS (API Free Mobile) les alertes urgentes et les réponses au formulaire de contact de ce site.

Deux problèmes, de la panne à la solution

Un appel « réussi » qui passait en fait par le VPN

Je voulais une messagerie « comme iMessage » (photos, vidéos, vocaux), avec des appels de groupe à 4 ou 5, pour moins de dix proches et avec 4 à 5 Go de RAM disponibles sur le NAS. J'ai comparé Matrix à cinq autres solutions, puis déployé Synapse, PostgreSQL et LiveKit en Docker Compose sur le TrueNAS, avec un dataset ZFS par composant.

Premier piège : mon appel de test « réussi » passait en fait par le VPN, comme le montraient les journaux de LiveKit. Je l'ai refait en 4G, VPN et Wi-Fi coupés, pour vérifier que le chemin public fonctionnait vraiment.

Côté sécurité, la fédération et les inscriptions sont fermées, et l'API d'administration est bloquée depuis Internet. J'ai remplacé l'interface d'administration web par la ligne de commande en SSH : un service et un port exposé en moins. Avant de migrer l'authentification vers MAS (OIDC), j'ai pris un instantané ZFS et une sauvegarde de la base : 10 contrôles sur 10 au vert, comptes et messages conservés.

Résultat : des appels vidéo chiffrés de bout en bout, pour moins de 300 Mo de RAM pendant un appel. Encore ouvert : le son ne passe pas entre deux mobiles hors du réseau local, une capture réseau est prévue.

Ce que j'en retiens : un test qui marche ne prouve rien tant qu'on n'a pas vérifié par où passe le trafic.

La carte réseau qui lâchait pendant le transcodage

J'ai confié le GPU du mini-PC à la VM multimédia (passthrough) pour le transcodage. Dès que le transcodage tournait en continu, la carte réseau Intel se bloquait et la machine devenait injoignable.

J'ai d'abord désactivé la gestion d'énergie PCIe (ASPM) et ajouté un script, lancé chaque minute par cron, qui relançait l'interface en cas de blocage. Il s'est déclenché trois fois en moins d'une heure : à chaque fois, le réseau revenait puis retombait 20 à 25 minutes plus tard.

J'ai alors vérifié que la carte et le GPU étaient dans des groupes IOMMU différents, puis épinglé leurs interruptions sur deux cœurs distincts (service systemd) et désactivé l'Energy Efficient Ethernet de la carte.

Résultat : une nuit complète de transcodage sans blocage.

Limite : j'ai épinglé les interruptions et désactivé l'Energy Efficient Ethernet en même temps, donc je ne sais pas lequel des deux a réglé le problème.

Prochaines étapes

  • Une copie hors site de mes propres données : la synchronisation vers un stockage cloud échoue aujourd'hui sur une limite de quota.
  • Des sauvegardes planifiées de la base de Matrix.
  • Le son des appels entre mobiles hors du réseau local.
  • Une supervision de la sécurité : collecte des journaux et détection d'intrusion.

Compétences mobilisées

Retour aux projets