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

VPN over DNS beskriver en transportidé og er ikke synonymt med å peke en enhet mot en tilpasset resolver. Spørsmålet som avgjør forvirringen, er enkelt: hva bærer DNS-meldingene egentlig? En vanlig VPN kan installere en resolver slik at dekkede applikasjoner finner private navn, og å bytte den resolveren endrer bare navneoppslag. Kjør kontrollene nedenfor i rekkefølge, fordi de tre ordningene deler ordforråd og nesten ingenting annet.

Skill de tre ordningene

I den første ordningen leverer VPN-en en resolver eller en innstilling for navnepolicy. Applikasjonsdata reiser fortsatt over sine egne nettverksforbindelser, og tunnelen påvirker bare hvilken server som svarer på oppslaget.

I den andre beskytter kryptert DNS selve DNS-utvekslingen. DNS over HTTPS og DNS over TLS pakker forespørsler til den valgte resolveren og bærer ikke pakker fra andre applikasjoner. De skjuler heller ikke forespørselsnavnene for resolveren du valgte, noe som er en annen tillitsgrense enn å skjule dem for det lokale nettverket.

I den tredje koder en samarbeidende klient andre data inn i DNS-meldinger, og et samarbeidende endepunkt gjenoppbygger dem. Den vanlige resolverveien blir transporten, og resolveren er nå en del av datastien i stedet for en navnetjeneste.

Sjekk hva DNS-meldingene bærer

Bytt resolver og se om trafikkveien til applikasjonen endres. Hvis applikasjonen fortsatt kobler til de samme adressene over de samme socketene, har du endret navneoppslaget og ingenting mer.

En tunnel som bæres av DNS trenger en tilsvarende ordning på serversiden. Iodine er et dokumentert eksempel: prosjektdokumentasjonen beskriver en IP-tunnel gjennom DNS, og den krever en serverkomponent som forstår kodingen. Å skrive inn en offentlig resolveradresse i Android gir ikke det endepunktet, og et markedsføringsuttrykk som to produkter deler, er ikke en protokollspesifikasjon.

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

Sjekk kapasiteten før du forplikter deg

DNS ble designet for forespørsler og svar, ikke for massedistribusjon. Kodingskostnader, grenser for meldingsstørrelse og resolveratferd tar alle sin del av den nominelle veien, så nyttig kapasitet er lavere enn den underliggende forbindelsen antyder. Behandle enhver gjennomstrømningstall du ikke har målt på din egen vei som en hypotese og ikke et budsjett. Mål begge retninger, fordi opplasting og nedlasting kan treffe ulike grenser på en bærer av typen forespørsel-svar.

Klienten må også avgjøre hvilken trafikk som kommer inn i tunnelen. Et lokalt VPN-tjenestegrensesnitt 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 forespørsel og svar i stedet for en strøm, og en forbindelse som blir stående åpen, sier lite om interaktiv latenstid.

Mål med trafikken du har tenkt å bære. En tunnel som føles fin for et 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. Resolverveien og tunnelendepunktet ser det implementasjonen avslører, og den eksponeringen varierer etter design.

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

Hvis kravet er personvern mot det lokale nettverket, svarer kryptert DNS og en datatunnel på ulike 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året 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 lov 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 ordningen, bekreft hva meldingene bærer, mål kapasitet, og gjennomgå deretter tillit. Ethvert trinn som ikke passer med symptomet, betyr at de to andre ordningene fortsatt er i spill.