Tunnel di porta

Questo documento illustra la funzione «Tunnel di porta» del pannello: mappare le porte applicative di un server in tunnel privo di IP pubblico sulle porte pubbliche del server del pannello, così che gli utenti esterni possano accedervi.

In una frase

Il tuo server è nascosto nella rete interna (non ha IP pubblico) e su di esso gira un sito o un'applicazione a cui nessuno da fuori può accedere. Il Tunnel di porta «apre una porta pubblica sul server del pannello e trasporta gli accessi esterni, attraverso un tunnel cifrato, fino alla porta applicativa di questo server di rete interna». Risultato: chi è fuori, accedendo a IP del server del pannello:porta, accede all'applicazione sul tuo server di rete interna.

Panoramica della funzione

Per i server senza IP pubblico collegati tramite «Operations tramite tunnel», le applicazioni in esecuzione (come Navidrome per la musica, Nextcloud per il cloud, Memos per le note) non sono raggiungibili dall'esterno. Il Tunnel di porta mappa queste porte applicative sulle porte del server del pannello (che ha un IP pubblico), così che gli utenti esterni vi accedano tramite «IP del server del pannello:porta».

Quando serve

su un server in tunnel gira un'applicazione Web che vuoi rendere accessibile dall'esterno
esporre su Internet i servizi di un dispositivo di rete interna
dare un ingresso pubblico a siti, API e pannelli presenti su dispositivi senza IP pubblico

Principio (come scorrono i dati)

Utente esterno → porta pubblica del server del pannello (es. :9117) → tunnel cifrato → porta applicativa del server in tunnel (es. :9117)

Il traffico esterno raggiunge prima il server del pannello (l'unico punto con IP pubblico), poi attraverso un tunnel inverso cifrato arriva al dispositivo di rete interna e infine termina sulla porta applicativa realmente in esecuzione sul dispositivo.

Canale unificato (tutti i dispositivi, nessuna scelta manuale):

Tipo di dispositivo	Canale di inoltro	Note
Server Linux (senza IP pubblico)	tunnel inverso 4433 (cifratura AES-256-GCM)	flusso di byte TCP nativo, veloce e stabile, con supporto a molte connessioni simultanee
Dispositivi Android/Termux	tunnel inverso 4433 (cifratura AES-256-GCM)	stesso tunnel cifrato dei dispositivi Linux, stabile e senza overhead aggiuntivo

Il pannello usa ovunque il tunnel inverso sulla 4433: creando un tunnel non devi preoccuparti del canale sottostante né sceglierlo manualmente.

> Nota aggiuntiva: sui dispositivi Android/Termux la Gestione di sistema (esecuzione di comandi, terminale, file) passa dal canale stabile SocketIO; il Tunnel di porta invece usa sempre il tunnel inverso 4433. Ognuno fa il suo lavoro senza disturbare l'altro.

Come si usa

1. Assicurati che il dispositivo di destinazione sia collegato tramite «Operations tramite tunnel» (Agent online)

2. Apri «Tunnel di porta» e clicca «Aggiungi tunnel»

3. Scegli il server in tunnel (Agent) e compila:

Porta di ascolto: la porta pubblica del server del pannello (per l'accesso esterno), ad esempio 9117
Porta di destinazione: la porta applicativa sul server in tunnel, ad esempio 8080

4. Dopo la creazione, dall'esterno si accede a http://IP del server del pannello:porta di ascolto

Esempio

Supponiamo che l'IP pubblico del server del pannello sia 203.0.113.10 e che tu abbia un Raspberry Pi di rete interna con Navidrome in ascolto sulla 4533:

Porta di ascolto: 4533
Porta di destinazione: 4533
Dopo la creazione, un utente esterno apre Navidrome sul Raspberry Pi accedendo a http://203.0.113.10:4533

Limiti di risorse

Limite	Valore
Canali di inoltro massimi per Agent	32
Agent massimi in tutto il pannello	64

Oltre il limite le nuove connessioni vengono rifiutate automaticamente, senza impatto sui tunnel già attivi.

Avvertenze

1. Firewall cloud: il firewall cloud / security group del server del pannello deve consentire la porta di ascolto corrispondente, altrimenti l'accesso esterno non funziona.

2. Versione dell'Agent: inoltrare porte non SSH (diverse dalla 22) richiede che il server in tunnel abbia installato la nuova versione dell'Agent (le versioni vecchie supportano solo l'inoltro della porta 22). Per inoltrare altre porte, reinstalla l'Agent.

3. Agent online: il tunnel dipende dalla presenza online dell'Agent. Se l'Agent è offline il tunnel si interrompe e si ripristina automaticamente alla riconnessione.

4. Ripristino automatico al riavvio del pannello: dopo il riavvio del servizio del pannello i tunnel si ripristinano automaticamente (attivati dalla riconnessione dell'Agent).

5. Il servizio di destinazione su Android deve supportare la concorrenza: se il servizio di destinazione inoltrato sull'Android (come python3 -m http.server) è a thread singolo e con keep-alive attivo, una connessione non chiusa blocca le richieste successive. Si consiglia un servizio multi-thread oppure di garantire la chiusura tempestiva delle connessioni.

Documentazione correlata

Operations tramite tunnel — collega prima al pannello il dispositivo senza IP pubblico
Inoltro di porta — inoltro di porta tradizionale sui server con IP pubblico (le differenze sono descritte più sotto)

Tunnel di porta vs Inoltro di porta (come scegliere)

	Tunnel di porta (questo documento)	Inoltro di porta
Server adatti	senza IP pubblico (server in tunnel)	con IP pubblico dedicato
Modalità	tunnel inverso	DNAT del firewall di sistema
Dove avviene l'inoltro	server del pannello	macchina di destinazione
Serve l'Agent	Sì	No

In una frase: senza IP pubblico usa il tunnel, con IP pubblico usa l'inoltro.