VPN prek DNS ni isto kot strežnik DNS za VPN

VPN prek DNS opisuje idejo prenosa in ni sopomenka za usmerjanje naprave na lasten razreševalnik. Vprašanje, ki razreši zmedo, je preprosto: kaj pravzaprav prenašajo sporočila DNS? Običen VPN lahko namesti razreševalnik, da zajete aplikacije najdejo zasebna imena, in menjava tega razreševalnika spremeni le razreševanje imen. Izvedite spodnje kontrole po vrsti, ker si tri postavitve delijo izrazoslovje in skoraj nič drugega.

Ločite tri postavitve

V prvi postavitvi VPN zagotovi razreševalnik ali nastavitev politike imen. Podatki aplikacij še vedno potujejo po lastnih omrežnih povezavah, tunel pa vpliva le na to, kateri strežnik odgovori na poizvedbo.

V drugi šifriran DNS ščiti samo izmenjavo DNS. DNS prek HTTPS in DNS prek TLS ovijeta poizvedbe na izbrani razreševalnik in ne prenašata paketov nobene druge aplikacije. Prav tako ne skrivata imen poizvedb pred razreševalnikom, ki ste ga izbrali, kar je druga meja zaupanja kot skrivanje pred lokalnim omrežjem.

V tretji sodelujoči odjemalec kodira druge podatke v sporočila DNS, sodelujoča končna točka pa jih rekonstruira. Običajna pot razreševalnika postane prenos, razreševalnik pa je zdaj sestavni del podatkovne poti, ne pa imenska storitev.

Preverite, kaj prenašajo sporočila DNS

Zamenjajte razreševalnik in opazujte, ali se spremeni pot prometa aplikacije. Če se aplikacija še vedno povezuje na iste naslove prek istih vtičnic, ste spremenili razreševanje imen in nič več.

Tunel, ki ga prenaša DNS, potrebuje ustrezno postavitev na strani strežnika. Iodine je dokumentiran primer: njegova dokumentacija projekta opisuje tunel IP prek DNS in zahteva strežniško komponento, ki razume kodiranje. Vnos naslova javnega razreševalnika v Androidu te končne točke ne zagotovi, marketinški izraz, ki si ga delita dva izdelka, pa ni specifikacija protokola.

Zajem je odločilna kontrola. Če vidite običajne poizvedbe na razreševalnik in nič drugega, tunela ni. Če vidite tovor, kodiran v imena poizvedb in odgovore, ste našli nosilec, naslednje vprašanje pa je, koliko lahko prenese.

Preverite zmogljivost, preden se zavežete

DNS je bil zasnovan za poizvedbe in odgovore, ne za množično dostavo. Stroški kodiranja, omejitve velikosti sporočil in vedenje razreševalnika vsi vzamejo svoj del nominalne poti, zato je uporabna zmogljivost nižja, kot nakazuje osnovna povezava. Vsako število prepustnosti, ki ga niste izmerili na svoji poti, obravnavajte kot hipotezo in ne kot proračun. Merite v obe smeri, ker lahko pošiljanje in prejemanje na nosilcu vrste zahteva-odgovor naletita na različne meje.

Odjemalec mora tudi odločiti, kateri promet vstopi v tunel. Lokalni vmesnik storitve VPN lahko zbira pakete, vendar vmesnik ne pove ničesar o tem, kako jih oddaljeni prenos ščiti ali posreduje. Razdrobljanje in ponovno pošiljanje se obnašata drugače, ko je nosilec protokol zahteve in odgovora namesto toka, povezava, ki ostane odprta, pa pove malo o interaktivni zakasnitvi.

Merite s prometom, ki ga nameravate prenašati. Tunel, ki se zdi dober za obdobni utrip, je lahko neuporaben za interaktivno sejo, in velja tudi obratno.

Preverite varnost nosilca

Ne predpostavljajte, da inkapsulacija DNS zagotavlja zaupnost ali močno preverjanje pristnosti. Pot razreševalnika in končna točka tunela vidita, kar izvedba razkrije, in ta izpostavljenost se razlikuje glede na zasnovo.

Šifriranje in izbira nosilca sta ločeni lastnosti. Tunel je mogoče šifrirati prek običajne poti IP, tunel, ki ga prenaša DNS, pa je mogoče zgraditi z zaščito tovora ali brez nje. V vsakem primeru ohranite HTTPS aplikacije na mestu in ocenite dejansko varnostno zasnovo tunela, ne njegovega imena.

Če je zahteva zasebnost pred lokalnim omrežjem, šifriran DNS in podatkovni tunel odgovarjata na različne dele tega. Preden izberete eno, zapišite, pred katerim opazovalcem se branite.

Prilagodite popravek dejanski okvari

Pri običajnem počasnem VPN nadomestitev s tunelom, ki ga prenaša DNS, doda omejen prenos na vrh težave. Ne odpravi kakovosti radia, zastoja ali obremenitve strežnika in jih običajno naredi bolj vidne.

Pri okvarah zasebnih imen najprej preglejte predvideno politiko razreševalnika: kateri strežnik naj odgovori, katera imena so v obsegu in ali ga odjemalec sme uporabljati. Nato izberite pooblaščen prenos, ki ustreza zahtevi, in hranite konfiguracijo razreševalnika v dnevniku sprememb, da naslednji dogodek ne začne istega iskanja znova.

Kontrolni seznam je kratek: prepoznajte postavitev, potrdite, kaj sporočila prenašajo, izmerite zmogljivost in nato pregledajte zaupanje. Vsak korak, ki se ne ujema s simptomom, pomeni, da sta drugi dve postavitvi še vedno v igri.