VPN caur DNS apraksta transportēšanas ideju, un tas nav sinonīms tam, ka ierīce tiek novirzīta uz savu resolvētāju. Jautājums, kas atrisina neskaidrību, ir vienkāršs: ko DNS ziņojumi patiešām pārvieto? Parasts VPN var instalēt resolvētāju, lai aptvertās lietotnes atrastu privātus nosaukumus, un šī resolvētāja maiņa maina tikai nosaukumu izšķiršanu. Veiciet tālāk norādītās pārbaudes secīgi, jo trīs izkārtojumi dala terminoloģiju un gandrīz neko citu.

Atdaliet trīs izkārtojumus

Pirmajā izkārtojumā VPN nodrošina resolvētāju vai nosaukumu politikas iestatījumu. Lietotnes dati joprojām ceļo pa saviem tīkla savienojumiem, un tunelis ietekmē tikai to, kurš serveris atbild uz vaicājumu.

Otrajā šifrēts DNS aizsargā pašu DNS apmaiņu. DNS caur HTTPS un DNS caur TLS ietin vaicājumus izvēlētajā resolvētājā un nepārvieto nevienas citas lietotnes paketes. Tie arī neslēpj vaicājumu nosaukumus no jūsu izvēlētā resolvētāja, kas ir cita uzticēšanās robeža nekā slēpt tos no vietējā tīkla.

Trešajā sadarbojošs klients iekodē citus datus DNS ziņojumos, un sadarbojošs galapunkts tos atjauno. Parastais resolvētāja ceļš kļūst par transportu, un resolvētājs tagad ir datu ceļa sastāvdaļa, nevis nosaukumu pakalpojums.

Pārbaudiet, ko DNS ziņojumi pārvieto

Nomainiet resolvētāju un novērojiet, vai mainās lietotnes trafika ceļš. Ja lietotne joprojām savienojas ar tiem pašiem adresēm pa tiem pašiem ligzdām, jūs mainījāt nosaukumu izšķiršanu un neko vairāk.

Tunelim, ko pārvieto DNS, nepieciešams atbilstošs servera puses izkārtojums. Iodine ir dokumentēts piemērs: tā projekta dokumentācija apraksta IP tuneli caur DNS, un tam nepieciešama servera komponente, kas saprot kodējumu. Publiska resolvētāja adreses ievadīšana Android nenodrošina šo galapunktu, un divu produktu kopīgs mārketinga termins nav protokola specifikācija.

Uztveršana ir izšķirošā pārbaude. Ja redzat parastus vaicājumus resolvētājam un neko citu, tuneļa nav. Ja redzat lietderīgo slodzi, kas iekodēta vaicājumu nosaukumos un atbildēs, jūs esat atradis nesēju, un nākamais jautājums ir, cik daudz tas var pārvietot.

Pārbaudiet ietilpību pirms saistībām

DNS tika izstrādāts vaicājumiem un atbildēm, nevis lielapjoma piegādei. Kodēšanas izmaksas, ziņojuma izmēra ierobežojumi un resolvētāja uzvedība visi paņem savu daļu no nominālā ceļa, tāpēc lietderīgā ietilpība ir zemāka, nekā liecina pamata saite. Jebkuru caurlaidspējas skaitli, ko neesat izmērījis savā ceļā, uzskatiet par hipotēzi, nevis budžetu. Mēriet abus virzienus, jo augšupielāde un lejupielāde var saskarties ar dažādiem ierobežojumiem vaicājuma-atbildes nesējā.

Klientam arī jāizlemj, kurš trafiks nonāk tunelī. Vietējā VPN pakalpojuma saskarne var savākt paketes, bet saskarne neko nepasaka par to, kā attālinātais transports tās aizsargā vai pārsūta. Fragmentācija un atkārtota pārsūtīšana uzvedas citādi, ja nesējs ir vaicājuma-atbildes protokols, nevis plūsma, un atvērts paliekošs savienojums maz pasaka par interaktīvu aizkavi.

Mēriet ar to trafiku, ko plānojat pārvietot. Tunelis, kas šķiet piemērots periodiskam sirdspukstam, var būt nederīgs interaktīvai sesijai, un otrādi arī ir taisnība.

Pārbaudiet nesēja drošību

Nepieņemiet, ka DNS iekapsulēšana nodrošina konfidencialitāti vai spēcīgu autentifikāciju. Resolvētāja ceļš un tuneļa galapunkts redz to, ko atklāj ieviešana, un šī atklāšana atšķiras atkarībā no dizaina.

Šifrēšana un nesēja izvēle ir atsevišķas īpašības. Tuneli var šifrēt vienkāršā IP ceļā, un caur DNS pārvietotu tuneli var veidot ar lietderīgās slodzes aizsardzību vai bez tās. Jebkurā gadījumā saglabājiet lietotnes HTTPS un novērtējiet tuneļa faktisko drošības dizainu, nevis tā nosaukumu.

Ja prasība ir privātums no vietējā tīkla, šifrēts DNS un datu tunelis atbild uz dažādām tā daļām. Pirms izvēlaties vienu, pierakstiet, pret kuru novērotāju jūs aizsargājaties.

Saskaņojiet labojumu ar faktisko kļūmi

Parastam lēnam VPN aizstāšana ar caur DNS pārvietotu tuneli pievieno ierobežotu transportu problēmas virsū. Tas nelabo radio kvalitāti, pārslodzi vai servera slodzi un parasti padara tās pamanāmākas.

Privātu nosaukumu kļūmēm vispirms pārbaudiet paredzēto resolvētāja politiku: kuram serverim jāatbild, kuri nosaukumi ir tvērumā un vai klientam to atļauts lietot. Pēc tam izvēlieties prasībai atbilstošu atļautu transportu un glabājiet resolvētāja konfigurāciju izmaiņu žurnālā, lai nākamais incidents nesāktu to pašu meklēšanu no jauna.

Kontrolsaraksts ir īss: identificējiet izkārtojumu, apstipriniet, ko pārvieto ziņojumi, izmēriet ietilpību un pēc tam pārskatiet uzticēšanos. Jebkurš solis, kas neatbilst simptomam, nozīmē, ka pārējie divi izkārtojumi joprojām ir spēlē.

Saistītie raksti