Cosa può e cosa non può dimostrare un nome host VPN pubblico

I nomi host e le bandiere dei paesi sembrano fatti su un server, e nessuno dei due lo è. Un nome punta a indirizzi che possono cambiare, e le parole al suo interno le ha scelte chi lo ha registrato. Il protocollo, la posizione di uscita e il comportamento di registrazione hanno ciascuno bisogno delle proprie prove. Partite da ciò a cui il nome risolve davvero, poi decidete cosa resta sconosciuto.

Il nome risolve, e nient'altro è stabilito

Un nome host è un puntatore nel DNS, e i record dietro di esso possono variare secondo il resolver, secondo l'ora del giorno e secondo la famiglia di indirizzi preferita dal client. Due persone che leggono la stessa voce di elenco possono legittimamente raggiungere macchine diverse. Il nome dice cosa chiedere, non cosa risponderà.

Anche i risultati delle ricerche cambiano senza avviso, cosa che conta quando un profilo fissa un indirizzo invece del nome. Un profilo che incorpora il vecchio indirizzo continua a fallire dopo che l'operatore sposta il servizio, e il guasto sembra una porta bloccata. Tenete gli indirizzi risolti accanto al profilo, così che un confronto successivo abbia una base. Niente di tutto ciò dice chi gestisce l'altro capo.

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

Trasporto e identità sono domande separate

Una pagina web aperta sul nome host prova un solo listener su una sola porta. OpenVPN, IPsec e SSTP ascoltano altrove, sulle proprie porte e con i propri protocolli, quindi un server web raggiungibile non dice nulla su di loro.

La voce di elenco e il profilo devono concordare su trasporto, porta e credenziali. L'identità è verificata dalla catena di certificati o dall'impronta della chiave del peer con cui è stato configurato il client, non dalla scrittura del nome host. Un nome che contiene una parola di progetto familiare dimostra solo che qualcuno lo ha registrato. Leggete il certificato che il servizio presenta e confrontate emittente e soggetto con ciò che il profilo si aspetta.

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

Le parole dei paesi non sono un controllo della posizione

Un'etichetta jp o de in un elenco è una registrazione, e i database di geolocalizzazione IP sono abbastanza spesso discordanti che nessuno dei due merita di essere trattato come verità assoluta. Hosting condiviso, anycast e una semplice configurazione errata spostano tutti la posizione osservata lontano dall'etichetta.

La prova pratica è il percorso proprio dell'applicazione: quale indirizzo raggiunge e cosa mostra un controllo dell'indirizzo di uscita dall'interno della sessione. Un indirizzo di uscita osservato è una proprietà della rotta in quel momento, non una garanzia legata al nome. Gli elenchi di volontari aggiungono un altro strato, perché chi ha registrato una scheda non deve essere per forza chi gestisce la macchina. Annotate cosa avete misurato e quando, invece di ciò che la scheda prometteva.

Verificate il servizio offerto, poi l'operatore

Una volta stabiliti trasporto e identità, la domanda che resta è il comportamento dell'operatore, e questo richiede prove documentali invece di inferenze. Una politica sulla privacy, un contatto pubblicato e un avviso di trasparenza sono prove di intento; nessuna dimostra la pratica, e l'assenza di tutte e tre è anch'essa informazione.

Per un nodo pubblico o gestito da volontari, date per scontato che l'uscita sia condivisa e che chi lo gestisce possa vedere ciò che vi passa. Quell'assunzione, e non il nome host, deve decidere cosa inviate nel tunnel.

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

Tenete il nome per ciò in cui è bravo: trovare un endpoint e connettersi. Tutto il resto va provato separatamente, il giorno in cui conta.