Streaming está Roto IV: La Fortaleza: VPN y Gluetun
Tenemos el servidor y nuestro sistema operativo instalado y configurado. Antes de empezar a elegir a los actores que interpretarán los papeles principales, hagamos una pausa para centrarnos en el backstage. Más concretamente, en la privacidad. Independientemente de que vivas en un país que castigue activamente la piratería o no, nadie debería saber cómo usas tu red local. ¡La privacidad importa!.
Si inicias una descarga de torrent en el servidor ahora mismo, tu IP real quedará expuesta al mundo. Además, anuncios, rastreadores y datos de telemetría fluirán libremente por tu red.
Tenemos que poner fin a esto.
No vamos simplemente a “instalar una VPN”; vamos a diseñar una puerta de enlace de red segura que actúe como un Kill Switch físico y segregue tu tráfico de red para garantizar velocidad donde importa y privacidad donde es vital. ¿Suena complejo? Verás que no lo es. Puedes apostar por ello.
El Concepto de Puerta de Enlace Sidecar
El enfoque amateur es instalar una VPN directamente en el sistema operativo (Host). Esto es malo porque cifra todo (incluyendo tu acceso SSH y la transmisión local de Jellyfin), matando, destrozando y desollando el rendimiento.
Aquí, aplicaremos el patrón Sidecar:
Creamos un contenedor (Gluetun) cuya única función es abrir un túnel VPN seguro.
Los contenedores “sensibles” (qBittorrent, Prowlarr, Arr-Stack) no usan la red del servidor. Se configuran con
network_mode: service:gluetun.Se suben a hombros de la conexión de Gluetun. No tienen salida a internet propia.
La Arquitectura Híbrida: Sucio vs. Limpio
Como habrás notado en el diagrama anterior, y pensando en el rendimiento de nuestra CPU y del sistema, vamos a optar por un enfoque crucial: Segregación de Red. Dividiremos nuestra red en dos grupos:
- El Grupo “Sucio” (Túnel VPN):
Miembros: qBittorrent, Prowlarr, Sonarr, Radarr.
Razón: Descargar archivos, buscar en indexadores públicos y necesitan anonimato. Ni siquiera diría “necesitan”—deben ser anónimos a toda costa.
Intercomunicación: Como comparten la misma “pila” de red, se comunican entre sí a través de localhost (por ejemplo, Sonarr habla con qBit en localhost:8080).
- El Grupo “Limpio” (Bridge/Host):
Miembros: Jellyfin, Kavita, AdGuard Home, Dashboard.
Razón: Jellyfin transmite vídeo 4K de alta tasa de bits (80Mbps+) a tu TV en el salón. Si pasáramos esto por la VPN, el cifrado consumiría CPU inútilmente y añadiría latencia. Este tráfico debe ser local, rápido y directo.
El Guardián DNS: AdGuard Home
Ningún servidor doméstico moderno está completo sin una capa de saneamiento de tráfico. A diferencia de ese plugin que instalas en Chrome que solo protege el navegador, AdGuard Home opera a nivel de red. Es un “agujero negro” (DNS Sinkhole) para toda tu casa.
La lógica es simple y brutal: cuando tu TV Box, tu iPad o tu PC intentan cargar un sitio legítimo, AdGuard lo deja pasar. Pero cuando esos mismos dispositivos intentan conectarse a servidores conocidos de publicidad, rastreo, telemetría o malware, AdGuard devuelve una dirección nula. Bloquea la conexión incluso antes de que comience la descarga de basura digital. ¿El resultado? Navegación limpia, ahorro de ancho de banda y privacidad incluso para dispositivos donde no puedes instalar bloqueadores, como tu Smart TV (que adora espiarte).
¡La privacidad importa!
El Conflicto del Puerto 53: Cirugía en Ubuntu
Aquí nos encontramos con el primer “Jefe” técnico de la instalación. El protocolo DNS opera, por defecto, en el puerto 53. Para que AdGuard funcione como el servidor principal de la red, necesita ocupar este puerto. El problema es que Ubuntu Server moderno es posesivo. Viene con un servicio llamado systemd-resolved ocupando el puerto 53. Si intentáramos forzar la subida del contenedor, Docker gritaría un error de “Dirección ya en uso”.
El enfoque amateur sería intentar ejecutar AdGuard en un puerto alternativo (como 5353), pero eso rompería la compatibilidad con la mayoría de routers y dispositivos. Nuestro enfoque fue quirúrgico:
No matamos el servicio de Ubuntu (eso rompería la resolución de nombres propia del servidor). Editamos /etc/systemd/resolved.conf y desactivamos solo el DNSStubListener.
Básicamente, le dijimos a Ubuntu: “Sigue resolviendo nombres internamente, pero sal del puerto público 53 porque AdGuard vive allí ahora”. ¿Quedó bastante genial, verdad?
Como viste en la arquitectura anterior, AdGuard reside en el Grupo Limpio, fuera del túnel VPN. Esto es intencional y crítico. El DNS necesita ser accesible por cualquier dispositivo en tu red local (LAN) con la mínima latencia. Si pusiéramos AdGuard detrás de la VPN, cada solicitud de sitio ("¿cuál es la IP para pornhub.com?") tendría que viajar a través del túnel cifrado y volver, haciendo tu navegación lenta.
Se sienta en el bridge, ligero y rápido, filtrando la suciedad en la entrada, mientras Gluetun protege el tráfico pesado en la parte trasera.
No olvides cambiar el parámetro DNS de DHCP de tu router a la IP del servidor doméstico.
Ahora tenemos un entorno de red blindado. El tráfico sensible está encapsulado en un túnel irrompible, el tráfico de medios fluye libremente en la red local y el DNS está limpio. La “Fortaleza” se alza imponente.
En la próxima publicación, explicaré la magia de los Hardlinks, cómo resolver la pesadilla de los permisos de usuario y entender por qué la estructura de carpetas es el secreto para que la automatización funcione.