Publicar o NAS na internet (acesso externo)

16 min · 8 secções

Este guia transforma o teu NAS na tua nuvem: um nome próprio (micasa.duckdns.org), um certificado válido e acesso a partir de qualquer sítio sem avisos do navegador. Como efeito secundário, a interface pode ser instalada como aplicação (PWA): com um certificado autoassinado, o navegador limita o service worker e, com um válido, não.

O caminho são quatro passos, por esta ordem:

1. Abrir as portas 80 e 443 no router (e só essas).
2. Um nome de domínio que siga o teu IP (DDNS).
3. Emitir o certificado da Let's Encrypt.
4. Publicar o painel e as apps com o proxy inverso.

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

Se só o usas em casa, há um caminho mais curto

Se não precisas de entrar a partir de fora e a única coisa que te incomoda é o aviso do navegador —e não poderes instalar o painel como aplicação no telemóvel—, não precisas de nada disto.

O teu NAS tem o seu próprio certificado. Em Painel de controlo → Acesso externo → Certificado há um botão para o transferir, com os passos de instalação para o dispositivo a partir do qual estiveres a ver (iPhone, Android, Windows, Mac ou Linux). Instala-o em cada telemóvel ou computador a partir do qual entras e o aviso desaparece nesse; depois, o painel já pode ser instalado como aplicação.

Tens de o fazer dispositivo a dispositivo —a confiança é de cada um—, mas uma única vez: continua a valer mesmo que o NAS mude de endereço. E tem em conta o que estás a dizer ao instalá-lo: esse dispositivo vai confiar em qualquer sítio que o teu NAS lhe apresente. Numa rede de casa é o normal, mas instala-o só nos teus dispositivos.

Como fica montado

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

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

1. Antes de começar

• IP fixo para o NAS na tua rede: reserva DHCP no router ou IP estático em Painel de controlo → Rede. Se o NAS mudar de IP, o reencaminhamento de portas deixa de apontar para ele.
• IP público a sério (sem CGNAT). Verifica-o assim:

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

Compara esse valor com o IP WAN que o teu router mostra. Se não coincidirem, ou se o do router estiver no intervalo 100.64.0.0 – 100.127.255.255, estás atrás de CGNAT: o reencaminhamento de portas não vai funcionar, faças o que fizeres. Pede ao teu operador um IP público (costuma ser grátis e basta pedi-lo) ou entra com o Tailscale ou o NetBird, que não precisam de abrir portas (Serviços de rede).

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

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

A 80 não é opcional, mesmo que não queiras servir nada sem cifrar: a Let's Encrypt verifica que o domínio é teu pedindo um ficheiro pela porta 80, e sem essa verificação não há certificado. O que convém, isso sim, é que a 80 só redirecione para a 443.

Porque NÃO se abrem a 5001 nem a 5000

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

• A 5000 vai sem cifrar. O que viajar por aí a partir da internet pode ser lido por qualquer pessoa pelo caminho, a começar pelo endereço para onde estás a ser enviado.
• A 5001 serve o certificado autoassinado, por isso o navegador vai avisar sempre e vais acabar por te habituar a ignorar avisos de certificado — que é precisamente o que torna viável um ataque de intermediário contra ti.
• Expõe a API de administração completa diretamente, sem os cabeçalhos, o redirecionamento nem a filtragem que o proxy aplica à frente.
• Com um certificado inválido, a PWA fica limitada e algumas funções do navegador são desativadas.

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

Também não abras a 445 (SMB), a 2049 (NFS), a 3389 nem, a não ser que saibas muito bem o que estás a fazer, a 22 (SSH). São protocolos pensados para a rede local; o SMB exposto à internet é a porta por onde entra a maior parte do ransomware doméstico.

A firewall do NAS também conta

Se tiveres a firewall ativada (Painel de controlo → Segurança → Firewall), por predefinição só deixa passar o painel e o SSH: mesmo que o router reencaminhe, o Apache não vai receber nada. Acrescenta duas regras e não mexas na origem (têm de poder entrar a partir de qualquer IP):

3. DDNS com o DuckDNS, passo a passo

Quase nenhum operador doméstico dá IP fixo: muda de poucos em poucos dias ou a cada reinício do router. Um serviço de DNS dinâmico mantém o nome a apontar para o IP atual. O DuckDNS é gratuito, não pede cartão e funciona bem.

1. Entra em https://www.duckdns.org e carrega num dos botões sign in with (Google, GitHub, Reddit…). Não crias uma palavra-passe nova: usas a conta que já tens.
2. Na caixa add domain, escreve o nome que quiseres (por exemplo micasa) e carrega em add domain. O teu domínio é micasa.duckdns.org.
3. No topo da página vais ver token: xxxxxxxx-xxxx-…. Copia-o. Esse token é a palavra-passe do teu domínio: não o partilhes nem o deixes visível em capturas de ecrã.
4. No NAS: Painel de controlo → Acesso externo → *Domínio dinâmico (DDNS)*. Escolhe o fornecedor DuckDNS, escreve o domínio completo (micasa.duckdns.org), cola o token e deixa a frequência predefinida (admite de 5 a 1440 minutos; abaixo de 5, os fornecedores começam a rejeitar pedidos). Ativa o interruptor e guarda; com «Atualizar agora» verificas no momento que o token é válido. O painel mostra o último IP publicado e o erro da última atualização, se tiver havido. Os outros fornecedores admitidos são o Cloudflare (token de API com a permissão Zone · DNS · Edit) e o No-IP (chave da secção Dynamic DNS).
5. Verifica que resolve (a partir do NAS, ou com nslookup no Windows):

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

Se preferires não depender do NAS para isto, vê se o teu router traz um cliente DDNS com DuckDNS: atualiza o IP mesmo que o NAS esteja desligado, o que é mais robusto. O pedido, para o caso de precisares dele num script ou para forçar uma atualização manual, é:

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

O parâmetro ip vazio significa «usa o IP a partir do qual te estou a chamar».

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

Com um domínio próprio, o passo 3 é equivalente: aponta um registo A para o teu IP público (ou usa o DDNS do teu fornecedor de DNS) e continua igual a partir do passo 4.

4. Emitir o certificado

Requisitos, os três ao mesmo tempo: o domínio resolve para o teu IP público, a porta 80 chega ao NAS e o Apache está em funcionamento. Antes de emitir seja o que for, verifica a partir de fora da tua rede (dados móveis do telemóvel, não o Wi-Fi de casa) que http://micasa.duckdns.org responde alguma coisa —mesmo que seja a página predefinida do Apache—. Se isso não funcionar, o certificado também não.

A partir da interface: Painel de controlo → Acesso externo → Certificado. Escreve o domínio, um e-mail de contacto (a Let's Encrypt só o usa para te avisar se um certificado estiver prestes a expirar sem ser renovado), aceita as condições e carrega em Emitir certificado. Quando estiver emitido, Usar no painel faz com que a própria interface o sirva: reinicia durante uns segundos e volta por https com o teu domínio, sem avisos.

O equivalente pela consola, se preferires vê-lo por dentro:

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

Se já geres o proxy inverso a partir do painel, usa certbot certonly --apache … em vez disso: o --apache sozinho reescreve os vhosts para acrescentar o TLS e passaria por cima dos que o painel gera. Com certonly, só é emitido o certificado e a configuração continua a cargo do painel.

O que deves saber depois:

• Os ficheiros ficam em /etc/letsencrypt/live/micasa.duckdns.org/ (fullchain.pem e privkey.pem). Não os movas: o certbot substitui-os ao renovar.
• Expiram ao fim de 90 dias e renovam-se sozinhos. O pacote instala um temporizador; verifica-o com systemctl list-timers certbot.timer e ensaia-o com sudo certbot renew --dry-run.
• A Let's Encrypt limita as tentativas falhadas (5 por hora e por domínio). Se falhar, corrige a causa antes de tentar novamente; insistir em ciclo vai deixar-te sem poder emitir durante algum tempo. Para testes, usa --dry-run.

Se emitiste o certificado à mão com o certbot, o painel não dá por isso: continua com o autoassinado na 5001 e a cópia que fizeres fica desatualizada assim que o certbot renovar. Este gancho de implementação mantém-no em dia (o certbot executa-o em cada renovação efetiva):

sudo tee /etc/letsencrypt/renewal-hooks/deploy/10-lgm-os.sh >/dev/null <<'EOF'
#!/bin/sh
# o certbot executa este script em cada renovação efetiva.
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 inverso)

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

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

1. Domínio público: o nome completo (pelis.micasa.duckdns.org).
2. Host e porta de destino: normalmente 127.0.0.1 e a porta da app. A lista de contentores em funcionamento preenche-os por ti; se a app não publicar porta, escreve-os à mão.
3. Redirecionar HTTP para HTTPS: deixa-o ativado. Quem escrever o nome sem https:// vai parar igualmente à ligação cifrada.
4. Usar o certificado gerido: ativado se esse nome estiver coberto pelo certificado emitido no passo 4.
5. Regra ativa: podes deixá-la desativada e publicá-la mais tarde sem a eliminar.

Ao guardar, o painel escreve o vhost e recarrega o Apache. Os WebSockets funcionam sem mexer em nada (o instalador deixa o proxy_wstunnel ativado); é o que precisam os terminais web, os registos em direto, o Home Assistant ou o code-server para não ficarem «a ligar» para sempre. Duas condições para cada nome:

• Que resolva: com o DuckDNS, os subdomínios funcionam sozinhos; com um domínio próprio, cria um registo CNAME (ou A) para cada um.
• Que tenha certificado: a validação HTTP-01 emite por nome concreto, por isso emite também o certificado do subdomínio (ou acrescenta-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 convém repetir: as portas das apps não se abrem no router. O proxy chega a elas por 127.0.0.1. Publicar por proxy e abrir também a porta direta é deixar a porta das traseiras aberta ao lado da boa.

6. Segurança (lê isto antes de mexer no router)

Enquanto o NAS estava só na tua rede, uma falha de configuração era vista pela tua família. A partir do momento em que o publicas, é vista por um scanner automático em questão de horas: não é exagero, os bots experimentam /login em qualquer IP com a 443 aberta. Isto é o mínimo:

• Ativa o 2FA já: Painel de controlo → A tua conta. Sem segundo fator, a única coisa entre a internet e todos os teus dados é uma palavra-passe.
• Passa o Consultor de segurança (Painel de controlo → Segurança) e resolve os seus avisos. É o resumo honesto de como está o NAS; não publiques 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 o varrimento pela raiz.
• Firewall ativada com só a 80 e a 443 abertas para fora.
• Palavras-passe longas e únicas, em especial a do administrador. Para quem só consulta, cria utilizadores com a função viewer.
• Atualiza: Painel de controlo → Atualizar o LGM-OS (apt) e a atualização do painel. Um NAS publicado e sem atualizações é uma questão de tempo, não de sorte.
• Cópias de segurança, e pelo menos uma fora de linha. Publicar multiplica o risco de ransomware, e uma cópia ligada é cifrada com o resto. Vê disaster-recovery.md.
• Consulta a Auditoria e os Utilizadores ligados de vez em quando: aí vais ver as tentativas de acesso e a partir de que IP.
• Publica só o necessário. Se o que queres é ver os teus filmes fora de casa, publica o Jellyfin e administra o painel a partir de casa. Cada nome publicado é mais uma porta.

E a comparação honesta: o mais seguro continua a ser não publicar nada. Uma VPN (WireGuard) dá-te acesso a todo o NAS sem expor um único serviço à internet, em troca de teres de ligar a VPN em cada dispositivo. O LGM-OS traz o seu próprio servidor WireGuard (Painel de controlo → VPN, com um código QR para o telemóvel), e em «A tua ligação» pode pedir ao router que abra a porta sozinho (UPnP). Para uso pessoal é a melhor opção. Se não conseguires abrir essa porta —CGNAT, ou um router que não é teu—, o mesmo ecrã traz o Tailscale e o NetBird: o NAS entra na tua rede desse serviço e chegas a ele sem abrir nada. Publicar com proxy e certificado é a opção certa quando precisas de partilhar com pessoas que não vão instalar uma VPN.

7. Se alguma coisa não funcionar

Pela VPN vê-se tudo menos o painel

Desconcerta porque parece que o NAS se protege de ti: o telemóvel diz «ligado», o ping funciona, entras nos outros dispositivos de casa… e o painel dá não é possível aceder a este site.

Não é a firewall nem a licença: é o MTU. Um túnel WireGuard sem MTU declarado usa 1420 bytes, o que sobra por fibra mas não cabe em 4G/5G (a rede móvel e o CGNAT ficam com parte do pacote). Os pacotes pequenos passam —daí o ping e quase tudo funcionarem— e os cheios perdem-se em silêncio. O painel é precisamente o que viaja em pacotes cheios: o cumprimento TLS com o seu 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 teu cliente for anterior a essa versão, não precisas de o refazer: edita a ligação na app do WireGuard e acrescenta 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 sua validade

Os módulos do Apache de que o proxy precisa (proxy, proxy_http, proxy_wstunnel, headers, ssl, rewrite) são ativados pelo deploy/install.sh e pelo deploy/update.sh. Para os verificar:

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