L’IP di uscita di una VPN non prova un tunnel: cosa vedono i server

Qualcuno chiede un servizio raggiungibile solo dagli utenti VPN, e l’implementazione ovvia è consentire un elenco di indirizzi di uscita. L’elenco fa qualcosa di reale: limita chi può connettersi. Non dimostra che sia stato usato un tunnel, perché l’indirizzo appartiene a chi gestisce l’uscita e quell’operatore può inoltrare il traffico di chiunque. Il divario tra queste affermazioni è l’intero problema di progettazione.

Il server vede un indirizzo per connessione

Una connessione arriva con un indirizzo di origine e una porta di destinazione, e questo è tutto ciò che il livello di rete riporta. Quando un client usa un tunnel, i pacchetti che raggiungono il vostro listener provengono dall’uscita o dalla traduzione davanti a essa. L’indirizzo del client, di solito privato, non compare mai. Una regola del firewall scritta per l’intervallo della LAN del client quindi non fa assolutamente nulla.

Tutto ciò che segue quell’indirizzo di origine sono dati dell’applicazione, e l’applicazione può fidarsene solo nella misura in cui li autentica.

Verificate che aspetto ha la vostra uscita

Guardate il percorso da entrambe le estremità prima di scrivere una regola. La visione del client sulla propria uscita e quella del server sulla connessione sono i due fatti che contano.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Il primo comando riporta l’indirizzo pubblico con cui appare il client, ed è il valore che ogni elenco di autorizzati deve contenere. Il secondo mostra le connessioni stabilite sul server con gli indirizzi dei peer, ed è con questo che la regola corrisponderà davvero. Se i due non concordano con il vostro modello mentale, correggete il modello prima di modificare la politica. Un firewall di un database cloud, un elenco di autorizzati applicativo e un bilanciatore di carico possono ciascuno vedere uno strato di traduzione diverso.

Solo uno dei due insiemi di uscite può essere elencato

Un caso è verificabile al momento della richiesta e l’altro no, il che produce garanzie molto diverse.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

L’elenco pubblicato delle uscite Tor può essere scaricato e confrontato, in base all’età dell’elenco e alla politica di ciascuna uscita, perciò una regola di rifiuto verso uscite note è applicabile e verificabile. Non esiste un registro equivalente per le VPN commerciali. Gli indirizzi ruotano, molti fornitori non pubblicano nulla e un tunnel può girare su un indirizzo cloud affittato che non è mai appartenuto a una VPN. L’elenco che compilate è un’istantanea di indirizzi osservati, e ampliarlo a intervalli di hosting aggiunge carichi non correlati senza aggiungere prove.

Usate gli indirizzi come input di politica, non come prova

Decidete a cosa serve la regola. Una restrizione di rete dovrebbe restare stretta, registrare l’indirizzo osservato con data e motivo, e offrire agli utenti legittimi un percorso di recupero quando la loro uscita cambia. Il controllo degli accessi richiede un account autenticato o un token firmato, perché solo questi legano una richiesta a un’identità. La valutazione del rischio può usare l’indirizzo come un singolo segnale inaffidabile, accettandone i falsi positivi e i punti ciechi. Scrivere la regola come decisione di prodotto è onesto; scriverla come verifica che un tunnel esista non lo è.

La richiesta speculare, recuperare l’indirizzo reale dell’utente dietro una VPN, fallisce per lo stesso motivo: una connessione porta un indirizzo, e un cambiamento tra sessioni è compatibile con diverse spiegazioni. Trattate il valore precedente come storia, non come verità.