Servizio Onion contro servizio VPN: modelli di accesso diversi

Le persone descrivono un servizio Onion e un servizio raggiungibile solo via VPN come due varianti della stessa idea: nascondere la porta, condividere l'indirizzo segreto. Differiscono in ciò a cui è legato l'indirizzo, chi può raggiungerlo e cosa deve accadere prima che arrivi una richiesta. Uno è un punto d'incontro dentro Tor, l'altro è una rotta dentro una rete privata. Trattarli come intercambiabili produce progetti che non sono né privati né mantenibili.

Il mito: entrambi i progetti sono solo una porta nascosta

La proprietà condivisa è reale ma sottile: nessuno dei due progetti colloca l'interfaccia amministrativa su una porta pubblica direttamente raggiungibile. Tutto il resto diverge. Un indirizzo Onion deriva dalla chiave propria del servizio, quindi il nome è legato a un'identità; un indirizzo VPN è solo un indirizzo dentro una rete in cui siete stati ammessi. Uno nasconde il servizio dentro un livello sovrapposto, l'altro vi ammette in una topologia privata. Trattare il secondo come sinonimo del primo è dove inizia la confusione.

Nessuna delle due proprietà è un controllo di sicurezza per l'applicazione stessa. Una posizione nascosta non corregge il software dietro di essa, e una rotta privata non aggiunge autenticazione alla pagina di accesso. Entrambi i progetti hanno ancora bisogno dei permessi dell'applicazione, ed entrambi hanno ancora bisogno di qualcuno responsabile degli aggiornamenti e del ripristino.

A cosa punta davvero un indirizzo Onion

Un indirizzo Onion di versione v3 codifica la chiave pubblica del servizio, perciò nessuno può scegliere un indirizzo per un servizio che non controlla. Il client si connette tramite Tor a un punto d'incontro, e il servizio raggiunge lo stesso punto dal suo lato; nessun nodo d'uscita ordinario porta quella connessione fino al servizio. Il nome è un'identità, non un record DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Per questo aggiungere una rotta o una voce hosts per un nome onion non serve a nulla. La risoluzione non è il meccanismo; lo sono il client Tor e i suoi circuiti. Se il servizio è pensato per un piccolo gruppo di persone, l'autorizzazione client onion può richiedere una chiave prima che la connessione sia accettata, ma non è ancora l'accesso all'applicazione. Pubblicare l'indirizzo è anch'esso un atto deliberato, perché chiunque lo impari può tentare una connessione a meno che non l'abbiate limitata.

Fermatevi se l'unica ragione del progetto onion è evitare di configurare l'autenticazione. Il livello sovrapposto non lo fornisce, e lo costruirete comunque più avanti.

Cosa concede davvero una rotta VPN

Una VPN ammette un dispositivo in una rete e gli dà una rotta verso un gateway o una sottorete. Il servizio dietro quel gateway vede un indirizzo dal pool del tunnel e applica l'autorizzazione che ha. La rotta non dice nulla su chi sia l'utente; dice dove possono andare i pacchetti.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Quel modello si adatta a un gruppo noto con dispositivi gestiti, perché il gateway può imporre lo stato del dispositivo e la rete può essere verificata. Si adatta male a visitatori anonimi o occasionali, che andrebbero prima registrati. L'accesso dell'applicazione stessa decide ancora cosa può leggere un utente connesso. Confondere la raggiungibilità con il permesso è il modo in cui una VPN finisce per concedere un'intera sottorete a chiunque possa connettersi.

Fermatevi se il pubblico è sconosciuto o cambia continuamente. Registrare estranei in una rete privata per mostrare loro una pagina è un impegno grande rispetto alla pubblicazione di un servizio.

Scegliere tra i due, e cosa resta uguale

Scegliete il modello onion quando il pubblico è tecnico, il servizio non deve avere alcun indirizzo pubblico e potete accettare i requisiti del client Tor. Scegliete il modello VPN quando il pubblico è un gruppo definito di cui gestite i dispositivi e di cui volete registrare l'accesso a livello di rete. Nessuna delle due scelte elimina il bisogno di autenticazione dell'applicazione, di patch o di un percorso di ripristino. Nessuna è automaticamente più privata nel senso che conta per i vostri utenti.

In entrambi i progetti, annotate chi può raggiungere il servizio, come vengono identificati e cosa succede quando una credenziale va persa. La risposta per un servizio onion comprende le sue chiavi di autorizzazione client e l'indirizzo stesso; la risposta per una VPN comprende l'account, il dispositivo e la politica del gateway. Sono inventari diversi, e solo uno di essi sarà ovvio per il prossimo amministratore.

Il confronto finisce dove inizia l'applicazione. Un indirizzo nascosto e una rotta privata sono scelte di trasporto, e l'applicazione deve ancora decidere cosa può fare una richiesta. Tenete queste decisioni in documenti separati e nessuno dei due progetti assorbirà silenziosamente il lavoro dell'altro.