Una VPN su DNS non è la stessa cosa di un server DNS per VPN

Una VPN su DNS descrive un’idea di trasporto e non è sinonimo di puntare un dispositivo verso un risolutore personalizzato. La domanda che risolve la confusione è semplice: cosa trasportano davvero i messaggi DNS? Una VPN ordinaria può installare un risolutore affinché le applicazioni coperte trovino nomi privati, e cambiare quel risolutore cambia solo la risoluzione dei nomi. Eseguite i controlli qui sotto in ordine, perché le tre disposizioni condividono il vocabolario e quasi nient’altro.

Separate le tre disposizioni

Nella prima disposizione, la VPN fornisce un risolutore o un’impostazione di politica dei nomi. I dati delle applicazioni viaggiano ancora sulle proprie connessioni di rete, e il tunnel influenza solo quale server risponde alla ricerca.

Nella seconda, il DNS cifrato protegge lo scambio DNS stesso. DNS su HTTPS e DNS su TLS avvolgono le query verso il risolutore scelto e non trasportano pacchetti di altre applicazioni. Non nascondono nemmeno i nomi delle query al risolutore che avete scelto, il che è un confine di fiducia diverso dal nasconderli alla rete locale.

Nella terza, un client collaborante codifica altri dati in messaggi DNS e un endpoint collaborante li ricostruisce. Il percorso ordinario del risolutore diventa il trasporto, e il risolutore ora è un componente del percorso dati invece di un servizio di nomi.

Verificate cosa trasportano i messaggi DNS

Cambiate il risolutore e osservate se cambia il percorso del traffico dell’applicazione. Se l’applicazione si connette ancora agli stessi indirizzi tramite gli stessi socket, avete cambiato la risoluzione dei nomi e nient’altro.

Un tunnel trasportato dal DNS richiede una disposizione corrispondente sul lato server. Iodine è un esempio documentato: la sua documentazione del progetto descrive un tunnel IP attraverso il DNS, e richiede un componente server che comprenda la codifica. Inserire un indirizzo di risolutore pubblico in Android non fornisce quell’endpoint, e un termine di marketing condiviso da due prodotti non è una specifica di protocollo.

La cattura è il controllo decisivo. Se vedete query ordinarie verso il risolutore e nient’altro, non c’è alcun tunnel. Se vedete carico codificato nei nomi delle query e nelle risposte, avete trovato il vettore, e la domanda successiva è quanto può spostare.

Verificate la capacità prima di impegnarvi

Il DNS è stato progettato per query e risposte, non per la consegna in blocco. Il sovraccarico di codifica, i limiti di dimensione dei messaggi e il comportamento del risolutore prendono tutti la loro parte del percorso nominale, quindi la capacità utile è inferiore a quanto suggerisce il collegamento sottostante. Trattate ogni cifra di velocità che non avete misurato sul vostro percorso come un’ipotesi e non come un budget. Misurate entrambe le direzioni, perché upload e download possono incontrare limiti diversi su un vettore di tipo richiesta-risposta.

Il client deve anche decidere quale traffico entra nel tunnel. Un’interfaccia locale del servizio VPN può raccogliere pacchetti, ma l’interfaccia non dice nulla su come il trasporto remoto li protegga o li inoltri. La frammentazione e la ritrasmissione si comportano diversamente quando il vettore è un protocollo richiesta-risposta invece di un flusso, e una connessione che resta aperta dice poco sulla latenza interattiva.

Misurate con il traffico che intendete trasportare. Un tunnel che va bene per un battito periodico può essere inutilizzabile per una sessione interattiva, e vale anche il contrario.

Verificate la sicurezza del vettore

Non date per scontato che l’incapsulamento DNS fornisca riservatezza o autenticazione forte. Il percorso del risolutore e l’endpoint del tunnel vedono ciò che l’implementazione espone, e tale esposizione varia a seconda del progetto.

La cifratura e la scelta del vettore sono proprietà separate. Un tunnel può essere cifrato su un percorso IP semplice, e un tunnel trasportato dal DNS può essere costruito con o senza protezione del suo carico. Mantenete comunque l’HTTPS dell’applicazione al suo posto, e valutate il progetto di sicurezza reale del tunnel e non il suo nome.

Se il requisito è la riservatezza rispetto alla rete locale, il DNS cifrato e un tunnel dati rispondono a parti diverse di essa. Annotate contro quale osservatore vi difendete prima di sceglierne uno.

Adattate la correzione al guasto reale

Per una VPN lenta ordinaria, sostituirla con un tunnel trasportato dal DNS aggiunge un trasporto limitato sopra il problema. Non ripara la qualità radio, la congestione o il carico del server, e di solito li rende più visibili.

Per i guasti dei nomi privati, esaminate prima la politica del risolutore prevista: quale server deve rispondere, quali nomi rientrano nell’ambito e se il client è autorizzato a usarlo. Poi scegliete un trasporto autorizzato che corrisponda al requisito, e conservate la configurazione del risolutore nel registro delle modifiche affinché l’incidente successivo non riavvii la stessa ricerca.

La lista di controllo è breve: identificate la disposizione, confermate cosa trasportano i messaggi, misurate la capacità, poi rivedete la fiducia. Qualsiasi passo che non corrisponda al sintomo significa che le altre due disposizioni sono ancora in gioco.