VPN prin DNS nu este același lucru cu un server DNS pentru VPN

VPN prin DNS descrie o idee de transport și nu este sinonim cu direcționarea unui dispozitiv către un resolver personalizat. Întrebarea care rezolvă confuzia este simplă: ce transportă de fapt mesajele DNS? Un VPN obișnuit poate instala un resolver pentru ca aplicațiile acoperite să găsească nume private, iar schimbarea acelui resolver schimbă doar rezolvarea numelor. Rulați verificările de mai jos în ordine, pentru că cele trei aranjamente împărtășesc vocabularul și aproape nimic altceva.

Separați cele trei aranjamente

În primul aranjament, VPN-ul furnizează un resolver sau o setare de politică a numelor. Datele aplicațiilor călătoresc în continuare pe propriile conexiuni de rețea, iar tunelul influențează doar ce server răspunde la interogare.

În al doilea, DNS criptat protejează schimbul DNS în sine. DNS prin HTTPS și DNS prin TLS înfășoară interogările către resolverul ales și nu transportă pachete ale niciunei alte aplicații. De asemenea, nu ascund numele interogărilor față de resolverul pe care l-ați ales, ceea ce este o altă graniță de încredere decât ascunderea lor față de rețeaua locală.

În al treilea, un client cooperant codifică alte date în mesaje DNS, iar un punct final cooperant le reconstruiește. Calea obișnuită a resolverului devine transportul, iar resolverul este acum o componentă a căii de date, nu un serviciu de nume.

Verificați ce transportă mesajele DNS

Schimbați resolverul și observați dacă se schimbă calea traficului aplicației. Dacă aplicația se conectează în continuare la aceleași adrese prin aceleași socketuri, ați schimbat rezolvarea numelor și nimic mai mult.

Un tunel transportat prin DNS are nevoie de un aranjament corespunzător pe partea serverului. Iodine este un exemplu documentat: documentația proiectului său descrie un tunel IP prin DNS și necesită o componentă de server care înțelege codificarea. Introducerea unei adrese de resolver public în Android nu oferă acel punct final, iar un termen de marketing comun pentru două produse nu este o specificație de protocol.

Captura este verificarea decisivă. Dacă vedeți interogări obișnuite către resolver și nimic altceva, nu există tunel. Dacă vedeți date codificate în numele interogărilor și în răspunsuri, ați găsit purtătorul, iar următoarea întrebare este cât poate muta.

Verificați capacitatea înainte de a vă angaja

DNS a fost proiectat pentru interogări și răspunsuri, nu pentru livrare în masă. Costul codificării, limitele de dimensiune ale mesajelor și comportamentul resolverului iau toate o parte din calea nominală, așa că capacitatea utilă este mai mică decât sugerează legătura de bază. Tratați orice cifră de debit pe care nu ați măsurat-o pe propria cale ca pe o ipoteză, nu ca pe un buget. Măsurați ambele direcții, pentru că încărcarea și descărcarea pot atinge limite diferite pe un purtător de tip cerere-răspuns.

Clientul trebuie să decidă și ce trafic intră în tunel. O interfață locală a serviciului VPN poate colecta pachete, dar interfața nu spune nimic despre modul în care transportul îndepărtat le protejează sau le redirecționează. Fragmentarea și retransmisia se comportă diferit când purtătorul este un protocol cerere-răspuns și nu un flux, iar o conexiune care rămâne deschisă spune puțin despre latența interactivă.

Măsurați cu traficul pe care intenționați să îl transportați. Un tunel care pare potrivit pentru un puls periodic poate fi inutilizabil pentru o sesiune interactivă, și inversul este de asemenea adevărat.

Verificați securitatea purtătorului

Nu presupuneți că încapsularea DNS oferă confidențialitate sau autentificare puternică. Calea resolverului și punctul final al tunelului văd ceea ce expune implementarea, iar această expunere variază în funcție de proiectare.

Criptarea și alegerea purtătorului sunt proprietăți separate. Un tunel poate fi criptat pe o cale IP simplă, iar un tunel transportat prin DNS poate fi construit cu sau fără protecție pentru încărcătura sa. Păstrați HTTPS-ul aplicației la locul lui în orice caz și evaluați proiectarea de securitate reală a tunelului, nu numele lui.

Dacă cerința este confidențialitatea față de rețeaua locală, DNS criptat și un tunel de date răspund unor părți diferite ale acesteia. Notați față de ce observator vă apărați înainte de a alege unul.

Potriviți remedierea cu defecțiunea reală

Pentru un VPN lent obișnuit, înlocuirea cu un tunel transportat prin DNS adaugă un transport restricționat peste problemă. Nu repară calitatea radio, congestia sau încărcarea serverului și de obicei le face mai vizibile.

Pentru defecțiuni ale numelor private, examinați mai întâi politica de resolver intenționată: ce server ar trebui să răspundă, ce nume sunt în domeniu și dacă clientul are voie să îl folosească. Apoi alegeți un transport autorizat care corespunde cerinței și păstrați configurația resolverului în jurnalul modificărilor, astfel încât incidentul următor să nu reia aceeași căutare.

Lista de verificare este scurtă: identificați aranjamentul, confirmați ce transportă mesajele, măsurați capacitatea și apoi revizuiți încrederea. Orice pas care nu corespunde simptomului înseamnă că celelalte două aranjamente sunt încă în joc.