Streaming Está Quebrado IV: A Fortaleza: VPN e Gluetun :: doismiu

Temos o servidor e nosso sistema operacional instalados e configurados. Antes de começarmos a escalar os atores que vão desempenhar os papéis principais, vamos fazer uma pausa para focar nos bastidores. Mais precisamente, na privacidade. Independentemente de você morar em um país que puna ativamente a pirataria ou não, ninguém deve saber como você usa sua rede local. Privacidade importa!.

Se você iniciar um download de torrent no servidor agora mesmo, seu IP real será exposto ao mundo. Além disso, anúncios, rastreadores e dados de telemetria fluirão livremente pela sua rede.

Temos que acabar com isso.

Não vamos apenas “instalar uma VPN”; vamos arquitetar um gateway de rede seguro que atue como um Kill Switch físico e segrege o tráfego da sua rede para garantir velocidade onde importa e privacidade onde é vital. Parece complexo, certo? Você verá que não é. Pode apostar.

O Conceito de Gateway Sidecar

A abordagem amadora é instalar uma VPN diretamente no sistema operacional (Host). Isso é ruim porque criptografa tudo (incluindo seu acesso SSH e streaming local do Jellyfin), matando, estraçalhando e esfolando o desempenho.

Aqui, aplicaremos o padrão Sidecar:

Criamos um container (Gluetun) cuja única função é abrir um túnel VPN seguro.
Os containers “sensíveis” (qBittorrent, Prowlarr, Arr-Stack) não usam a rede do servidor. Eles são configurados com network_mode: service:gluetun.
Eles pegam carona na conexão do Gluetun. Eles não têm saída própria para a internet.

A Arquitetura Híbrida: Sujo vs. Limpo

Como você deve ter notado no diagrama acima, e pensando no desempenho da nossa CPU e do sistema, vamos optar por uma abordagem crucial: Segregação de Rede. Vamos dividir nossa rede em dois grupos:

O Grupo “Sujo” (Túnel VPN):

Membros: qBittorrent, Prowlarr, Sonarr, Radarr.
Razão: Eles baixam arquivos, buscam em indexadores públicos e precisam de anonimato. Eu nem diria “precisam”—eles devem ser anônimos a todo custo.
Intercomunicação: Como compartilham a mesma “pilha” de rede, eles conversam entre si via localhost (por exemplo, o Sonarr conversa com o qBit em localhost:8080).

O Grupo “Limpo” (Bridge/Host):

Membros: Jellyfin, Kavita, AdGuard Home, Dashboard.
Razão: O Jellyfin transmite vídeo 4K de alta taxa de bits (80Mbps+) para sua TV na sala. Se passássemos isso pela VPN, a criptografia consumiria CPU inutilmente e adicionaria latência. Esse tráfego deve ser local, rápido e direto.

O Guardião DNS: AdGuard Home

Nenhum servidor doméstico moderno está completo sem uma camada de saneamento de tráfego. Diferente daquele plugin que você instala no Chrome que só protege o navegador, o AdGuard Home opera no nível da rede. É um “buraco negro” (DNS Sinkhole) para toda a sua casa.

A lógica é simples e brutal: quando sua TV Box, seu iPad ou seu PC tenta carregar um site legítimo, o AdGuard deixa passar. Mas quando esses mesmos dispositivos tentam se conectar a servidores conhecidos de publicidade, rastreamento, telemetria ou malware, o AdGuard retorna um endereço nulo. Ele bloqueia a conexão antes mesmo que o download do lixo digital comece. O resultado? Navegação limpa, economia de banda larga e privacidade até para dispositivos onde você não pode instalar bloqueadores, como sua Smart TV (que adora espionar você).

Privacidade importa!

O Conflito da Porta 53: Cirurgia no Ubuntu

Aqui encontramos nosso primeiro “Chefe” técnico da instalação. O protocolo DNS opera, por padrão, na porta 53. Para que o AdGuard funcione como o servidor principal da rede, ele precisa ficar nesta porta. O problema é que o Ubuntu Server moderno é possessivo. Ele vem com um serviço chamado systemd-resolved ocupando a porta 53. Se tentássemos forçar o container a subir, o Docker gritaria um erro “Address already in use”.

A abordagem amadora seria tentar executar o AdGuard em uma porta alternativa (como 5353), mas isso quebraria a compatibilidade com a maioria dos roteadores e dispositivos. Nossa abordagem foi cirúrgica:

Não matamos o serviço do Ubuntu (isso quebraria a resolução de nomes do próprio servidor). Editamos o arquivo /etc/systemd/resolved.conf e desativamos apenas o DNSStubListener.

Basicamente, dissemos ao Ubuntu: “Continue resolvendo nomes internamente, mas saia da porta pública 53 porque o AdGuard mora lá agora.” Ficou bem legal, não é?

Como você viu na arquitetura acima, o AdGuard reside no Grupo Limpo, fora do túnel VPN. Isso é intencional e crítico. O DNS precisa ser acessível por qualquer dispositivo na sua rede local (LAN) com latência mínima. Se colocássemos o AdGuard atrás da VPN, toda solicitação de site (“qual é o IP para pornhub.com?”) teria que viajar pelo túnel criptografado e voltar, tornando sua navegação lenta.

Ele fica na bridge, leve e rápido, filtrando a sujeira na entrada, enquanto o Gluetun protege o tráfego pesado nos fundos.

Não se esqueça de alterar o parâmetro DNS do DHCP do seu roteador para o IP do servidor doméstico.

Agora temos um ambiente de rede blindado. O tráfego sensível está encapsulado em um túnel inquebrável, o tráfego de mídia flui livremente na rede local e o DNS está limpo. A “Fortaleza” está de pé.

No próximo post, explicarei a mágica dos Hardlinks, como resolver o pesadelo das permissões de usuário e entender por que a estrutura de pastas é o segredo para fazer a automação funcionar.