Idiomes disponibles:

Streaming està Trencat IV: La Fortalesa: VPN i Gluetun

Aquesta publicació va ser originalment escrita en anglès. La traducció pot no reflectir el 100% de les idees originals de l'autor.

Tenim el servidor i el nostre sistema operatiu instal·lat i configurat. Abans de començar a triar els actors que interpretaran els papers principals, parem un moment per centrar-nos en els bastidors. Més concretament, en la privadesa. Independentment de si vius en un país que castiga activament la pirateria o no, ningú hauria de saber com utilitzes la teva xarxa local. La privadesa importa!.

Si comences una descàrrega torrent al servidor ara mateix, la teva IP real quedarà exposada al món. A més, anuncis, rastrejadors i dades de telemetria fluiran lliurement per la teva xarxa.

Hem de posar-hi fi.

No només anem a “instal·lar una VPN”; anem a dissenyar una passarel·la de xarxa segura que actui com un Kill Switch físic i segrega el trànsit de la teva xarxa per garantir velocitat on importa i privadesa on és vital. Sona complex, oi? Veuràs que no ho és. Pots apostar-hi.

El Concepte de Passarel·la Sidecar

L’enfocament amateur és instal·lar una VPN directament al sistema operatiu (Host). Això és dolent perquè xifra tot (incloent-hi el teu accés SSH i la transmissió local de Jellyfin), matant, destrossant i esquilant el rendiment.

Aquí, aplicarem el patró Sidecar:

  • Creem un contenidor (Gluetun) la única funció del qual és obrir un túnel VPN segur.

  • Els contenidors “sensibles” (qBittorrent, Prowlarr, Arr-Stack) no utilitzen la xarxa del servidor. Es configuren amb network_mode: service:gluetun.

  • Viatgen a sobre de la connexió de Gluetun. No tenen sortida a Internet pròpia.

Passarel·la Sidecar explicada.

L’Arquitectura Híbrida: Brut vs. Net

Com pots haver notat en el diagrama anterior, i pensant en el nostre CPU i rendiment del sistema, optarem per un enfocament crucial: Segregació de Xarxa. Dividirem la nostra xarxa en dos grups:

  1. El Grup “Brut” (Túnel VPN):
  • Membres: qBittorrent, Prowlarr, Sonarr, Radarr.

  • Raó: Baixen fitxers, cerquen en indexadors públics i necessiten anonimat. Ni tan sols diria “necessiten”—han de ser anònims a qualsevol preu.

  • Intercomunicació: Com que comparteixen la mateixa “pila” de xarxa, es comuniquen entre ells via localhost (per exemple, Sonarr parla amb qBit a localhost:8080).

  1. El Grup “Net” (Bridge/Host):
  • Membres: Jellyfin, Kavita, AdGuard Home, Dashboard.

  • Raó: Jellyfin transmet vídeo 4K d’alta taxa de bits (80Mbps+) a la teva TV al saló. Si passéssim això a través de la VPN, el xifratge consumiria CPU inútilment i afegiria latència. Aquest trànsit ha de ser local, ràpid i directe.

El Guardià DNS: AdGuard Home

Cap servidor domèstic modern està complet sense una capa de saneig de trànsit. A diferència d’aquell connector que instal·les a Chrome que només protegeix el navegador, AdGuard Home opera a nivell de xarxa. És un “forat negre” (DNS Sinkhole) per a tota la teva casa.

La lògica és simple i brutal: quan la teva TV Box, el teu iPad o el teu PC intenta carregar un lloc legítim, AdGuard ho deixa passar. Però quan aquests mateixos dispositius intenten connectar-se a servidors coneguts de publicitat, rastreig, telemetria o programari maliciós, AdGuard retorna una adreça nul·la. Bloqueja la connexió abans que comenci ni tan sols la descàrrega de l’escombraria digital. El resultat? Navegació neta, estalvi d’amplada de banda i privadesa fins i tot per a dispositius on no pots instal·lar bloquejadors, com la teva Smart TV (que li encanta espiar-te).

La privadesa importa!

El Conflicte del Port 53: Cirurgia a Ubuntu

Aquí ens trobem amb el nostre primer “Cap” tècnic de la instal·lació. El protocol DNS opera, per defecte, al port 53. Perquè AdGuard funcioni com el servidor principal de la xarxa, necessita seure en aquest port. El problema és que Ubuntu Server modern és possessiu. Ve amb un servei anomenat systemd-resolved ocupant el port 53. Si intentéssim forçar que el contenidor s’aixequés, Docker cridaria un error “Address already in use”.

L’enfocament amateur seria intentar executar AdGuard en un port alternatiu (com el 5353), però això trencaria la compatibilitat amb la majoria de routers i dispositius. El nostre enfocament va ser quirúrgic:

No vam matar el servei d’Ubuntu (això trencaria la resolució de noms pròpia del servidor). Vam editar /etc/systemd/resolved.conf i vam desactivar només el DNSStubListener.

Bàsicament, vam dir-li a Ubuntu: “Segueix resolent noms internament, però surt del port públic 53 perquè ara AdGuard viu allà”. Va quedar la mar de bé, oi?

Com vas veure en l’arquitectura anterior, AdGuard resideix al Grup Net, fora del túnel VPN. Això és intencionat i crític. El DNS ha de ser accessible per qualsevol dispositiu a la teva xarxa local (LAN) amb latència mínima. Si poséssim AdGuard darrere de la VPN, cada petició de lloc (“quina és la IP per pornhub.com?”) hauria de viatjar a través del túnel xifrat i tornar, fent la teva navegació lenta.

Es troba al bridge, lleuger i ràpid, filtrant la brutícia a l’entrada, mentre Gluetun protegeix el trànsit pesat al darrere.

Pantalla d’AdGuard

No oblidis canviar el paràmetre DNS del DHCP del teu router per la IP del servidor domèstic.

Ara tenim un entorn de xarxa blindat. El trànsit sensible està encapsulat en un túnel irrompible, el trànsit de mitjans flueix lliurement a la xarxa local, i el DNS està net. La “Fortalesa” s’aixeca imponent.

Fortalesa perquè és TeamFortress!

A la propera entrada, explicaré la màgia dels Hardlinks, com resoldre el malson dels permisos d’usuari i entendre per què l’estructura de carpetes és el secret per fer funcionar l’automatització.