Le Streaming est Cassé IV : La Forteresse : VPN et Gluetun :: doismiu

Nous avons le serveur et notre système d’exploitation installés et configurés. Avant de commencer à choisir les acteurs qui joueront les rôles principaux, faisons une pause pour nous concentrer sur les coulisses. Plus précisément, sur la vie privée. Que vous viviez dans un pays qui punit activement le piratage ou non, personne ne devrait savoir comment vous utilisez votre réseau local. La vie privée est importante !.

Si vous lancez un téléchargement torrent sur le serveur maintenant, votre véritable IP sera exposée au monde entier. De plus, les publicités, les traqueurs et les données de télémétrie circuleront librement sur votre réseau.

Nous devons mettre fin à cela.

Nous n’allons pas simplement “installer un VPN” ; nous allons concevoir une passerelle réseau sécurisée qui agit comme un Kill Switch physique et segmente votre trafic réseau pour garantir la vitesse là où c’est important et la confidentialité là où elle est vitale. Cela semble complexe, n’est-ce pas ? Vous verrez que ce n’est pas le cas. Vous pouvez parier dessus.

Le Concept de Passerelle Sidecar

L’approche amateur consiste à installer un VPN directement sur le système d’exploitation (l’hôte). C’est mauvais car cela chiffre tout (y compris votre accès SSH et votre streaming Jellyfin local), tuant, massacrant et écorchant les performances.

Ici, nous appliquerons le modèle Sidecar :

Nous créons un conteneur (Gluetun) dont la seule fonction est d’ouvrir un tunnel VPN sécurisé.
Les conteneurs “sensibles” (qBittorrent, Prowlarr, Arr-Stack) n’utilisent pas le réseau du serveur. Ils sont configurés avec network_mode: service:gluetun.
Ils s’accrochent à la connexion de Gluetun. Ils n’ont pas de sortie Internet propre.

L’Architecture Hybride : Sale vs. Propre

Comme vous l’avez peut-être remarqué dans le diagramme ci-dessus, et en pensant aux performances de notre CPU et de notre système, nous allons opter pour une approche cruciale : La Ségrégation Réseau. Nous diviserons notre réseau en deux groupes :

Le Groupe “Sale” (Tunnel VPN) :

Membres : qBittorrent, Prowlarr, Sonarr, Radarr.
Raison : Ils téléchargent des fichiers, recherchent sur des indexeurs publics et ont besoin d’anonymat. Je ne dirais même pas “besoin” — ils doivent être anonymes à tout prix.
Intercommunication : Puisqu’ils partagent la même “pile” réseau, ils communiquent entre eux via localhost (par exemple, Sonarr parle à qBit sur localhost:8080).

Le Groupe “Propre” (Bridge/Host) :

Membres : Jellyfin, Kavita, AdGuard Home, Dashboard.
Raison : Jellyfin diffuse de la vidéo 4K à haut débit (80Mbps+) vers votre télévision dans le salon. Si nous faisions passer cela par le VPN, le chiffrement consommerait inutilement du CPU et ajouterait de la latence. Ce trafic doit être local, rapide et direct.

Le Gardien DNS : AdGuard Home

Aucun serveur domestique moderne n’est complet sans une couche d’assainissement du trafic. Contrairement à cette extension que vous installez dans Chrome et qui ne protège que le navigateur, AdGuard Home opère au niveau du réseau. C’est un “trou noir” (DNS Sinkhole) pour toute votre maison.

La logique est simple et brutale : lorsque votre Box TV, votre iPad ou votre PC essaie de charger un site légitime, AdGuard le laisse passer. Mais lorsque ces mêmes appareils essaient de se connecter à des serveurs connus de publicité, de suivi, de télémétrie ou de logiciels malveillants, AdGuard renvoie une adresse nulle. Il bloque la connexion avant même que le téléchargement des déchets numériques ne commence. Le résultat ? Une navigation propre, des économies de bande passante et une confidentialité même pour les appareils où vous ne pouvez pas installer de bloqueurs, comme votre Smart TV (qui adore vous espionner).

La vie privée est importante !

Le Conflit du Port 53 : Chirurgie sur Ubuntu

Ici, nous rencontrons notre premier “Boss” technique de l’installation. Le protocole DNS fonctionne, par défaut, sur le port 53. Pour qu’AdGuard fonctionne comme serveur principal du réseau, il doit se trouver sur ce port. Le problème est qu’Ubuntu Server moderne est possessif. Il est livré avec un service appelé systemd-resolved occupant le port 53. Si nous essayions de forcer le démarrage du conteneur, Docker crierait une erreur “Address already in use”.

L’approche amateur consisterait à essayer d’exécuter AdGuard sur un port alternatif (comme 5353), mais cela casserait la compatibilité avec la plupart des routeurs et appareils. Notre approche a été chirurgicale :

Nous n’avons pas tué le service Ubuntu (cela casserait la résolution de noms propre au serveur). Nous avons édité /etc/systemd/resolved.conf et désactivé uniquement le DNSStubListener.

En gros, nous avons dit à Ubuntu : “Continue à résoudre les noms en interne, mais libère le port public 53 car AdGuard y vit maintenant.” C’est plutôt cool, non ?

Comme vous l’avez vu dans l’architecture ci-dessus, AdGuard réside dans le Groupe Propre, en dehors du tunnel VPN. C’est intentionnel et critique. Le DNS doit être accessible par tout appareil de votre réseau local (LAN) avec une latence minimale. Si nous mettions AdGuard derrière le VPN, chaque requête de site (“quelle est l’IP pour pornhub.com?”) devrait voyager à travers le tunnel chiffré et revenir, rendant votre navigation lente.

Il se trouve sur le bridge, léger et rapide, filtrant la saleté à l’entrée, tandis que Gluetun protège le trafic lourd à l’arrière.

N’oubliez pas de changer le paramètre DNS DHCP de votre routeur pour l’IP de votre serveur domestique.

Nous avons maintenant un environnement réseau blindé. Le trafic sensible est encapsulé dans un tunnel incassable, le trafic média circule librement sur le réseau local, et le DNS est propre. La “Forteresse” se dresse fièrement.

Dans le prochain article, j’expliquerai la magie des Hardlinks, comment résoudre le cauchemar des permissions utilisateur, et comprendre pourquoi la structure des dossiers est le secret pour faire fonctionner l’automatisation.