VPN per DNS nėra tas pats kaip VPN DNS serveris

VPN per DNS apibūdina transportavimo idėją ir nėra sinonimas tam, kad įrenginys nukreipiamas į savą resolverį. Painiavą išsprendžiantis klausimas paprastas: ką DNS pranešimai iš tikrųjų perneša? Įprastas VPN gali įdiegti resolverį, kad aprėptos programos rastų privačius vardus, o to resolverio pakeitimas keičia tik vardų skyrimą. Atlikite toliau pateiktus patikrinimus iš eilės, nes trys išdėstymai dalijasi terminija ir beveik niekuo kitu.

Atskirkite tris išdėstymus

Pirmajame išdėstyme VPN pateikia resolverį arba vardų politikos nuostatą. Programos duomenys vis dar keliauja savo tinklo ryšiais, o tunelis veikia tik tai, kuris serveris atsako į užklausą.

Antrajame šifruotas DNS saugo patį DNS mainus. DNS per HTTPS ir DNS per TLS apgaubia užklausas pasirinktam resolveriui ir neperneša jokios kitos programos paketų. Jie taip pat neslepia užklausų vardų nuo pasirinkto resolverio, o tai yra kita pasitikėjimo riba nei slėpti juos nuo vietinio tinklo.

Trečiajame bendradarbiaujantis klientas užkoduoja kitus duomenis DNS pranešimuose, o bendradarbiaujantis galinis taškas juos atkuria. Įprastas resolverio kelias tampa transportu, o resolveris dabar yra duomenų kelio dalis, o ne vardų tarnyba.

Patikrinkite, ką perneša DNS pranešimai

Pakeiskite resolverį ir stebėkite, ar keičiasi programos srauto kelias. Jei programa vis dar jungiasi prie tų pačių adresų tais pačiais lizdais, pakeitėte vardų skyrimą ir nieko daugiau.

Tuneliui, pernešamam per DNS, reikia atitinkamo serverio pusės išdėstymo. Iodine yra dokumentuotas pavyzdys: jo projekto dokumentacija aprašo IP tunelį per DNS, ir jam reikia serverio komponento, kuris supranta kodavimą. Viešo resolverio adreso įvedimas Android sistemoje nesuteikia to galinio taško, o dviejų produktų bendras rinkodaros terminas nėra protokolo specifikacija.

Užfiksavimas yra lemiamas patikrinimas. Jei matote įprastas užklausas resolveriui ir nieko daugiau, tunelio nėra. Jei matote naudingąją apkrovą, užkoduotą užklausų varduose ir atsakymuose, radote nešėją, o kitas klausimas yra, kiek jis gali perkelti.

Patikrinkite talpą prieš įsipareigodami

DNS buvo sukurtas užklausoms ir atsakymams, o ne masiniam pristatymui. Kodavimo sąnaudos, pranešimų dydžio ribos ir resolverio elgsena visi pasiima savo dalį nominalaus kelio, todėl naudingoji talpa mažesnė, nei leidžia manyti pagrindinė jungtis. Bet kokį pralaidumo skaičių, kurio neišmatavote savo kelyje, laikykite hipoteze, o ne biudžetu. Matuokite abi kryptis, nes siuntimas ir atsisiuntimas gali susidurti su skirtingomis ribomis užklausos-atsakymo nešėjuje.

Klientas taip pat turi nuspręsti, kuris srautas patenka į tunelį. Vietinė VPN tarnybos sąsaja gali rinkti paketus, tačiau sąsaja nieko nesako apie tai, kaip nuotolinis transportas juos apsaugo ar persiunčia. Fragmentavimas ir pakartotinis perdavimas elgiasi kitaip, kai nešėjas yra užklausos-atsakymo protokolas, o ne srautas, o atvira liekanti jungtis mažai pasako apie interaktyvų vėlavimą.

Matuokite tuo srautu, kurį ketinate pernešti. Tunelis, kuris atrodo tinkamas periodiniam širdies plakimui, gali būti netinkamas interaktyviai sesijai, ir atvirkščiai.

Patikrinkite nešėjo saugumą

Nemanau, kad DNS inkapsuliavimas suteikia konfidencialumą ar stiprią autentifikaciją. Resolverio kelias ir tunelio galinis taškas mato tai, ką atskleidžia įgyvendinimas, o tas atskleidimas skiriasi priklausomai nuo dizaino.

Šifravimas ir nešėjo pasirinkimas yra atskiros savybės. Tunelį galima šifruoti paprastame IP kelyje, o per DNS pernešamą tunelį galima sukurti su apkrovos apsauga arba be jos. Bet kuriuo atveju palikite programos HTTPS vietoje ir vertinkite tikrąjį tunelio saugumo dizainą, o ne jo pavadinimą.

Jei reikalavimas yra privatumas nuo vietinio tinklo, šifruotas DNS ir duomenų tunelis atsako į skirtingas jo dalis. Prieš pasirinkdami vieną, užsirašykite, nuo kurio stebėtojo ginatės.

Pritaikykite pataisą tikram gedimui

Įprastam lėtam VPN pakeitimas per DNS pernešamu tuneliu prideda ribotą transportą virš problemos. Jis netaiso radijo kokybės, perkrovos ar serverio apkrovos ir paprastai daro juos labiau pastebimus.

Privačių vardų gedimams pirmiausia patikrinkite numatytą resolverio politiką: kuris serveris turėtų atsakyti, kurie vardai patenka į apimtį ir ar klientui leidžiama juo naudotis. Tada pasirinkite reikalavimą atitinkantį įgaliotą transportą ir laikykite resolverio konfigūraciją pakeitimų įraše, kad kitas incidentas nepradėtų tos pačios paieškos iš naujo.

Kontrolinis sąrašas trumpas: nustatykite išdėstymą, patvirtinkite, ką perneša pranešimai, išmatuokite talpą, tada peržiūrėkite pasitikėjimą. Bet kuris žingsnis, neatitinkantis simptomo, reiškia, kad kiti du išdėstymai vis dar žaidime.