VPN sobre DNS no és el mateix que un servidor DNS de VPN

VPN sobre DNS descriu una idea de transport i no és sinònim de dirigir un dispositiu a un resolutor personalitzat. La pregunta que resol la confusió és simple: què transporten realment els missatges DNS? Una VPN ordinària pot instal·lar un resolutor perquè les aplicacions cobertes trobin noms privats, i canviar aquest resolutor només canvia la resolució de noms. Feu les comprovacions següents en ordre, perquè les tres disposicions comparteixen vocabulari i gairebé res més.

Separeu les tres disposicions

En la primera disposició, la VPN proporciona un resolutor o un paràmetre de política de noms. Les dades de l'aplicació continuen viatjant per les seves pròpies connexions de xarxa, i el túnel només influeix en quin servidor respon la consulta.

En la segona, el DNS xifrat protegeix el bescanvi DNS mateix. DNS sobre HTTPS i DNS sobre TLS embolcallen les consultes al resolutor triat i no transporten paquets de cap altra aplicació. Tampoc no amaguen els noms de consulta al resolutor que heu triat, cosa que és una frontera de confiança diferent d'amagar-los de la xarxa local.

En la tercera, un client cooperant codifica altres dades en missatges DNS i un extrem cooperant les reconstrueix. El camí ordinari del resolutor es converteix en el transport, i el resolutor ara és un component del camí de dades en lloc d'un servei de noms.

Comproveu què transporten els missatges DNS

Canvieu el resolutor i observeu si canvia el camí del trànsit de l'aplicació. Si l'aplicació encara es connecta a les mateixes adreces pels mateixos sockets, heu canviat la resolució de noms i res més.

Un túnel transportat pel DNS necessita una disposició corresponent al costat del servidor. Iodine n'és un exemple documentat: la seva documentació del projecte descriu un túnel IP a través del DNS i requereix un component de servidor que entengui la codificació. Introduir una adreça de resolutor públic a Android no proporciona aquest extrem, i un terme de màrqueting compartit per dos productes no és una especificació de protocol.

La captura és la comprovació decisiva. Si veieu consultes ordinàries al resolutor i res més, no hi ha túnel. Si veieu càrrega codificada en noms de consulta i respostes, heu trobat el portador, i la pregunta següent és quant pot moure.

Comproveu la capacitat abans de comprometre-us

El DNS es va dissenyar per a consultes i respostes, no per a lliurament massiu. La sobrecàrrega de codificació, els límits de mida dels missatges i el comportament del resolutor prenen la seva part del camí nominal, així que la capacitat útil és inferior al que suggereix l'enllaç subjacent. Tracteu qualsevol xifra de rendiment que no hàgiu mesurat al vostre propi camí com una hipòtesi i no com un pressupost. Mesureu les dues direccions, perquè la pujada i la baixada poden topar amb límits diferents en un portador de petició-resposta.

El client també ha de decidir quin trànsit entra al túnel. Una interfície local del servei VPN pot recollir paquets, però la interfície no diu res sobre com el transport remot els protegeix o els reenvia. La fragmentació i la retransmissió es comporten diferent quan el portador és un protocol de petició-resposta i no un flux, i una connexió que es manté oberta diu poc sobre la latència interactiva.

Mesureu amb el trànsit que penseu transportar. Un túnel que va bé per a un batec periòdic pot ser inservible per a una sessió interactiva, i el contrari també és cert.

Comproveu la seguretat del portador

No assumiu que l'encapsulament DNS proporcioni confidencialitat o autenticació forta. El camí del resolutor i l'extrem del túnel veuen què exposa la implementació, i aquesta exposició varia segons el disseny.

El xifratge i l'elecció del portador són propietats separades. Un túnel es pot xifrar sobre un camí IP pla, i un túnel transportat pel DNS es pot construir amb o sense protecció per a la seva càrrega. Mantingueu l'HTTPS de l'aplicació al seu lloc de tota manera, i avalueu el disseny de seguretat real del túnel i no el seu nom.

Si el requisit és privacitat respecte de la xarxa local, el DNS xifrat i un túnel de dades responen a parts diferents d'això. Anoteu contra quin observador us defenseu abans de triar-ne un.

Adapteu la solució a la fallada real

Per a una VPN lenta ordinària, substituir-la per un túnel transportat pel DNS afegeix un transport restringit a sobre del problema. No repara la qualitat de ràdio, la congestió ni la càrrega del servidor, i normalment les fa més visibles.

Per a les fallades de noms privats, reviseu primer la política de resolutor prevista: quin servidor ha de respondre, quins noms estan dins l'abast i si el client té permís per utilitzar-lo. Després trieu un transport autoritzat que coincideixi amb el requisit, i conserveu la configuració del resolutor al registre de canvis perquè el proper incident no reiniciï la mateixa cerca.

La llista de comprovacions és curta: identifiqueu la disposició, confirmeu què transporten els missatges, mesureu la capacitat i després reviseu la confiança. Qualsevol pas que no coincideixi amb el símptoma vol dir que les altres dues disposicions encara són presents.