VPN o proxy: cosa copre ciascuno e cosa no

Sia una VPN sia un proxy diretto cambiano l'indirizzo che vede un sito web, ed è lì che si fermano la maggior parte dei confronti. La differenza che decide la tua configurazione è la copertura: un proxy diretto è un intermediario che la tua applicazione sceglie di usare, a differenza del proxy inverso che sta davanti a un sito web, mentre una VPN sposta tutto ciò che il sistema operativo instrada in un tunnel. Cifratura, gestione del DNS e comportamento in caso di guasto derivano tutti da questa divisione. Esegui questi cinque controlli in ordine, e il primo che fallisce ti dirà quale strumento ti serve davvero.

Quali app copre l'intermediario?

Un'estensione proxy del browser vale solo per quel profilo del browser. I client di posta, i gestori di pacchetti e un secondo browser continuano a usare le proprie impostazioni, e alcune applicazioni ignorano del tutto le variabili proxy di sistema. Una VPN copre ciò che la tabella di routing invia nel tunnel, che può essere tutte le applicazioni o un sottoinsieme in tunnel diviso a seconda delle rotte e della policy del client.

Prova le applicazioni che contano invece di generalizzare da un singolo caricamento di pagina. curl https://ifconfig.me segue le variabili proxy dell'ambiente; un'app desktop potrebbe non farlo. Su Windows, netsh winhttp show proxy stampa il proxy WinHTTP usato dai servizi, e questa è un'impostazione diversa da quella del browser.

Il salto è cifrato, e dove termina TLS?

Un protocollo proxy è un punto d'incontro, non una garanzia. SOCKS5 inoltra TCP senza cifrarlo, e un proxy HTTP semplice trasporta la riga di richiesta e le intestazioni in chiaro. HTTPS attraverso un proxy usa CONNECT, quindi la tua sessione TLS termina comunque a destinazione, non al proxy. La guida MDN sui server proxy e il tunneling descrive questa distinzione dal lato del protocollo.

Una VPN cifra il tratto tra il tuo dispositivo e il suo endpoint. Oltre l'endpoint valgono le stesse regole di qualsiasi altra rete, ed è per questo che un tunnel da solo non protegge un'applicazione che invia credenziali su HTTP semplice. Nessuno dei due progetti nasconde un account connesso, un cookie o un'impronta del browser.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

L'output dettagliato mostra se curl ha inviato CONNECT alla porta 443 o un GET semplice con un URL completo. Con socks5h:// il proxy riceve il nome host dentro la richiesta SOCKS5 e poi inoltra un TLS che non può leggere, quindi vede il nome e il conteggio dei byte. Attraverso un proxy http://, un URL https:// è un CONNECT, quindi anche quel proxy vede il nome e il volume della destinazione, ma non la richiesta né il corpo della risposta.

Quale resolver vede il nome?

La risoluzione dei nomi può avvenire localmente prima che la richiesta parta, oppure in remoto al proxy. Con curl, socks5h:// invia il nome host al proxy mentre socks5:// lo risolve prima localmente. Le impostazioni proxy del browser offrono un'opzione DNS paragonabile, e i file PAC possono instradare host diversi in modi diversi.

Due protocolli possono aggirare un proxy senza alcun errore di configurazione. WebRTC raccoglie candidati tramite STUN, e QUIC esegue HTTP/3 su UDP, che un proxy TCP non può trasportare. Il browser tornerà a TCP se UDP 443 è bloccato, quindi bloccare UDP 443 nel firewall dell'host (o nel router per un'intera rete), e non un flag del browser, è il modo affidabile per mantenere HTTP/3 nel percorso del proxy.

Controlla il resolver dal punto di vista della destinazione, non del tuo portatile. Una richiesta che arriva con l'indirizzo di uscita del proxy ma con un nome risolto localmente dice comunque al resolver locale quali siti visiti.

Cosa succede quando l'intermediario si guasta?

Un proxy esplicito fallisce chiuso: ferma il processo del proxy e il browser o l'app restituisce un errore di connessione invece di andare diretto. Le configurazioni PAC e WPAD sono quelle che falliscono aperte - se lo script non può essere recuperato, il client torna a DIRECT e il sito vede di nuovo il tuo indirizzo reale. Una VPN può fallire aperta o chiusa a seconda del client e se è attivo un kill switch o una regola del firewall.

Prova il caso di guasto di proposito: ferma il servizio proxy e ricarica; se ottieni una pagina di errore invece di un caricamento diretto, punta l'URL del PAC su un host irraggiungibile per vedere il ripiego. Se la pagina si carica ancora tramite il tuo percorso abituale, il proxy non offre alcuna protezione contro il proprio disservizio, e questa è una proprietà che dovresti conoscere prima di affidarti ad esso.

L'ordine decide cosa vede il sito. Un proxy il cui traffico in uscita passa per la VPN lascia al sito l'indirizzo dell'endpoint VPN; metti il proxy fuori dal tunnel (VPN verso un proxy su un host remoto) e il sito vedrà invece l'indirizzo di uscita di quel proxy. In entrambi i casi i due salti possono registrare cose diverse.

Cinque controlli, in ordine

La lista di controllo qui sotto è tutta la decisione in un solo posto. La copertura viene per prima perché elimina la maggior parte delle incongruenze: se l'app da coprire non rispetta l'impostazione, nulla più avanti nella lista la salva.

Poi conferma il risultato con l'app che ha motivato il cambiamento. Carica una pagina nel browser configurato, recupera la stessa pagina con curl e confronta l'indirizzo riportato da ciascuno. Se non coincidono, c'è ancora un'estensione, una regola PAC o una sovrascrittura a livello di app in gioco, e nessuna messa a punto del tunnel lo risolverà.

Annota cosa hai configurato: quali app usano il proxy, se il DNS è locale o remoto, se UDP è bloccato e qual è il comportamento in caso di guasto. Quel piccolo inventario è ciò che rende possibile il confronto successivo, perché «l'IP è cambiato» non ti ha mai detto quale di questi cinque controlli fosse superato.