Tor aggira CGNAT con poche righe: come pubblicare un server senza VPS

Pubblicare un server domestico dietro CGNAT può richiedere un VPS pubblico, un tunnel WireGuard, regole di routing, DNAT e una configurazione firewall abbastanza articolata. Oppure, cambiando completamente modello, possono bastare poche righe nel file di configurazione di Tor.

In un nostro precedente approfondimento abbiamo visto come pubblicare un server dietro CGNAT usando WireGuard e un VPS: il server domestico stabilisce autonomamente un tunnel verso una macchina dotata di indirizzo IP pubblico; il VPS riceve le connessioni provenienti da Internet e le inoltra attraverso WireGuard verso casa. Servono quindi un endpoint pubblico, routing IP, regole NAT e una corretta gestione del percorso di ritorno dei pacchetti.

Con un Tor Onion Service, invece, il problema è affrontato a un livello completamente differente. Il server non deve più essere raggiungibile attraverso un indirizzo IP pubblico: è sufficiente che possa aprire connessioni verso la rete Tor. E una connessione in uscita è proprio ciò che CGNAT permette senza problemi.

Perché CGNAT complica la pubblicazione di un server

Con un’utenza dotata di IPv4 pubblico, il router domestico riceve direttamente i pacchetti destinati a quell’indirizzo. Una regola di port forwarding può quindi stabilire, ad esempio, che le connessioni TCP dirette alla porta 443 su tale IP pubblico vadano automaticamente inoltrate verso 192.168.1.20:443. CGNAT rompe questo meccanismo perché introduce un secondo livello di NAT nella rete dell’operatore.

L’indirizzo IPv4 pubblico non è più legato al singolo router dell’utente abbonato ma è condiviso tra più clienti e il primo apparato che riceve una nuova connessione proveniente da Internet è il CGN (Carrier-Grade NAT, condivide un singolo indirizzo IP pubblico tra più clienti) dell’operatore.

Da qui nasce la soluzione basata sul VPS descritta nel nostro precedente articolo: se non è possibile avviare da Internet una connessione verso il router, è il server domestico a iniziarne una verso un host remoto. Il VPS possiede l’elemento che manca alla rete domestica: un vero IP pubblico.

Con Tor il server non deve avere un IP pubblico

Un Onion Service non funziona come un normale server Internet al quale il client si collega conoscendone l’indirizzo IP.

Tor crea una rete sovrapposta alla normale infrastruttura IP: Tor Project sottolinea infatti che, dal punto di vista degli Onion Services, gli indirizzi IP del server non svolgono il ruolo che hanno sul web tradizionale: la posizione del servizio resta nascosta dietro la rete Tor.

Prendiamo un server web nginx in esecuzione sulla macchina domestica e rispondente all’indirizzo locale 127.0.0.1:8080. Di norma nessun sistema esterno potrebbe raggiungerlo: l’indirizzo 127.0.0.1 appartiene soltanto alla macchina locale.

Installando il servizio Tor possiamo però aggiungere nel file di configurazione /etc/tor/torrc quanto segue:

HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:8080

La seconda direttiva indica che quando qualcuno raggiunge la porta 80 dell’Onion Service, la connessione deve essere consegnata alla porta 8080 del localhost. Dopo il riavvio del servizio, Tor genera inoltre l’indirizzo .onion associato.

Non abbiamo acquistato un VPS. Non abbiamo un IPv4 pubblico. Non si è aperta la porta 80 sul router né impostato DNAT né configurato WireGuard. E nginx potrebbe tranquillamente continuare ad ascoltare soltanto su 127.0.0.1:8080.

Come fa Tor ad attraversare CGNAT?

Il servizio Tor installato sulla macchina domestica non aspetta che qualcuno da Internet riesca a raggiungerlo direttamente. Fa l’opposto: apre autonomamente circuiti verso alcuni relay Tor che assumono il ruolo di introduction point.

Tor Project cita esplicitamente il NAT punching tra le proprietà degli Onion Services: non è necessario aprire porte sul firewall o disporre di connessioni in ingresso, perché il servizio stabilisce soltanto connessioni uscenti.

Il principio iniziale ricorda quindi quello che abbiamo sfruttato con WireGuard: far partire la comunicazione dalla macchina che si trova dietro CGNAT. Dopo questo punto, però, i due sistemi prendono strade completamente diverse.

Supponiamo di digitare in Tor Browser (download) l’indirizzo di un Onion Service. Il browser non esegue una normale risoluzione DNS per ottenere l’IP del server. Un indirizzo Onion v3 è composto da 56 caratteri più il suffisso .onion e incorpora informazioni crittografiche legate all’identità del servizio.

Il servizio ha precedentemente pubblicato nella rete Tor un descrittore contenente, tra le altre informazioni, i suoi introduction point. Il client sceglie quindi un relay Tor come rendezvous point e costruisce verso di esso un circuito. Attraverso uno degli introduction point comunica al servizio dove avviare l’incontro.

Schema di funzionamento

A questo punto succede qualcosa che spiega perfettamente perché CGNAT non rappresenti un ostacolo.

Come si vede nello schema di seguito, né il client né il server devono aprire una connessione IP diretta l’uno verso l’altro. Entrambi raggiungono dall’interno la rete Tor e si incontrano in un punto intermedio. Sia il client che l’Onion Service costruiscono i propri circuiti verso il rendezvous point; il collegamento completo di norma coinvolge diversi relay e non espone l’IP del servizio al client.

Da qui deriva la sorprendente semplicità della configurazione. Come accennato in precedenza, inoltre, l’indirizzo .onion rappresenta direttamente l’identità crittografica del servizio e non richiede il DNS pubblico tradizionale. Il traffico tra utente Tor e Onion Service dispone inoltre già di cifratura e autenticazione end-to-end offerte dal protocollo Onion Services. Tor Project precisa infatti che utilizzare HTTP per un Onion Service non equivale alla classica connessione HTTP in chiaro attraverso Internet.

Tor rende inutile WireGuard con un VPS?

No. Con VPS e WireGuard otteniamo un vero punto di ingresso dalla normale rete Internet pubblica.

Un Onion Service, invece, rimane accessibile soltanto attraverso Tor: un utente non può quindi prendere l’indirizzo .onion e aprirlo con una configurazione standard di Chrome collegato direttamente a Internet. Deve utilizzare Tor Browser oppure un’applicazione opportunamente configurata per instradare quella connessione attraverso Tor.

Con il VPS possiamo far apparire il server domestico come se disponesse, indirettamente, di un IP pubblico. Possiamo pubblicare selettivamente SSH, HTTPS o altre porte e costruire politiche di routing piuttosto sofisticate. Tor Onion Services lavora invece soprattutto con stream TCP associati alle porte configurate con HiddenServicePort.

Possiamo ad esempio scrivere quanto segue per rendere disponibili via Tor sia un server Web che un server SSH:

HiddenServicePort 80 127.0.0.1:8080
HiddenServicePort 22 127.0.0.1:22

Non stiamo però creando una normale interfaccia IP raggiungibile dalla rete pubblica. Protocolli che richiedono UDP o applicazioni che devono essere esposte direttamente sulla normale Internet non possono essere trasferiti automaticamente nello stesso modo.

Differenza tra VPS/WireGuard e Tor in termini di percorso dei pacchetti dati

Anche il percorso dei pacchetti è molto più lungo nel caso di Tor. Se scegliamo un VPS geograficamente vicino, il sovraccarico può rimanere contenuto; un Onion Service costruisce invece circuiti attraverso diversi relay Tor. Nella descrizione semplificata del Tor Project, il collegamento completo tra client e servizio può coinvolgere 6 relay: 3 scelti dal client e 3 dal servizio, con il rendezvous point che unisce i due circuiti.

Questa architettura privilegia privacy, occultamento della posizione e resistenza alla censura, non la minima latenza possibile.

Per amministrare occasionalmente un server, pubblicare un piccolo sito, esporre un’interfaccia Web privata o raggiungere un servizio domestico senza preoccuparsi di CGNAT può essere un compromesso interessante.

Per distribuire contenuti a un pubblico generico, trasferire grandi quantità di dati o offrire applicazioni sensibili alla latenza, un ingresso Internet tradizionale attraverso VPS può risultare molto più appropriato.

Un Onion Service può essere privato

Un indirizzo .onion non deve necessariamente diventare un sito pubblico da distribuire a chiunque: può rappresentare semplicemente un modo per raggiungere da remoto un’applicazione che gira a casa.

Possiamo ad esempio immaginare Home Assistant, Nextcloud, un pannello amministrativo, un server Git, un’interfaccia di monitoraggio in ascolto soltanto su localhost o sulla LAN e pubblicarne una porta tramite Onion Service. In tal caso non dobbiamo esporre direttamente il servizio su Internet e non dobbiamo neppure comunicare al mondo l’indirizzo IP della linea domestica.

Com’è ovvio, la conoscenza dell’indirizzo .onion non deve diventare l’unica misura di sicurezza adottata: le applicazioni che gestiscono dati personali e riservati devono continuare a usare un’autenticazione robusta. Gli Onion Services supportano inoltre meccanismi specifici di autorizzazione dei client per scenari nei quali non si vuole permettere l’accesso a chiunque conosca l’indirizzo.

Come pubblicare un server dietro CGNAT usando Tor

Lato server non va caricato Tor Browser: occorre installare il software Tor vero e proprio, quello che funziona come servizio di sistema.

Tor Project raccomanda, su Debian e Ubuntu, di utilizzare il repository ufficiale e quindi installare il pacchetto tor da questa fonte. Per Ubuntu è sconsigliato affidarsi alle vecchie versioni eventualmente disponibili nel repository universe, perché potrebbero non ricevere con la stessa tempestività aggiornamenti di stabilità e sicurezza.

Una volta configurato il repository appropriato, l’installazione vera e propria si riduce a impartire i comandi che seguono:

sudo apt update
sudo apt install tor

A questo punto Tor gira come daemon sul server Linux. Non abbiamo ancora creato alcun sito .onion: abbiamo soltanto installato il componente che permette alla macchina di partecipare alla rete Tor.

Prima di Tor serve un servizio locale

Supponiamo di avere nginx installato:

sudo apt install nginx

e di voler pubblicare la directory /srv/miosito.

Il punto importante consiste nel fare in modo che nginx ascolti soltanto sull’interfaccia locale, ad esempio:

server {
    listen 127.0.0.1:8080;

    root /srv/miosito;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Dopo aver salvato la configurazione si può controllarla e ricaricare nginx:

sudo nginx -t
sudo systemctl reload nginx

A questo punto, dalla macchina stessa il comando curl http://127.0.0.1:8080 deve restituire la pagina del sito. nginx non sta ascoltando sull’indirizzo IP della LAN né, tanto meno, su Internet: è accessibile soltanto dal server stesso.

Bastano due direttive nel file torrc

La configurazione principale di Tor si trova nel file /etc/tor/torrc, che abbiamo già citato in precedenza. Al suo interno possiamo aggiungere:

HiddenServiceDir /var/lib/tor/miosito/
HiddenServicePort 80 127.0.0.1:8080

La porta 80 è quella che vede chi visita il sito Onion; la destinazione 127.0.0.1:8080 è invece il servizio locale al quale Tor deve consegnare il traffico.

Riavviare Tor e ottenere l’indirizzo .onion

Dopo aver salvato torrc, bisogna riavviare Tor. Su molte installazioni è sufficiente impartire il comando sudo systemctl restart tor.

Se Tor parte correttamente, crea automaticamente la directory indicata in HiddenServiceDir e genera l’identità crittografica dell’Onion Service. Dentro la cartella /var/lib/tor/miosito/ compare, tra gli altri, il file chiamato hostname.

Per leggerlo dal terminale Linux, basta digitare:

sudo cat /var/lib/tor/miosito/hostname

Si ottiene un lungo indirizzo che finisce con .onion. Il nome non è acquistato presso un registrar e non deriva da una configurazione DNS: nasce dalle chiavi crittografiche generate per il servizio. A questo punto il sito è già online.

Da un altro computer si può aprire Tor Browser e incollare l’indirizzo recuperato dal file hostname: Tor Browser costruisce il circuito necessario e raggiunge l’Onion Service.

Conclusioni

Tor e WireGuard con VPS non risolvono il problema di CGNAT allo stesso modo.

Nel secondo caso si costruisce un vero punto di ingresso pubblico: il VPS riceve il traffico da Internet e lo inoltra al server domestico attraverso il tunnel. Con un Onion Service, invece, il server non deve risultare direttamente raggiungibile dall’esterno: gli basta poter stabilire connessioni in uscita verso la rete Tor.

Da qui deriva la notevole semplicità della configurazione. Non servono IPv4 pubblico, port forwarding, DNAT o un host intermedio; il servizio locale può persino restare in ascolto esclusivamente su 127.0.0.1. Per chi vuole raggiungere da remoto un server personale, SSH, un pannello di amministrazione o un’applicazione self-hosted, è una possibilità concreta e tecnicamente elegante.

Ci sono però dei compromessi. L’accesso richiede Tor lato client, il percorso attraverso più relay aumenta normalmente la latenza e un Onion Service non equivale a una normale interfaccia IP come quella ottenibile con WireGuard. Inoltre Tor non sostituisce le misure di sicurezza dell’applicazione: autenticazione robusta, aggiornamenti e protezione delle chiavi restano indispensabili.