Come registrare e verificare l’indirizzo di uscita VPN usato

Chiedi a un client VPN desktop quali server hai usato e la risposta onesta di solito è un nome di località. Quel nome è il punto d’ingresso che hai composto, e l’indirizzo da cui è uscito il tuo traffico può essere una macchina del tutto diversa. Nell’app nulla è progettato per conservare il secondo numero, quindi il registro va costruito al momento dell’uso. Esistono due approcci, e solo uno sopravvive a una pratica di assistenza.

Due registri, e solo uno dei due esiste

La vista del client è al massimo un elenco di località scelte con marche temporali. È una scelta di progetto e non una svista: gli indirizzi sono dettagli operativi, ruotano tra le assegnazioni, ed esporre la corrispondenza rende più difficile sia l’assistenza sia la gestione degli abusi. I fornitori mettono istanze cloud davanti alle proprie reti proprio perché l’endpoint possa spostarsi senza dirlo a nessuno. Ciò che l’app ti mostra è la scelta che hai fatto, non il percorso seguito.

Il registro che puoi costruire è un file locale con un indirizzo pubblico e una marca temporale UTC per riga. È più piccolo, più brutto e molto più utile, perché descrive esattamente ciò che anche un osservatore esterno può vedere.

Opzione A: catturare da soli l’indirizzo di uscita

Un servizio di echo restituisce l’indirizzo sorgente da cui è arrivata la richiesta, che è per definizione l’indirizzo di uscita. Esegui la cattura dopo che il tunnel segnala connesso, perché un client che dice connesso prima che rotte e DNS si assestino registrerà l’indirizzo precedente al tunnel e avvelenerà il registro fin dalla prima riga.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Due dettagli rendono quel frammento utilizzabile anziché decorativo. Marca temporale e indirizzo condividono una riga, così un’analisi successiva non deve riaccoppiare i record, e umask 077 mantiene il file privato dal momento in cui viene creato. Eseguilo una volta per connessione invece di una volta per avvio, e tieni un file per dispositivo.

Il registro annota quando hai usato un tunnel e da quale rete sei apparso, il che è più vicino a una cronologia di navigazione che a un contatore. Scegli un periodo di conservazione che puoi difendere, tieni il file fuori dalle cartelle di sincronizzazione condivise e cancellalo deliberatamente.

Opzione B: chiedere uno storico al fornitore

Alcuni fornitori tengono registri di connessione e risponderanno a una domanda di assistenza con una marca temporale e un nome di server. Quel registro descrive la loro infrastruttura e non il tuo traffico, e vale solo quanto valgono la loro finestra di conservazione e la loro volontà di guardare. Descrive inoltre una sessione, non una richiesta. La finestra di solito è breve, e si misura dal lato fornitore del tunnel.

I fornitori che pubblicizzano l’assenza di log non possono produrlo su richiesta, e un elenco di località recenti lato client non è la stessa cosa. Chiedere un indirizzo di uscita a un fornitore senza log di solito finisce con una spiegazione del perché quei dati non esistono.

Che cosa può provare ciascun registro in una pratica di assistenza

I due registri rispondono a domande diverse, ed è nella tabella che il confronto smette di essere teorico.

Solo la prima colonna è sotto il tuo controllo. Un registro del fornitore può confermare che un account era connesso in un dato momento, ma non può confermare quali richieste abbiano usato il tunnel, e non nominerà un indirizzo che il fornitore tratta come dettaglio operativo. Nessuno dei due registri identifica una persona, perché un indirizzo di uscita condiviso può portare molti clienti nello stesso minuto.

Confronta entrambi con un riferimento prima di fidarti dell’uno o dell’altro

Un indirizzo da solo non prova nulla. Cattura l’indirizzo diretto prima di connetterti, quello incapsulato dopo, e confrontali. Valori identici significano che il tunnel non trasporta quella richiesta, che sia per uno split tunnel, per un proxy prevalente o per un client che è ripiegato su un percorso diretto.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Ripeti il confronto per DNS e per IPv6, perché un echo di indirizzo prova il percorso di una singola richiesta HTTP e nulla su quale resolver abbia risposto. Un dispositivo che perde su uno dei due può sembrare perfettamente sano sull’altro.