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

VPN over DNS beskriver en transportidé og er ikke synonymt med at pege en enhed mod en tilpasset resolver. Spørgsmålet, der afklarer forvirringen, er enkelt: hvad bærer DNS-beskederne egentlig? En almindelig VPN kan installere en resolver, så dækkede programmer kan finde private navne, og at skifte den resolver ændrer kun navneopløsningen. Kør kontrollerne nedenfor i rækkefølge, fordi de tre arrangementer deler ordforråd og næsten intet andet.

Adskil de tre arrangementer

I det første arrangement leverer VPN'en en resolver eller en indstilling for navnepolitik. Programdata rejser stadig over deres egne netværksforbindelser, og tunnelen påvirker kun, hvilken server der svarer på opslaget.

I det andet beskytter krypteret DNS selve DNS-udvekslingen. DNS over HTTPS og DNS over TLS pakker forespørgsler til den valgte resolver ind og bærer ikke andre programmers pakker. De skjuler heller ikke forespørgselsnavnene for den resolver, du valgte, hvilket er en anden tillidsgrænse end at skjule dem for det lokale netværk.

I det tredje koder en samarbejdende klient andre data ind i DNS-beskeder, og et samarbejdende endepunkt genskaber dem. Den almindelige resolvervej bliver transporten, og resolveren er nu en del af datastien i stedet for en navnetjeneste.

Undersøg, hvad DNS-beskederne bærer

Skift resolveren, og se, om programmets trafikvej ændrer sig. Hvis programmet stadig forbinder til de samme adresser over de samme sockets, har du ændret navneopløsningen og intet andet.

En tunnel båret af DNS kræver et tilsvarende arrangement på serversiden. Iodine er et dokumenteret eksempel: dets projektdokumentation beskriver en IP-tunnel gennem DNS, og den kræver en serverkomponent, der forstår kodningen. At indtaste en offentlig resolveradresse i Android giver ikke det endepunkt, og et marketingudtryk, som to produkter deler, er ikke en protokolspecifikation.

En optagelse er den afgørende kontrol. Hvis du ser almindelige forespørgsler til resolveren og intet andet, er der ingen tunnel. Hvis du ser nyttelast kodet ind i forespørgselsnavne og svar, har du fundet bæreren, og det næste spørgsmål er, hvor meget den kan flytte.

Undersøg kapaciteten, før du forpligter dig

DNS blev designet til forespørgsler og svar, ikke til massedistribution. Kodningsomkostninger, grænser for meddelelsesstørrelse og resolveradfærd tager alle en del af den nominelle vej, så den nyttige kapacitet er lavere, end den underliggende forbindelse antyder. Behandl ethvert gennemstrømningstal, du ikke har målt på din egen vej, som en hypotese og ikke som et budget. Mål begge retninger, fordi upload og download kan ramme forskellige grænser på en bærer af typen forespørgsel-svar.

Klienten skal også beslutte, hvilken trafik der kommer ind i tunnelen. En lokal VPN-tjenestegrænseflade kan indsamle pakker, men grænsefladen siger intet om, hvordan den eksterne transport beskytter eller videresender dem. Fragmentering og videresendelse opfører sig anderledes, når bæreren er en protokol med forespørgsel og svar i stedet for en strøm, og en forbindelse, der forbliver åben, siger lidt om interaktiv latenstid.

Mål med den trafik, du agter at bære. En tunnel, der føles fin til et periodisk hjerteslag, kan være ubrugelig til en interaktiv session, og det modsatte gælder også.

Undersøg bærerens sikkerhed

Antag ikke, at DNS-indkapsling giver fortrolighed eller stærk autentificering. Resolvervejen og tunnelendepunktet kan se, hvad implementeringen afslører, og den eksponering varierer efter design.

Kryptering og valg af bærer er separate egenskaber. En tunnel kan krypteres over en almindelig IP-vej, og en DNS-båret tunnel kan bygges med eller uden beskyttelse af sin nyttelast. Behold programs HTTPS uanset, og vurder tunnelens faktiske sikkerhedsdesign frem for dens navn.

Hvis kravet er privatliv i forhold til det lokale netværk, besvarer krypteret DNS og en datatunnel forskellige dele af det. Skriv ned, hvilken observatør du forsvarer dig imod, før du vælger en.

Tilpas rettelsen til den faktiske fejl

For en almindelig langsom VPN tilføjer en erstatning med en DNS-båret tunnel en begrænset transport oven på problemet. Den reparerer ikke radiokvalitet, overbelastning eller serverbelastning og gør dem normalt mere synlige.

For fejl med private navne skal du først undersøge den tilsigtede resolverpolitik: hvilken server der skal svare, hvilke navne der er omfattet, og om klienten har tilladelse til at bruge den. Vælg derefter en autoriseret transport, der matcher kravet, og opbevar resolverkonfigurationen i ændringsloggen, så den næste hændelse ikke starter den samme søgning igen.

Tjeklisten er kort: identificer arrangementet, bekræft hvad beskederne bærer, mål kapacitet, og gennemgå derefter tillid. Ethvert trin, der ikke matcher symptomet, betyder, at de to andre arrangementer stadig er i spil.