Pubblicare il NAS su internet (accesso esterno)

15 min · 8 sezioni

Questa guida trasforma il tuo NAS nel tuo cloud: un nome tuo (micasa.duckdns.org), un certificato valido e accesso da qualsiasi posto senza avvisi del browser. Come effetto collaterale, l'interfaccia si può installare come applicazione (PWA): con un certificato autofirmato il browser limita il service worker e con uno valido no.

La strada sono quattro passaggi, in quest'ordine:

1. Aprire 80 e 443 nel router (e solo quelle).
2. Un nome di dominio che segua il tuo IP (DDNS).
3. Emettere il certificato Let's Encrypt.
4. Pubblicare il pannello e le app con il proxy inverso.

Pubblicare il NAS è la modifica che aggiunge più superficie di attacco in tutta la sua vita utile. La sezione Sicurezza non è un'appendice: leggila prima di aprire la prima porta.

Se lo usi solo a casa, c'è una strada più corta

Se non hai bisogno di entrare da fuori e l'unica cosa che ti dà fastidio è l'avviso del browser —e che non si possa installare il pannello come applicazione sul telefono—, non serve niente di tutto questo.

Il tuo NAS ha il suo certificato. In Pannello di controllo → Accesso esterno → Certificato c'è un pulsante per scaricarlo, con i passaggi di installazione del dispositivo da cui stai guardando (iPhone, Android, Windows, Mac o Linux). Installalo su ogni telefono o computer da cui entri e l'avviso sparisce su quello; dopo, il pannello si lascia già installare come applicazione.

Bisogna farlo dispositivo per dispositivo —la fiducia è di ciascuno— ma una sola volta: resta valido anche se il NAS cambia indirizzo. E tieni conto di cosa stai dicendo installandolo: quel dispositivo si fiderà di qualsiasi sito che gli presenti il tuo NAS. In una rete di casa è normale, ma installalo solo sui tuoi dispositivi.

Come resta montato

Internet ──► router ──► NAS · Apache ──┬──► 127.0.0.1:5001   pannello di LGM-OS
             80 e 443    :443 TLS      ├──► 127.0.0.1:8096   Jellyfin
                         :80 reindir.  └──► 127.0.0.1:8080   Nextcloud

Apache è l'unico che ascolta da fuori: termina il TLS con il certificato Let's Encrypt e inoltra a ogni servizio tramite 127.0.0.1. Né le porte del pannello (5001 e 5000) né quelle delle app escono dal NAS.

1. Prima di cominciare

• IP fisso per il NAS nella tua rete: prenotazione DHCP nel router o IP statico in Pannello di controllo → Rete. Se il NAS cambia IP, l'inoltro delle porte smette di puntare a lui.
• IP pubblico vero (senza CGNAT). Verificalo così:

curl -s https://api.ipify.org; echo      # IP con cui ti vede internet

Confronta quel valore con l'IP WAN che mostra il tuo router. Se non coincidono, o se quello del router è nell'intervallo 100.64.0.0 – 100.127.255.255, sei dietro CGNAT: l'inoltro delle porte non funzionerà qualunque cosa tu faccia. Chiedi al tuo operatore un IP pubblico (di solito è gratis e basta richiederlo) o entra con Tailscale o NetBird, che non hanno bisogno di aprire porte (Servizi di rete).

• Un nome di dominio: uno tuo, o uno gratuito con DDNS (passaggio 3).

2. Porte del router: 80 e 443, niente di più

L'80 non è facoltativa anche se non vuoi servire nulla in chiaro: Let's Encrypt verifica che il dominio sia tuo chiedendo un file sulla porta 80, e senza quella verifica non c'è certificato. Ciò che conviene è che l'80 si limiti a reindirizzare alla 443.

Perché NON si aprono la 5001 né la 5000

Sono le porte del pannello: la 5001 cifrata e la 5000 in chiaro, che reindirizza soltanto alla

1. Pubblicarle è un errore anche se sembra la strada breve:

• La 5000 va in chiaro. Ciò che viaggia da lì da internet lo legge chiunque lungo il percorso, a cominciare dall'indirizzo a cui ti si sta mandando.
• La 5001 serve il certificato autofirmato, quindi il browser avviserà sempre e finirai per abituarti a saltare gli avvisi di certificato — che è proprio ciò che rende possibile un attacco man-in-the-middle contro di te.
• Espone direttamente l'API di amministrazione completa, senza le intestazioni, il reindirizzamento né il filtro che applica il proxy davanti.
• Con un certificato non valido la PWA resta zoppa e alcune funzioni del browser si disattivano.

Con il proxy inverso entri nel pannello da https://micasa.duckdns.org (porta 443, con certificato valido) e la 5001 e la 5000 continuano ad ascoltare solo dentro casa, che è dove devono stare.

Non aprire nemmeno la 445 (SMB), la 2049 (NFS), la 3389 né, a meno che tu non sappia molto bene cosa fai, la 22 (SSH). Sono protocolli pensati per la rete locale; SMB esposto a internet è la porta da cui entra la maggior parte del ransomware domestico.

Conta anche il firewall del NAS

Se hai il firewall attivato (Pannello di controllo → Sicurezza → Firewall), di default lascia passare solo il pannello e SSH: anche se il router inoltra, Apache non riceverà nulla. Aggiungi due regole e non toccare l'origine (devono poter entrare da qualsiasi IP):

3. DDNS con DuckDNS, passo passo

Quasi nessun operatore domestico dà un IP fisso: cambia ogni pochi giorni o a ogni riavvio del router. Un servizio di DNS dinamico mantiene il nome puntato all'IP attuale. DuckDNS è gratuito, non chiede la carta e funziona bene.

1. Entra in https://www.duckdns.org e premi uno dei pulsanti sign in with (Google, GitHub, Reddit…). Non creare una password nuova: usa l'account che hai già.
2. Nel riquadro add domain scrivi il nome che vuoi (per esempio micasa) e premi *add domain*. Il tuo dominio è micasa.duckdns.org.
3. In cima alla pagina vedrai token: xxxxxxxx-xxxx-…. Copialo. Quel token è la password del tuo dominio: non condividerlo né lasciarlo visibile negli screenshot.
4. Nel NAS: Pannello di controllo → Accesso esterno → Dominio dinamico (DDNS). Scegli il provider DuckDNS, scrivi il dominio completo (micasa.duckdns.org), incolla il token e lascia la frequenza di default (ammette da 5 a 1440 minuti; sotto i 5 i provider cominciano a rifiutare le richieste). Attiva l'interruttore e salva; con «Aggiorna ora» verifichi subito che il token sia valido. Il pannello mostra l'ultimo IP pubblicato e l'errore dell'ultimo aggiornamento se c'è stato. Gli altri provider ammessi sono Cloudflare (token API con permesso Zone · DNS · Edit) e No-IP (chiave della sezione Dynamic DNS).
5. Verifica che risolva (dal NAS, o nslookup da Windows):

getent hosts micasa.duckdns.org      # deve restituire il tuo IP pubblico
curl -s https://api.ipify.org; echo  # ...lo stesso di questo

Se preferisci non dipendere dal NAS per questo, guarda se il tuo router ha un client DDNS con DuckDNS: aggiorna l'IP anche se il NAS è spento, che è più robusto. La chiamata, nel caso ti serva in uno script o per forzare un aggiornamento manuale, è:

curl -s "https://www.duckdns.org/update?domains=micasa&token=IL-TUO-TOKEN&ip="
# risponde OK (aggiornato) o KO (dominio o token errati)

Il parametro ip vuoto significa «usa l'IP da cui ti sto chiamando».

Due dettagli utili di DuckDNS: le modifiche impiegano un paio di minuti a propagarsi, e qualsiasi sottodominio (pelis.micasa.duckdns.org) risolve allo stesso IP senza configurare nulla — è ciò che permette di pubblicare diverse app per nome (passaggio 5).

Con un dominio tuo il passaggio 3 è equivalente: punta un record A al tuo IP pubblico (o usa il DDNS del tuo provider DNS) e prosegui allo stesso modo dal passaggio 4.

4. Emettere il certificato

Requisiti, tutti e tre insieme: il dominio risolve al tuo IP pubblico, la porta 80 arriva al NAS e Apache è in funzione. Prima di emettere qualsiasi cosa, verifica da fuori dalla tua rete (dati mobili del telefono, non il wifi di casa) che http://micasa.duckdns.org risponda qualcosa —anche solo la pagina predefinita di Apache—. Se questo non funziona, nemmeno il certificato.

Dall'interfaccia: Pannello di controllo → Accesso esterno → Certificato. Scrivi il dominio, un'email di contatto (Let's Encrypt la usa solo per avvisarti se un certificato sta per scadere senza rinnovarsi), accetta le condizioni e premi Emetti certificato. Quando è emesso, Usa nel pannello fa sì che l'interfaccia stessa lo serva: si riavvia per qualche secondo e torna in https con il tuo dominio, senza avvisi.

L'equivalente da console, se preferisci vederlo dall'interno:

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

Se il proxy inverso lo gestisci già dal pannello, usa invece certbot certonly --apache …: --apache da solo riscrive i vhost per aggiungere il TLS e calpesterebbe quelli generati dal pannello. Con certonly si emette solo il certificato e la configurazione continua a gestirla il pannello.

Cosa devi sapere dopo:

• I file restano in /etc/letsencrypt/live/micasa.duckdns.org/ (fullchain.pem e privkey.pem). Non spostarli: certbot li sostituisce al rinnovo.
• Scadono dopo 90 giorni e si rinnovano da soli. Il pacchetto installa un timer; verificalo con systemctl list-timers certbot.timer e provalo con sudo certbot renew --dry-run.
• Let's Encrypt limita i tentativi falliti (5 all'ora per dominio). Se fallisce, risolvi la causa prima di riprovare; insistere in un ciclo ti lascerà per un po' senza poter emettere. Per le prove usa --dry-run.

Se hai emesso il certificato a mano con certbot, il pannello non se ne accorge: continuerà con quello autofirmato sulla 5001 e la copia che fai invecchierà appena certbot rinnova. Questo hook di distribuzione lo tiene aggiornato (certbot lo esegue a ogni rinnovo effettivo):

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. Pubblicare app per sottodominio (proxy inverso)

L'idea: un nome per ogni servizio, tutti in ingresso dalla 443 e smistati da Apache secondo il nome che chiede il browser.

In Pannello di controllo → Accesso esterno → Proxy inverso → Nuova regola, con un servizio per regola:

1. Dominio pubblico: il nome completo (pelis.micasa.duckdns.org).
2. Host e porta di destinazione: di solito 127.0.0.1 e la porta dell'app. Il menu dei container in funzione li compila per te; se l'app non pubblica una porta, scrivili a mano.
3. Reindirizza HTTP a HTTPS: lascialo attivo. Chi scrive il nome senza https:// finirà comunque nella connessione cifrata.
4. Usa il certificato gestito: attivo se quel nome è coperto dal certificato emesso al passaggio 4.
5. Regola attiva: puoi lasciarla disattivata e pubblicarla più tardi senza eliminarla.

Al salvataggio, il pannello scrive il vhost e ricarica Apache. I WebSocket funzionano senza toccare nulla (il programma di installazione lascia proxy_wstunnel abilitato); è ciò di cui hanno bisogno i terminali web, i log dal vivo, Home Assistant o code-server per non restare eternamente «in connessione». Due condizioni per ogni nome:

• Che risolva: con DuckDNS i sottodomini funzionano da soli; con un dominio tuo crea un record CNAME (o A) per ciascuno.
• Che abbia un certificato: la validazione HTTP-01 emette per nome preciso, quindi emetti anche il certificato del sottodominio (o aggiungilo a quello esistente con un altro -d). Un certificato jolly *.miodominio richiede la validazione DNS-01, che questa guida non copre.

E una regola che conviene ripetere: le porte delle app non si aprono nel router. Il proxy ci arriva tramite 127.0.0.1. Pubblicare via proxy e in più aprire la porta diretta significa lasciare aperta la porta sul retro accanto a quella buona.

6. Sicurezza (leggilo prima di toccare il router)

Finché il NAS era solo nella tua rete, un errore di configurazione lo vedeva la tua famiglia. Da quando lo pubblichi, lo vede uno scanner automatico nel giro di poche ore: non è un'esagerazione, i bot provano /login su qualsiasi IP con la 443 aperta. Questo è il minimo:

• Attiva subito il 2FA: Pannello di controllo → Il tuo account. Senza secondo fattore, l'unica cosa tra internet e tutti i tuoi dati è una password.
• Passa il Consulente di sicurezza (Pannello di controllo → Sicurezza) e risolvi i suoi avvisi. È il riassunto onesto di come sta il dispositivo; non pubblicare con avvisi critici aperti.
• Blocco degli IP attivato (Sicurezza → Blocco degli IP). Il pannello limita già a 10 tentativi al minuto e blocca l'account dopo 5 errori, ma il blocco per IP è ciò che taglia la scansione alla radice.
• Firewall attivato con solo la 80 e la 443 aperte verso fuori.
• Password lunghe e uniche, specialmente quella dell'amministratore. Per chi deve solo consultare, crea utenti con ruolo viewer.
• Aggiorna: Pannello di controllo → Aggiorna LGM-OS (apt) e l'aggiornamento del pannello. Un NAS pubblicato e non aggiornato è questione di tempo, non di fortuna.
• Backup, e almeno uno offline. Pubblicare moltiplica il rischio di ransomware, e un backup collegato si cifra insieme al resto. Vedi disaster-recovery.md.
• Guarda il Controllo e gli Utenti connessi ogni tanto: lì vedrai i tentativi di accesso e da quale IP.
• Pubblica il minimo. Se quello che vuoi è vedere i tuoi film fuori casa, pubblica Jellyfin e amministra il pannello da casa. Ogni nome pubblicato è una porta in più.

E il confronto onesto: la cosa più sicura resta non pubblicare nulla. Una VPN (WireGuard) ti dà accesso a tutto il NAS senza esporre un solo servizio a internet, in cambio di dover collegare la VPN su ogni dispositivo. LGM-OS ha il suo server WireGuard (Pannello di controllo → VPN, con un codice QR per il telefono), e in «La tua connessione» può chiedere al router di aprire la sua porta da solo (UPnP). Per l'uso personale è l'opzione migliore. Se non puoi aprire quella porta —CGNAT, o un router che non è tuo—, la stessa schermata ha Tailscale e NetBird: il NAS entra nella tua rete di quel servizio e ci arrivi senza aprire nulla. Pubblicare con proxy e certificato è l'opzione giusta quando devi condividere con persone che non installeranno una VPN.

7. Se qualcosa non funziona

Via VPN si vede tutto tranne il pannello

Sconcerta perché sembra che il NAS si protegga da te: il telefono dice «connesso», il ping va, entri negli altri dispositivi di casa… e il pannello dà impossibile raggiungere il sito.

Non è il firewall né la licenza: è l'MTU. Un tunnel WireGuard senza MTU dichiarato usa 1420 byte, che bastano e avanzano in fibra ma non passano in 4G/5G (la rete mobile e il CGNAT si tengono una parte del pacchetto). I pacchetti piccoli passano —ecco perché il ping e quasi tutto funzionano— e quelli pieni si perdono in silenzio. Il pannello è proprio ciò che viaggia in pacchetti pieni: la negoziazione TLS con il suo certificato e poi l'interfaccia intera.

I client creati da LGM-OS escono già con MTU = 1280, il minimo che internet garantisce. Se il tuo client è precedente a quella versione, non serve rifarlo: modifica la connessione nell'app WireGuard e aggiungi quella riga in [Interface].

Comandi di diagnostica:

sudo apachectl configtest              # la configurazione di Apache è valida?
sudo systemctl status apache2
sudo journalctl -u apache2 -n 50
sudo tail -f /var/log/apache2/error.log
sudo certbot certificates              # certificati emessi e loro scadenza

I moduli di Apache di cui ha bisogno il proxy (proxy, proxy_http, proxy_wstunnel, headers, ssl, rewrite) li abilitano deploy/install.sh e deploy/update.sh. Per verificarli:

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