Streaming è Rotto IV: La Fortezza: VPN e Gluetun
Abbiamo il server e il nostro sistema operativo installati e configurati. Prima di iniziare a scegliere gli attori che interpreteranno i ruoli principali, fermiamoci un momento per concentrarci sul backstage. Più precisamente, sulla privacy. Indipendentemente dal fatto che tu viva in un paese che punisce attivamente la pirateria o meno, nessuno dovrebbe sapere come usi la tua rete locale. La privacy conta!.
Se iniziassi un download torrent sul server in questo momento, il tuo vero IP sarebbe esposto al mondo. Inoltre, pubblicità, tracker e dati di telemetria fluirebbero liberamente attraverso la tua rete.
Dobbiamo porre fine a tutto ciò.
Non ci limiteremo a “installare una VPN”; architetteremo un gateway di rete sicuro che funga da Kill Switch fisico e segregherà il traffico di rete per garantire velocità dove serve e privacy dove è vitale. Sembra complesso, vero? Vedrai che non lo è. Puoi scommetterci.
Il Concetto di Gateway Sidecar
L’approccio amatoriale è installare una VPN direttamente sul sistema operativo (Host). Questo è negativo perché critta tutto (incluso l’accesso SSH e lo streaming locale di Jellyfin), uccidendo, massacrando e scuoiando le prestazioni.
Qui applicheremo il pattern Sidecar:
Creiamo un container (Gluetun) la cui unica funzione è aprire un tunnel VPN sicuro.
I container “sensibili” (qBittorrent, Prowlarr, Arr-Stack) non usano la rete del server. Sono configurati con
network_mode: service:gluetun.Viaggiano a rimorchio della connessione di Gluetun. Non hanno una propria uscita internet.
L’Architettura Ibrida: Sporco vs. Pulito
Come avrai notato nel diagramma sopra, e pensando alle prestazioni della CPU e del sistema, opteremo per un approccio cruciale: Segregazione di Rete. Divideremo la nostra rete in due gruppi:
- Il Gruppo “Sporco” (Tunnel VPN):
Membri: qBittorrent, Prowlarr, Sonarr, Radarr.
Motivo: Scaricano file, cercano su indicizzatori pubblici e hanno bisogno di anonimato. Non direi nemmeno “bisogno”—devono essere anonimi a tutti i costi.
Comunicazione interna: Poiché condividono lo stesso “stack” di rete, comunicano tra loro via localhost (ad esempio, Sonarr parla con qBit su localhost:8080).
- Il Gruppo “Pulito” (Bridge/Host):
Membri: Jellyfin, Kavita, AdGuard Home, Dashboard.
Motivo: Jellyfin trasmette video 4K ad alto bitrate (80Mbps+) alla tua TV in salotto. Se facessimo passare questo traffico attraverso la VPN, la crittografia consumerebbe inutilmente CPU e aggiungerebbe latenza. Questo traffico deve essere locale, veloce e diretto.
Il Guardiano DNS: AdGuard Home
Nessun home server moderno è completo senza uno strato di sanificazione del traffico. A differenza di quel plugin che installi in Chrome che protegge solo il browser, AdGuard Home opera a livello di rete. È un “buco nero” (DNS Sinkhole) per tutta la tua casa.
La logica è semplice e brutale: quando la tua TV Box, il tuo iPad o il tuo PC cercano di caricare un sito legittimo, AdGuard lo lascia passare. Ma quando questi stessi dispositivi cercano di connettersi a server noti di pubblicità, tracciamento, telemetria o malware, AdGuard restituisce un indirizzo nullo. Blocca la connessione prima che inizi anche solo il download della spazzatura digitale. Il risultato? Navigazione pulita, risparmio di banda e privacy anche per i dispositivi su cui non puoi installare blocker, come la tua Smart TV (che adora spiarti).
La privacy conta!
Il Conflitto sulla Porta 53: Chirurgia su Ubuntu
Qui incontriamo il primo “Boss” tecnico dell’installazione. Il protocollo DNS opera, per impostazione predefinita, sulla porta 53. Perché AdGuard funzioni come server principale della rete, deve risiedere su questa porta. Il problema è che Ubuntu Server moderno è possessivo. Viene fornito con un servizio chiamato systemd-resolved che occupa la porta 53. Se provassimo a forzare l’avvio del container, Docker urlerebbe un errore “Indirizzo già in uso”.
L’approccio amatoriale sarebbe provare a far girare AdGuard su una porta alternativa (come 5353), ma questo romperebbe la compatibilità con la maggior parte dei router e dispositivi. Il nostro approccio è stato chirurgico:
Non abbiamo ucciso il servizio di Ubuntu (ciò avrebbe rotto la risoluzione dei nomi del server stesso). Abbiamo modificato /etc/systemd/resolved.conf e disabilitato solo il DNSStubListener.
In pratica, abbiamo detto a Ubuntu: “Continua a risolvere i nomi internamente, ma libera la porta pubblica 53 perché ora ci vive AdGuard”. È venuto fuori dannatamente bene, vero?
Come hai visto nell’architettura sopra, AdGuard risiede nel Gruppo Pulito, fuori dal tunnel VPN. Questo è intenzionale e critico. Il DNS deve essere accessibile da qualsiasi dispositivo sulla tua rete locale (LAN) con latenza minima. Se mettessimo AdGuard dietro la VPN, ogni richiesta di sito (“qual è l’IP per pornhub.com?”) dovrebbe viaggiare attraverso il tunnel crittografato e ritorno, rendendo la tua navigazione lenta.
Rimane sul bridge, leggero e veloce, filtrando lo sporco all’ingresso, mentre Gluetun protegge il traffico pesante nel retro.
Non dimenticare di cambiare il parametro DNS DHCP del tuo router con l’IP del homeserver.
Ora abbiamo un ambiente di rete corazzato. Il traffico sensibile è incapsulato in un tunnel inespugnabile, il traffico multimediale scorre liberamente sulla rete locale e il DNS è pulito. La “Fortezza” si erge alta.
Nel prossimo post, spiegherò la magia degli Hardlink, come risolvere l’incubo dei permessi utente e capire perché la struttura delle cartelle è il segreto per far funzionare l’automazione.