VPN över DNS är inte samma sak som en VPN-DNS-server

VPN över DNS beskriver en transportidé och är inte synonymt med att peka en enhet mot en egen resolver. Frågan som avgör förvirringen är enkel: vad bär DNS-meddelandena egentligen? En vanlig VPN kan installera en resolver så att täckta program hittar privata namn, och att byta den resolvern ändrar bara namnmatchningen. Kör kontrollerna nedan i ordning, eftersom de tre uppläggen delar ordförråd och nästan ingenting annat.

Skilj de tre uppläggen

I det första upplägget tillhandahåller VPN:en en resolver eller en inställning för namnpolicy. Programdata färdas fortfarande över sina egna nätverksanslutningar, och tunneln påverkar bara vilken server som svarar på slaget.

I det andra skyddar krypterad DNS själva DNS-utbytet. DNS över HTTPS och DNS över TLS paketerar frågor till den valda resolvern och bär inte paket från något annat program. De döljer inte heller frågenamnen för resolvern du valde, vilket är en annan förtroendegräns än att dölja dem för det lokala nätverket.

I det tredje kodar en samverkande klient andra data i DNS-meddelanden och en samverkande ändpunkt återställer dem. Den vanliga resolvervägen blir transporten, och resolvern är nu en komponent i datavägen i stället för en namntjänst.

Kontrollera vad DNS-meddelandena bär

Byt resolver och observera om programmets trafikväg ändras. Om programmet fortfarande ansluter till samma adresser över samma sockets, har du ändrat namnmatchningen och ingenting mer.

En tunnel som bärs av DNS behöver ett motsvarande upplägg på serversidan. Iodine är ett dokumenterat exempel: dess projektdokumentation beskriver en IP-tunnel genom DNS, och den kräver en serverkomponent som förstår kodningen. Att ange en offentlig resolveradress i Android ger inte den ändpunkten, och en marknadsföringsterm som två produkter delar är ingen protokollspecifikation.

En avlyssning är den avgörande kontrollen. Om du ser vanliga frågor till resolvern och ingenting annat finns ingen tunnel. Om du ser nyttolast kodad i frågenamn och svar har du hittat bäraren, och nästa fråga är hur mycket den kan flytta.

Kontrollera kapaciteten innan du binder dig

DNS konstruerades för frågor och svar, inte för massutdelning. Kodningskostnader, gränser för meddelandestorlek och resolverbeteende tar alla sin del av den nominella vägen, så den användbara kapaciteten är lägre än den underliggande länken antyder. Behandla varje genomströmningstal du inte har mätt på din egen väg som en hypotes och inte som en budget. Mät båda riktningarna, eftersom uppladdning och nedladdning kan träffa olika gränser på en bärare av typen fråga-svar.

Klienten måste också avgöra vilken trafik som kommer in i tunneln. Ett lokalt VPN-tjänstegränssnitt kan samla paket, men gränssnittet säger ingenting om hur den fjärranslutna transporten skyddar eller vidarebefordrar dem. Fragmentering och omsändning beter sig annorlunda när bäraren är ett protokoll för fråga och svar i stället för en ström, och en anslutning som förblir öppen säger lite om interaktiv latens.

Mät med den trafik du tänker bära. En tunnel som känns bra för en periodisk hjärtslag kan vara oanvändbar för en interaktiv session, och det omvända är också sant.

Kontrollera bärarens säkerhet

Anta inte att DNS-inkapsling ger sekretess eller stark autentisering. Resolvervägen och tunnelns ändpunkt ser vad implementeringen avslöjar, och den exponeringen varierar med designen.

Kryptering och val av bärare är separata egenskaper. En tunnel kan krypteras över en vanlig IP-väg, och en DNS-buren tunnel kan byggas med eller utan skydd av sin nyttolast. Behåll programmets HTTPS på plats oavsett, och bedöm tunnelns faktiska säkerhetsdesign framför dess namn.

Om kravet är integritet gentemot det lokala nätverket, svarar krypterad DNS och en datatunnel på olika delar av det. Skriv ned vilken observatör du försvarar dig mot innan du väljer en.

Anpassa åtgärden till det faktiska felet

För en vanlig långsam VPN lägger en ersättning med en DNS-buren tunnel till en begränsad transport ovanpå problemet. Den reparerar inte radiokvalitet, överbelastning eller serverlast och gör dem vanligtvis mer synliga.

För fel med privata namn, granska först den avsedda resolverpolicyn: vilken server som ska svara, vilka namn som omfattas och om klienten får använda den. Välj sedan en auktoriserad transport som matchar kravet, och förvara resolverkonfigurationen i ändringsloggen så att nästa incident inte startar samma sökning igen.

Checklistan är kort: identifiera upplägget, bekräfta vad meddelandena bär, mät kapaciteten och granska sedan förtroendet. Varje steg som inte stämmer med symptomet betyder att de andra två uppläggen fortfarande är i spel.