VPN üle DNS ei ole sama mis VPN-i DNS-server

VPN üle DNS kirjeldab transpordiideed ja ei ole sünonüüm seadme suunamisele kohandatud resolveerile. Segaduse lahendav küsimus on lihtne: mida DNS-sõnumid tegelikult kannavad? Tavaline VPN võib paigaldada resolveeri, et kaetud rakendused leiaksid privaatseid nimesid, ja selle resolveeri vahetamine muudab ainult nimede lahendamist. Käivitage allolevad kontrollid järjest, sest kolm korraldust jagavad sõnavara ja peaaegu mitte midagi muud.

Eraldage kolm korraldust

Esimeses korralduses pakub VPN resolveeri või nimepoliitika sätte. Rakenduse andmed liiguvad endiselt oma võrguühenduste kaudu ja tunnel mõjutab ainult seda, milline server päringule vastab.

Teises kaitseb krüpteeritud DNS DNS-vahetust ennast. DNS üle HTTPS-i ja DNS üle TLS-i mähivad päringud valitud resolveerile ega kanna ühegi teise rakenduse pakette. Need ei varja päringunimesid ka teie valitud resolveeri eest, mis on teistsugune usalduspiir kui nende varjamine kohaliku võrgu eest.

Kolmandas kodeerib koostööd tegev klient muud andmed DNS-sõnumitesse ja koostööd tegev lõpp-punkt rekonstrueerib need. Tavaline resolveeri tee muutub transpordiks ja resolveer on nüüd andmetee komponent, mitte nimeteteenus.

Kontrollige, mida DNS-sõnumid kannavad

Vahetage resolveer ja jälgige, kas rakenduse liiklustee muutub. Kui rakendus ühendub endiselt samade soketite kaudu samade aadressidega, muutsite nimede lahendamist ja mitte midagi muud.

DNS-i kaudu kantav tunnel vajab serveripoolset vastavat korraldust. Iodine on dokumenteeritud näide: selle projekti dokumentatsioon kirjeldab IP-tunnelit läbi DNS-i ja see nõuab serverikomponenti, mis kodeerimist mõistab. Avaliku resolveeri aadressi sisestamine Androidis ei paku seda lõpp-punkti ja kahe toote jagatud turundustermin ei ole protokolli spetsifikatsioon.

Püük on otsustav kontroll. Kui näete resolveerile tavalisi päringuid ja mitte midagi muud, tunnelit ei ole. Kui näete päringunimedesse ja vastustesse kodeeritud kasulikku koormust, olete kandja leidnud ja järgmine küsimus on, kui palju see liigutada suudab.

Kontrollige mahtu enne kohustumist

DNS loodi päringute ja vastuste jaoks, mitte hulgitarneks. Kodeerimise kulu, sõnumi suuruse piirid ja resolveeri käitumine võtavad kõik nominaalsest teest oma osa, seega kasulik maht on väiksem, kui alusühendus vihjab. Käsitlege iga läbilaskevõime numbrit, mida te ei ole oma teel mõõtnud, hüpoteesina, mitte eelarvena. Mõõtke mõlemas suunas, sest üles- ja allalaadimine võivad päringu-vastuse kandjal erinevatele piiridele sattuda.

Klient peab otsustama ka selle, milline liiklus tunnelisse siseneb. Kohalik VPN-teenuse liides võib pakette koguda, kuid liides ei ütle midagi selle kohta, kuidas kaugtransport neid kaitseb või edasi saadab. Fragmentatsioon ja kordussaadetis käituvad teisiti, kui kandja on päringu-vastuse protokoll, mitte voog, ja avatuks jääv ühendus ütleb interaktiivse latentsuse kohta vähe.

Mõõtke liiklusega, mida kavatsete kanda. Tunnel, mis tundub perioodilise südamelöögi jaoks hea, võib olla interaktiivse sessiooni jaoks kasutu, ja vastupidi on samuti tõsi.

Kontrollige kandja turvalisust

Ärge eeldage, et DNS-kapseldus pakub konfidentsiaalsust või tugevat autentimist. Resolveeri tee ja tunneli lõpp-punkt näevad seda, mida teostus paljastab, ja see paljastus varieerub projekti järgi.

Krüpteerimine ja kandja valik on eraldi omadused. Tunnelit saab krüpteerida tavalisel IP-teel ja DNS-i kaudu kantavat tunnelit saab ehitada kasuliku koormuse kaitsega või ilma. Hoidke rakenduse HTTPS igal juhul paigal ja hinnake tunneli tegelikku turvadisaini, mitte selle nime.

Kui nõue on privaatsus kohaliku võrgu eest, vastavad krüpteeritud DNS ja andmetunnel selle erinevatele osadele. Kirjutage üles, millise vaatleja eest te end kaitsete, enne kui ühe valite.

Sobitage parandus tegeliku rikkega

Tavalise aeglase VPN-i puhul lisab asendamine DNS-i kaudu kantava tunneliga probleemi otsa piiratud transpordi. See ei paranda raadio kvaliteeti, ummikuid ega serverikoormust ja muudab need tavaliselt nähtavamaks.

Privaatsete nimede rikete puhul uurige esmalt kavandatud resolveeri poliitikat: milline server peaks vastama, millised nimed on ulatuses ja kas kliendil on lubatud seda kasutada. Seejärel valige nõudele vastav volitatud transport ja hoidke resolveeri konfiguratsiooni muudatuste logis, et järgmine juhtum ei alustaks sama otsingut uuesti.

Kontroll-loend on lühike: tehke kindlaks korraldus, kinnitage, mida sõnumid kannavad, mõõtke mahtu ja seejärel vaadake üle usaldus. Iga samm, mis sümptomiga ei klapi, tähendab, et ülejäänud kaks korraldust on endiselt mängus.