VPN over DNS er ikkje det same som ein VPN-DNS-server

VPN over DNS skildrar ein transportidé og er ikkje synonymt med å peike ein eining mot ein tilpassa resolver. Spørsmålet som avgjer forvirringa, er enkelt: kva ber DNS-meldingane eigentleg? Ein vanleg VPN kan installere ein resolver slik at dekte applikasjonar finn private namn, og å byte den resolveren endrar berre namneoppslaget. Køyr kontrollane nedanfor i rekkjefølgje, fordi dei tre ordningane deler ordforråd og nesten ingenting anna.

Skil dei tre ordningane

I den første ordninga leverer VPN-en ein resolver eller ei innstilling for namnpolitikk. Applikasjonsdata reiser framleis over sine eigne nettverkssamband, og tunnelen påverkar berre kva tenar som svarar på oppslaget.

I den andre vernar kryptert DNS sjølve DNS-utvekslinga. DNS over HTTPS og DNS over TLS pakkar førespurnader til den valde resolveren og ber ikkje pakkar frå andre applikasjonar. Dei skjuler heller ikkje førespurnadsnamna for resolveren du valde, noko som er ei anna tillitsgrense enn å skjule dei for det lokale nettverket.

I den tredje kodar ein samarbeidande klient andre data inn i DNS-meldingar, og eit samarbeidande endepunkt byggjer dei opp att. Den vanlege resolvervegen blir transporten, og resolveren er no ein del av datatvegen i staden for ein namneteneste.

Sjekk kva DNS-meldingane ber

Byte resolver og sjå om trafikkvegen til applikasjonen endrar seg. Viss applikasjonen framleis koplar til dei same adressene over dei same sokkane, har du endra namneoppslaget og ingenting meir.

Ein tunnel som blir boren av DNS treng ei tilsvarande ordning på tenarsida. Iodine er eit dokumentert døme: prosjektdokumentasjonen skildrar ein IP-tunnel gjennom DNS, og han krev ein tenarkomponent som forstår kodinga. Å skrive inn ei offentleg resolveradresse i Android gir ikkje det endepunktet, og eit marknadsføringsuttrykk som to produkt deler, er ikkje ein protokollspesifikasjon.

Eit opptak er den avgjerande kontrollen. Viss du ser vanlege førespurnader til resolveren og ingenting anna, finst det ingen tunnel. Viss du ser nyttelast koda inn i førespurnadsnamn og svar, har du funne beraren, og neste spørsmål er kor mykje han kan flytte.

Sjekk kapasiteten før du forpliktar deg

DNS vart designa for førespurnader og svar, ikkje for massedistribusjon. Kodingkostnader, grenser for meldingsstorleik og resolveråtferd tek alle sin del av den nominelle vegen, så nyttig kapasitet er lågare enn det den underliggjande sambandet antydar. Behandle kvar gjennomstrøymingstal du ikkje har målt på din eigen veg som ein hypotese og ikkje eit budsjett. Mål begge retningar, fordi opplasting og nedlasting kan treffe ulike grenser på ein berar av typen førespurnad-svar.

Klienten må også avgjere kva trafikk som kjem inn i tunnelen. Eit lokalt VPN-tenestegrensesnitt kan samle pakkar, men grensesnittet seier ingenting om korleis den eksterne transporten vernar eller videresender dei. Fragmentering og videresending oppfører seg annleis når beraren er ein protokoll for førespurnad og svar i staden for ein straum, og eit samband som blir ståande ope, seier lite om interaktiv latenstid.

Mål med trafikken du har tenkt å bere. Ein tunnel som kjennest fin for eit periodisk hjarteslag, kan vere ubrukeleg for ei interaktiv økt, og det motsette er også sant.

Sjekk tryggleiken til beraren

Ikkje rekn med at DNS-innkapsling gir konfidensialitet eller sterk autentisering. Resolvervegen og tunnelendepunktet ser det implementasjonen avdekkjer, og den eksponeringa varierer etter design.

Kryptering og val av berar er separate eigenskapar. Ein tunnel kan krypterast over ein vanleg IP-veg, og ein DNS-boren tunnel kan byggjast med eller utan vern av nyttelasta. Hald HTTPS-en til applikasjonen på plass uansett, og vurder det faktiske tryggleiksdesignet til tunnelen framfor namnet.

Viss kravet er personvern mot det lokale nettverket, svarar kryptert DNS og ein datatunnel på ulike delar av det. Skriv ned kva observatør du forsvarte deg mot, før du vel ein.

Tilpass rettinga til den faktiske feilen

For ein vanleg treg VPN legg ei erstatning med ein DNS-boren tunnel til ein avgrensa transport på toppen av problemet. Han reparerer ikkje radiokvalitet, overbelastning eller tenarlast, og gjer dei vanlegvis meir synlege.

For feil med private namn, gransk først den tiltenkte resolverpolitikken: kva tenar som skal svare, kva namn som er i omfang, og om klienten har lov til å bruke han. Vel deretter ein autorisert transport som passar kravet, og oppbevar resolverkonfigurasjonen i endringsloggen slik at neste hending ikkje startar same søket på nytt.

Sjekklista er kort: identifiser ordninga, stadfest kva meldingane ber, mål kapasitet, og gå deretter gjennom tillit. Eitkvart steg som ikkje passar med symptomet, betyr at dei to andre ordningane framleis er i spel.