Publicar o NAS na internet (acesso externo)

15 min · 8 seções

Este guia transforma o seu NAS na sua nuvem: um nome próprio (micasa.duckdns.org), um certificado válido e acesso de qualquer lugar sem avisos do navegador. Como efeito colateral, a interface pode ser instalada como aplicativo (PWA): com um certificado autoassinado, o navegador limita o service worker; com um válido, não.

O caminho tem quatro passos, nesta ordem:

1. Abrir as portas 80 e 443 no roteador (e só essas).
2. Um nome de domínio que acompanhe o seu IP (DDNS).
3. Emitir o certificado do Let's Encrypt.
4. Publicar o painel e os apps com o proxy reverso.

Publicar o NAS é a mudança que mais aumenta a superfície de ataque em toda a vida útil dele. A seção Segurança não é um apêndice: leia-a antes de abrir a primeira porta.

Se você só usa em casa, há um caminho mais curto

Se você não precisa entrar de fora e a única coisa que te incomoda é o aviso do navegador —e não poder instalar o painel como aplicativo no celular—, nada disto é necessário.

O seu NAS tem o próprio certificado. Em Painel de controle → Acesso externo → Certificado há um botão para baixá-lo, com os passos de instalação para o dispositivo que você estiver usando (iPhone, Android, Windows, Mac ou Linux). Instale-o em cada celular ou computador pelo qual você entra e o aviso desaparece nele; depois disso, o painel já pode ser instalado como aplicativo.

É preciso fazer isso dispositivo por dispositivo —a confiança é de cada um—, mas uma única vez: continua valendo mesmo que o NAS mude de endereço. E tenha em mente o que você está dizendo ao instalá-lo: esse dispositivo vai confiar em qualquer site que o seu NAS apresentar. Em uma rede doméstica isso é normal, mas instale-o só nos seus dispositivos.

Como fica a montagem

Internet ──► roteador ──► NAS · Apache ──┬──► 127.0.0.1:5001   painel do LGM-OS
             80 e 443      :443 TLS      ├──► 127.0.0.1:8096   Jellyfin
                           :80 → https   └──► 127.0.0.1:8080   Nextcloud

O Apache é o único que escuta de fora: ele termina o TLS com o certificado do Let's Encrypt e encaminha para cada serviço por 127.0.0.1. Nem as portas do painel (5001 e 5000) nem as dos apps saem do NAS.

1. Antes de começar

• IP fixo para o NAS na sua rede: reserva DHCP no roteador ou IP estático em Painel de controle → Rede. Se o NAS mudar de IP, o redirecionamento de portas deixa de apontar para ele.
• IP público de verdade (sem CGNAT). Verifique assim:

curl -s https://api.ipify.org; echo      # IP com que a internet te vê

Compare esse valor com o IP WAN que o seu roteador mostra. Se não coincidirem, ou se o do roteador estiver na faixa 100.64.0.0 – 100.127.255.255, você está atrás de CGNAT: o redirecionamento de portas não vai funcionar, faça o que fizer. Peça um IP público à sua operadora (costuma ser grátis e basta solicitar) ou entre com Tailscale ou NetBird, que não precisam abrir portas (Serviços de rede).

• Um nome de domínio: um próprio, ou um gratuito com DDNS (passo 3).

2. Portas do roteador: 80 e 443, nada mais

A 80 não é opcional, mesmo que você não queira servir nada sem criptografia: o Let's Encrypt verifica se o domínio é seu pedindo um arquivo pela porta 80, e sem essa verificação não há certificado. O que convém é que a 80 só redirecione para a 443.

Por que NÃO se abrem a 5001 nem a 5000

São as portas do painel: a 5001 criptografada e a 5000 sem criptografia, que só redireciona para a 5001. Publicá-las é um erro, mesmo que pareça o caminho curto:

• A 5000 vai sem criptografia. O que passar por ali vindo da internet pode ser lido por qualquer um no caminho, a começar pelo endereço para onde você está sendo mandado.
• A 5001 serve o certificado autoassinado, então o navegador vai avisar sempre e você vai acabar se acostumando a ignorar avisos de certificado — que é justamente o que torna viável um ataque de intermediário contra você.
• Expõe a API de administração completa diretamente, sem os cabeçalhos, o redirecionamento nem a filtragem que o proxy aplica na frente.
• Com um certificado inválido, a PWA fica capenga e algumas funções do navegador são desativadas.

Com o proxy reverso, você entra no painel em https://micasa.duckdns.org (porta 443, com certificado válido) e a 5001 e a 5000 continuam escutando só dentro de casa, que é onde devem estar.

Também não abra a 445 (SMB), a 2049 (NFS), a 3389 nem, a menos que saiba muito bem o que está fazendo, a 22 (SSH). São protocolos pensados para a rede local; SMB exposto à internet é a porta por onde entra a maioria dos ransomwares domésticos.

O firewall do NAS também conta

Se você tiver o firewall ativado (Painel de controle → Segurança → Firewall), por padrão ele só deixa passar o painel e o SSH: mesmo que o roteador encaminhe, o Apache não vai receber nada. Adicione duas regras e não mexa na origem (elas devem permitir a entrada de qualquer IP):

3. DDNS com DuckDNS, passo a passo

Quase nenhuma operadora doméstica dá IP fixo: ele muda a cada poucos dias ou a cada reinício do roteador. Um serviço de DNS dinâmico mantém o nome apontando para o IP atual. O DuckDNS é gratuito, não pede cartão e funciona bem.

1. Entre em https://www.duckdns.org e clique em um dos botões sign in with (Google, GitHub, Reddit…). Não crie senha nova: use a conta que você já tem.
2. No campo add domain, escreva o nome que quiser (por exemplo micasa) e clique em add domain. O seu domínio é micasa.duckdns.org.
3. No alto da página você verá token: xxxxxxxx-xxxx-…. Copie-o. Esse token é a senha do seu domínio: não o compartilhe nem o deixe visível em capturas de tela.
4. No NAS: Painel de controle → Acesso externo → *Domínio dinâmico (DDNS)*. Escolha o provedor DuckDNS, escreva o domínio completo (micasa.duckdns.org), cole o token e deixe a frequência padrão (aceita de 5 a 1440 minutos; abaixo de 5, os provedores começam a recusar pedidos). Ative o interruptor e salve; com “Atualizar agora” você verifica na hora se o token vale. O painel mostra o último IP publicado e o erro da última atualização, se houve. Os outros provedores aceitos são o Cloudflare (token de API com permissão Zone · DNS · Edit) e o No-IP (chave da seção Dynamic DNS).
5. Verifique se resolve (pelo NAS, ou com nslookup no Windows):

getent hosts micasa.duckdns.org      # deve devolver o seu IP público
curl -s https://api.ipify.org; echo  # ...o mesmo que este

Se preferir não depender do NAS para isso, veja se o seu roteador tem cliente DDNS com DuckDNS: ele atualiza o IP mesmo com o NAS desligado, o que é mais robusto. A chamada, caso você precise dela em um script ou para forçar uma atualização manual, é:

curl -s "https://www.duckdns.org/update?domains=micasa&token=SEU-TOKEN&ip="
# responde OK (atualizado) ou KO (domínio ou token incorretos)

O parâmetro ip vazio significa “use o IP de onde estou chamando”.

Dois detalhes úteis do DuckDNS: as mudanças levam alguns minutos para se propagar, e qualquer subdomínio (pelis.micasa.duckdns.org) resolve para o mesmo IP sem configurar nada — é o que permite publicar vários apps por nome (passo 5).

Com domínio próprio, o passo 3 é equivalente: aponte um registro A para o seu IP público (ou use o DDNS do seu provedor de DNS) e siga igual a partir do passo 4.

4. Emitir o certificado

Requisitos, os três ao mesmo tempo: o domínio resolve para o seu IP público, a porta 80 chega ao NAS e o Apache está rodando. Antes de emitir qualquer coisa, verifique de fora da sua rede (dados móveis do celular, não o Wi-Fi de casa) se http://micasa.duckdns.org responde algo —mesmo que seja a página padrão do Apache—. Se isso não funcionar, o certificado também não vai.

Pela interface: Painel de controle → Acesso externo → Certificado. Escreva o domínio, um e-mail de contato (o Let's Encrypt só o usa para avisar se um certificado vai expirar sem ser renovado), aceite os termos e clique em Emitir certificado. Quando ele estiver emitido, Usar no painel faz a própria interface servi-lo: ela reinicia por alguns segundos e volta por https com o seu domínio, sem avisos.

O equivalente pelo console, se você preferir ver por dentro:

sudo certbot --apache -d micasa.duckdns.org -m voce@email --agree-tos --no-eff-email

Se você já gerencia o proxy reverso pelo painel, use certbot certonly --apache … no lugar: --apache sozinho reescreve os vhosts para adicionar o TLS e sobrescreveria os que o painel gera. Com certonly só o certificado é emitido, e a configuração continua com o painel.

O que você precisa saber depois:

• Os arquivos ficam em /etc/letsencrypt/live/micasa.duckdns.org/ (fullchain.pem e privkey.pem). Não os mova: o certbot os substitui ao renovar.
• Expiram em 90 dias e se renovam sozinhos. O pacote instala um temporizador; confira com systemctl list-timers certbot.timer e teste com sudo certbot renew --dry-run.
• O Let's Encrypt limita as tentativas que falham (5 por hora e por domínio). Se falhar, corrija a causa antes de tentar novamente; insistir em loop vai te deixar sem poder emitir por um tempo. Para testes, use --dry-run.

Se você emitiu o certificado manualmente com o certbot, o painel não fica sabendo: vai continuar com o autoassinado na 5001, e a cópia que você fizer vai ficar velha assim que o certbot renovar. Este gancho de implantação o mantém em dia (o certbot o executa a cada renovação efetiva):

sudo tee /etc/letsencrypt/renewal-hooks/deploy/10-lgm-os.sh >/dev/null <<'EOF'
#!/bin/sh
# certbot ejecuta este script en cada renovación efectiva.
D=micasa.duckdns.org
cp "/etc/letsencrypt/live/$D/fullchain.pem" /etc/nas/tls/cert.pem
cp "/etc/letsencrypt/live/$D/privkey.pem"  /etc/nas/tls/key.pem
chgrp nas /etc/nas/tls/key.pem && chmod 640 /etc/nas/tls/key.pem
systemctl restart nas-backend
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/10-lgm-os.sh

5. Publicar apps por subdomínio (proxy reverso)

A ideia: um nome para cada serviço, todos entrando pela 443 e distribuídos pelo Apache conforme o nome que o navegador pedir.

Em Painel de controle → Acesso externo → Proxy reverso → Nova regra, com um serviço por regra:

1. Domínio público: o nome completo (pelis.micasa.duckdns.org).
2. Host de destino e Porta de destino: normalmente 127.0.0.1 e a porta do app. A lista de contêineres em execução os preenche para você; se o app não publicar porta, escreva-os à mão.
3. Redirecionar HTTP para HTTPS: deixe ativado. Quem digitar o nome sem https:// vai acabar mesmo assim na conexão criptografada.
4. Usar o certificado gerenciado: ativado se esse nome estiver coberto pelo certificado emitido no passo 4.
5. Regra ativa: você pode deixá-la desativada e publicá-la mais tarde sem excluí-la.

Ao salvar, o painel escreve o vhost e recarrega o Apache. Os WebSockets funcionam sem mexer em nada (o instalador deixa o proxy_wstunnel habilitado); é o que os terminais web, os logs ao vivo, o Home Assistant ou o code-server precisam para não ficarem “conectando” eternamente. Duas condições para cada nome:

• Que resolva: com DuckDNS, os subdomínios funcionam sozinhos; com domínio próprio, crie um registro CNAME (ou A) para cada um.
• Que tenha certificado: a validação HTTP-01 emite por nome específico, então emita também o certificado do subdomínio (ou adicione-o ao existente com outro -d). Um certificado curinga *.midominio exige validação DNS-01, que este guia não cobre.

E uma regra que vale repetir: as portas dos apps não são abertas no roteador. O proxy chega a elas por 127.0.0.1. Publicar por proxy e também abrir a porta direta é deixar a porta dos fundos aberta ao lado da boa.

6. Segurança (leia antes de mexer no roteador)

Enquanto o NAS estava só na sua rede, um erro de configuração era visto pela sua família. Desde que você o publica, ele é visto por um scanner automático em questão de horas: não é exagero, os bots testam /login em qualquer IP com a 443 aberta. Isto é o mínimo:

• Ative o 2FA agora: Painel de controle → Sua conta. Sem segundo fator, a única coisa entre a internet e todos os seus dados é uma senha.
• Passe o Consultor de segurança (Painel de controle → Segurança) e resolva os avisos dele. É o resumo honesto de como o dispositivo está; não publique com avisos críticos em aberto.
• Bloqueio de IPs ativado (Segurança → Bloqueio de IPs). O painel já limita a 10 tentativas por minuto e bloqueia a conta após 5 falhas, mas o bloqueio por IP é o que corta a varredura pela raiz.
• Firewall ativado, com só a 80 e a 443 abertas para fora.
• Senhas longas e únicas, principalmente a do administrador. Para quem só consulta, crie usuários com o papel viewer.
• Atualize: Painel de controle → Atualizar o LGM-OS (apt) e a atualização do painel. Um NAS publicado e sem atualizar é questão de tempo, não de sorte.
• Backups, e pelo menos um offline. Publicar multiplica o risco de ransomware, e um backup conectado é criptografado junto com o resto. Veja disaster-recovery.md.
• Olhe a Auditoria e os Usuários conectados de vez em quando: ali você verá as tentativas de acesso e de qual IP vieram.
• Publique só o necessário. Se o que você quer é ver seus filmes fora de casa, publique o Jellyfin e administre o painel de casa. Cada nome publicado é mais uma porta.

E a comparação honesta: o mais seguro continua sendo não publicar nada. Uma VPN (WireGuard) dá acesso a todo o NAS sem expor um único serviço à internet, em troca de precisar conectar a VPN em cada dispositivo. O LGM-OS traz o próprio servidor WireGuard (Painel de controle → VPN, com um código QR para o celular), e em “Sua conexão” ele pode pedir ao roteador que abra a porta sozinho (UPnP). Para uso pessoal, é a melhor opção. Se você não puder abrir essa porta —CGNAT, ou um roteador que não é seu—, a mesma tela traz o Tailscale e o NetBird: o NAS entra na sua rede desse serviço e você chega a ele sem abrir nada. Publicar com proxy e certificado é a opção certa quando você precisa compartilhar com pessoas que não vão instalar uma VPN.

7. Se algo não funcionar

Pela VPN se vê tudo menos o painel

Desconcerta porque parece que o NAS está se protegendo de você: o celular diz “conectado”, o ping funciona, você entra nos outros dispositivos da casa… e o painel dá não é possível acessar esse site.

Não é o firewall nem a licença: é o MTU. Um túnel WireGuard sem MTU declarado usa 1420 bytes, o que sobra na fibra mas não cabe no 4G/5G (a rede móvel e o CGNAT ficam com parte do pacote). Os pacotes pequenos passam —por isso o ping e quase tudo funcionam— e os cheios se perdem em silêncio. O painel é justamente o que viaja em pacotes cheios: o handshake TLS com o certificado e depois a interface inteira.

Os clientes que o LGM-OS cria já saem com MTU = 1280, o mínimo que a internet garante. Se o seu cliente é de antes dessa versão, não é preciso refazê-lo: edite a conexão no app do WireGuard e adicione essa linha em [Interface].

Comandos de diagnóstico:

sudo apachectl configtest              # a configuração do Apache é válida?
sudo systemctl status apache2
sudo journalctl -u apache2 -n 50
sudo tail -f /var/log/apache2/error.log
sudo certbot certificates              # certificados emitidos e a validade deles

Os módulos do Apache de que o proxy precisa (proxy, proxy_http, proxy_wstunnel, headers, ssl, rewrite) são habilitados por deploy/install.sh e deploy/update.sh. Para verificá-los:

apache2ctl -M | grep -E 'proxy|headers|ssl|rewrite'