VPN via DNS is niet hetzelfde als een VPN-DNS-server

VPN via DNS beschrijft een transportidee en is geen synoniem voor het richten van een apparaat op een eigen resolver. De vraag die de verwarring beslecht, is simpel: wat vervoeren de DNS-berichten eigenlijk? Een gewone VPN kan een resolver installeren zodat gedekte toepassingen privénamen vinden, en het wijzigen van die resolver verandert alleen de naamresolutie. Voer de controles hieronder in volgorde uit, want de drie opstellingen delen woordenschat en bijna niets anders.

Scheid de drie opstellingen

In de eerste opstelling levert de VPN een resolver of een instelling voor naambeleid. Toepassingsgegevens reizen nog steeds over hun eigen netwerkverbindingen, en de tunnel beïnvloedt alleen welke server de opzoeking beantwoordt.

In de tweede beschermt versleutelde DNS de DNS-uitwisseling zelf. DNS via HTTPS en DNS via TLS verpakken query's naar de gekozen resolver en vervoeren geen pakketten van andere toepassingen. Ze verbergen de querynamen ook niet voor de resolver die u koos, wat een andere vertrouwensgrens is dan ze voor het lokale netwerk verbergen.

In de derde codeert een samenwerkende client andere gegevens in DNS-berichten en reconstrueert een samenwerkend eindpunt ze. Het gewone resolverpad wordt het transport, en de resolver is nu een onderdeel van het datapad in plaats van een naamdienst.

Controleer wat de DNS-berichten vervoeren

Wijzig de resolver en kijk of het verkeerspad van de toepassing verandert. Als de toepassing nog steeds met dezelfde adressen verbindt via dezelfde sockets, hebt u de naamresolutie gewijzigd en niets meer.

Een tunnel die door DNS wordt gedragen, vereist een overeenkomstige opstelling aan de serverkant. Iodine is een gedocumenteerd voorbeeld: de projectdocumentatie beschrijft een IP-tunnel via DNS, en die vereist een servercomponent die de codering begrijpt. Een openbaar resolveradres invoeren in Android levert dat eindpunt niet, en een marketingterm die twee producten delen is geen protocolspecificatie.

Een opname is de beslissende controle. Ziet u gewone query's naar de resolver en niets anders, dan is er geen tunnel. Ziet u payload die in querynamen en antwoorden is gecodeerd, dan hebt u de drager gevonden, en de volgende vraag is hoeveel die kan verplaatsen.

Controleer de capaciteit voordat u zich vastlegt

DNS is ontworpen voor query's en antwoorden, niet voor bulklevering. Coderingskosten, limieten voor berichtgrootte en resolvergedrag nemen allemaal hun deel van het nominale pad, dus de bruikbare capaciteit is lager dan de onderliggende verbinding suggereert. Behandel elk doorvoergetal dat u niet op uw eigen pad hebt gemeten als een hypothese en niet als een budget. Meet beide richtingen, want upload en download kunnen op een drager van het type vraag-antwoord verschillende grenzen raken.

De client moet ook beslissen welk verkeer de tunnel in gaat. Een lokale interface van de VPN-dienst kan pakketten verzamelen, maar de interface zegt niets over hoe het externe transport ze beschermt of doorstuurt. Fragmentatie en herverzending gedragen zich anders wanneer de drager een protocol voor vraag en antwoord is in plaats van een stream, en een verbinding die open blijft, zegt weinig over interactieve latentie.

Meet met het verkeer dat u wilt vervoeren. Een tunnel die goed aanvoelt voor een periodieke hartslag, kan onbruikbaar zijn voor een interactieve sessie, en het omgekeerde is ook waar.

Controleer de beveiliging van de drager

Ga er niet van uit dat DNS-inkapseling vertrouwelijkheid of sterke authenticatie levert. Het resolverpad en het tunneleindpunt zien wat de implementatie blootlegt, en die blootstelling verschilt per ontwerp.

Versleuteling en de keuze van drager zijn afzonderlijke eigenschappen. Een tunnel kan worden versleuteld over een gewoon IP-pad, en een door DNS gedragen tunnel kan met of zonder bescherming van zijn payload worden gebouwd. Houd de HTTPS van de toepassing hoe dan ook op zijn plaats, en beoordeel het werkelijke beveiligingsontwerp van de tunnel en niet de naam.

Als de eis privacy tegenover het lokale netwerk is, beantwoorden versleutelde DNS en een datatunnel verschillende delen daarvan. Schrijf op tegen welke waarnemer u zich verdedigt voordat u er een kiest.

Pas de oplossing aan op de werkelijke storing

Voor een gewone langzame VPN voegt vervanging door een door DNS gedragen tunnel een beperkt transport bovenop het probleem. Het herstelt radiokwaliteit, congestie of serverbelasting niet, en maakt ze meestal zichtbaarder.

Voor storingen met privénamen onderzoekt u eerst het beoogde resolverbeleid: welke server moet antwoorden, welke namen vallen binnen bereik, en of de client het mag gebruiken. Kies daarna een geautoriseerd transport dat bij de eis past, en bewaar de resolverconfiguratie in het wijzigingslogboek zodat het volgende incident niet dezelfde zoektocht opnieuw begint.

De checklist is kort: identificeer de opstelling, bevestig wat de berichten vervoeren, meet de capaciteit en beoordeel dan het vertrouwen. Elke stap die niet bij het symptoom past, betekent dat de andere twee opstellingen nog in het spel zijn.