VPN over DNS er ikke det samme som en DNS-server for VPN

VPN over DNS beskriver en idé om transport, og det er ikke det samme som å peke en enhet mot en egen resolver. Spørsmålet som fjerner forvirringen, er enkelt: hva frakter DNS-meldingene egentlig? En vanlig VPN kan sette opp en resolver slik at omfattede apper finner private navn, og å bytte denne resolveren endrer bare navneoppslaget. Utfør kontrollene nedenfor i rekkefølge, fordi de tre oppsettene deler terminologi og nesten ikke noe annet.

Del opp de tre oppsettene

I det første oppsettet gir VPN-en en resolver eller en innstilling for navnepolicy. Appdata går fortsatt over sine egne nettverksforbindelser, og tunnelen påvirker bare hvilken server som svarer på oppslaget.

I det andre beskytter kryptert DNS selve DNS-utvekslingen. DNS over HTTPS og DNS over TLS pakker forespørsler til den valgte resolveren, og de frakter ikke pakker fra noen annen app. De skjuler heller ikke spørringsnavnene for resolveren du valgte, noe som er en annen tillitsgrense enn å skjule dem for det lokale nettet.

I det tredje koder en samarbeidende klient andre data inn i DNS-meldinger, og et samarbeidende endepunkt gjenoppretter dem. Den vanlige resolverruten blir transporten, og resolveren er nå en komponent i dataruten i stedet for en navnetjeneste.

Sjekk hva DNS-meldingene frakter

Bytt resolver og observer om trafikkruten til appen endres. Hvis appen fortsatt kobler til de samme adressene over de samme socketene, har du endret navneoppslaget og ingenting mer.

En tunnel som fraktes av DNS trenger et tilsvarende oppsett på serversiden. Iodine er et dokumentert eksempel: prosjektdokumentasjonen beskriver en IP-tunnel gjennom DNS, og den krever en serverkomponent som forstår kodingen. Å taste inn en offentlig resolveradresse i Android gir ikke dette endepunktet, og et markedsføringsbegrep som deles av to produkter er ikke en protokollspesifikasjon.

Et opptak er den avgjørende kontrollen. Ser du vanlige forespørsler til resolveren og ingenting annet, finnes det ingen tunnel. Ser du nyttelast kodet inn i spørringsnavn og svar, har du funnet bæreren, og neste spørsmål er hvor mye den kan flytte.

Sjekk kapasiteten før du binder deg

DNS ble laget for spørsmål og svar, ikke for massedistribusjon. Kodekostnader, grenser for meldingsstørrelse og resolveratferd tar alle sin del av den nominelle ruten, så nyttig kapasitet er lavere enn den underliggende lenken antyder. Behandle ethvert gjennomstrømningstall du ikke har målt på din egen rute som en hypotese og ikke et budsjett. Mål begge retninger, fordi opplasting og nedlasting kan treffe forskjellige grenser på en bærer av typen spørsmål-svar.

Klienten må også bestemme hvilken trafikk som kommer inn i tunnelen. Et lokalt grensesnitt for VPN-tjenesten kan samle pakker, men grensesnittet sier ingenting om hvordan den eksterne transporten beskytter eller videresender dem. Fragmentering og videresending oppfører seg annerledes når bæreren er en protokoll for spørsmål og svar i stedet for en strøm, og en forbindelse som blir stående åpen, sier lite om interaktiv forsinkelse.

Mål med trafikken du planlegger å frakte. En tunnel som føles bra for en periodisk hjerteslag, kan være ubrukelig for en interaktiv økt, og det motsatte er også sant.

Sjekk sikkerheten til bæreren

Ikke anta at DNS-innkapsling gir konfidensialitet eller sterk autentisering. Resolverruten og tunnelendepunktet ser det implementasjonen avdekker, og den eksponeringen varierer med designet.

Kryptering og valg av bærer er separate egenskaper. En tunnel kan krypteres over en vanlig IP-rute, og en DNS-båren tunnel kan bygges med eller uten beskyttelse av nyttelasten. Behold appens HTTPS på plass uansett, og vurder tunnelens faktiske sikkerhetsdesign fremfor navnet.

Hvis kravet er personvern mot det lokale nettet, svarer kryptert DNS og en datatunnel på forskjellige deler av det. Skriv ned hvilken observatør du forsvarer deg mot, før du velger en.

Tilpass rettelsen til den faktiske feilen

For en vanlig treg VPN legger en erstatning med en DNS-båren tunnel til en begrenset transport på toppen av problemet. Den reparerer ikke radiokvalitet, overbelastning eller serverlast, og gjør dem vanligvis mer synlige.

For feil med private navn, undersøk først den tiltenkte resolverpolicyen: hvilken server som skal svare, hvilke navn som er i omfang, og om klienten har tillatelse til å bruke den. Velg deretter en autorisert transport som passer kravet, og oppbevar resolverkonfigurasjonen i endringsloggen slik at neste hendelse ikke starter samme søk på nytt.

Sjekklisten er kort: identifiser oppsettet, bekreft hva meldingene frakter, mål kapasitet, og gjennomgå deretter tillit. Ethvert trinn som ikke passer med symptomet, betyr at de to andre oppsettene fortsatt er i spill.