VPN DNS:n yli ei ole sama asia kuin VPN:n DNS-palvelin

VPN DNS:n yli kuvaa kuljetusideaa, eikä se ole synonyymi laitteen ohjaamiselle omaan ratkaisijaan. Hämmennuksen ratkaiseva kysymys on yksinkertainen: mitä DNS-viestit oikeastaan kuljettavat? Tavallinen VPN voi asentaa ratkaisijan, jotta katetut sovellukset löytävät yksityisiä nimiä, ja tuon ratkaisijan vaihtaminen muuttaa vain nimien selvitystä. Suorita alla olevat tarkistukset järjestyksessä, koska kolme järjestelyä jakavat sanaston ja lähes ei mitään muuta.

Erottele kolme järjestelyä

Ensimmäisessä järjestelyssä VPN tarjoaa ratkaisijan tai nimikäytännön asetuksen. Sovellusten tiedot kulkevat edelleen omien verkkoyhteyksiensä kautta, ja tunneli vaikuttaa vain siihen, mikä palvelin vastaa kyselyyn.

Toisessa salattu DNS suojaa itse DNS-vaihtoa. DNS HTTPS:n yli ja DNS TLS:n yli kääriytyvät kyselyt valittuun ratkaisijaan eivätkä kuljeta minkään muun sovelluksen paketteja. Ne eivät myöskään piilota kyselyjen nimiä valitsemaltasi ratkaisijalta, mikä on eri luottamusraja kuin niiden piilottaminen paikallisverkolta.

Kolmannessa yhteistyötä tekevä asiakas koodaa muuta dataa DNS-viesteihin ja yhteistyötä tekevä päätepiste rekonstruoi sen. Tavallisesta ratkaisijan polusta tulee kuljetus, ja ratkaisija on nyt datapolun osa eikä nimipalvelu.

Tarkista, mitä DNS-viestit kuljettavat

Vaihda ratkaisija ja seuraa, muuttuuko sovelluksen liikennepolku. Jos sovellus edelleen yhdistää samoihin osoitteisiin samoja socketeja pitkin, muutit nimien selvitystä etkä muuta.

DNS:n kautta kuljetettu tunneli tarvitsee vastaavan palvelinpuolen järjestelyn. Iodine on dokumentoitu esimerkki: sen projektin dokumentaatio kuvaa IP-tunnelin DNS:n kautta, ja se vaatii palvelinkomponentin, joka ymmärtää koodauksen. Julkisen ratkaisijan osoitteen syöttäminen Androidissa ei tarjoa tuota päätepistettä, eikä kahden tuotteen jakama markkinointitermi ole protokollamääritelmä.

Kaappaus on ratkaiseva tarkistus. Jos näet tavallisia kyselyitä ratkaisijalle etkä muuta, tunnelia ei ole. Jos näet kyselyjen nimiin ja vastauksiin koodattua hyötykuormaa, olet löytänyt kantajan, ja seuraava kysymys on, kuinka paljon se voi siirtää.

Tarkista kapasiteetti ennen sitoutumista

DNS suunniteltiin kyselyitä ja vastauksia varten, ei joukkotoimitukseen. Koodauksen lisäkuorma, viestien kokorajat ja ratkaisijan käyttäytyminen ottavat kaikki osansa nimellisestä polusta, joten hyödyllinen kapasiteetti on pienempi kuin alla oleva linkki antaa ymmärtää. Käsittele jokaista läpimenolukua, jota et ole mitannut omalla polullasi, hypoteesina äläkä budjettina. Mittaa molemmat suunnat, koska lähetys ja lataus voivat osua eri rajoihin kysely-vastaus-kantajalla.

Asiakkaan on myös päätettävä, mikä liikenne tulee tunneliin. Paikallinen VPN-palvelun rajapinta voi kerätä paketteja, mutta rajapinta ei kerro mitään siitä, miten etäkuljetus suojaa tai välittää ne. Pirstoutuminen ja uudelleenlähetys käyttäytyvät eri tavoin, kun kantaja on kysely-vastaus-protokolla eikä virta, ja avoinna pysyvä yhteys kertoo vähän vuorovaikutteisesta viiveestä.

Mittaa liikenteellä, jonka aiot kuljettaa. Tunneli, joka tuntuu hyvältä säännölliselle sydämenlyönnille, voi olla käyttökelvoton vuorovaikutteiselle istunnolle, ja päinvastoin on myös totta.

Tarkista kantajan turvallisuus

Älä oleta, että DNS-kapselointi tarjoaa luottamuksellisuutta tai vahvaa todennusta. Ratkaisijan polku ja tunnelin päätepiste näkevät sen, mitä toteutus paljastaa, ja tuo paljastuminen vaihtelee suunnittelun mukaan.

Salaus ja kantajan valinta ovat erillisiä ominaisuuksia. Tunneli voidaan salata tavallisen IP-polun yli, ja DNS:n kautta kuljetettu tunneli voidaan rakentaa hyötykuorman suojauksella tai ilman. Pidä sovelluksen HTTPS paikallaan joka tapauksessa ja arvioi tunnelin todellista turvasuunnittelua, älä sen nimeä.

Jos vaatimus on yksityisyys paikallisverkkoa vastaan, salattu DNS ja datatunneli vastaavat sen eri osiin. Kirjoita muistiin, ketä tarkkailijaa vastaan puolustaudut, ennen kuin valitset yhden.

Sovita korjaus todelliseen vikaan

Tavallisen hitaan VPN:n kohdalla korvaaminen DNS:n kautta kuljetetulla tunnelilla lisää rajoitetun kuljetuksen ongelman päälle. Se ei korjaa radion laatua, ruuhkautumista tai palvelimen kuormaa ja tekee niistä yleensä näkyvämpiä.

Yksityisten nimien vikojen kohdalla tarkista ensin aiottu ratkaisijakäytäntö: minkä palvelimen pitäisi vastata, mitkä nimet ovat laajuudessa ja saako asiakas käyttää sitä. Valitse sitten vaatimukseen sopiva valtuutettu kuljetus ja pidä ratkaisijan kokoonpano muutoslokissa, jotta seuraava tapaus ei aloita samaa etsintää uudelleen.

Tarkistuslista on lyhyt: tunnista järjestely, vahvista mitä viestit kuljettavat, mittaa kapasiteetti ja tarkastele sitten luottamusta. Mikä tahansa vaihe, joka ei vastaa oiretta, tarkoittaa, että kaksi muuta järjestelyä ovat yhä pelissä.