VPN přes DNS není totéž jako DNS server pro VPN

VPN přes DNS popisuje transportní myšlenku a není synonymem pro nasměrování zařízení na vlastní resolver. Otázka, která zmatek rozřeší, je jednoduchá: co vlastně DNS zprávy přenášejí? Běžná VPN může nainstalovat resolver, aby pokryté aplikace našly privátní jména, a změna tohoto resolveru mění jen překlad jmen. Proveďte níže uvedené kontroly v pořadí, protože tři uspořádání sdílejí slovník a téměř nic jiného.

Oddělte tři uspořádání

V prvním uspořádání VPN poskytuje resolver nebo nastavení zásad pro jména. Data aplikací stále cestují přes jejich vlastní síťová spojení a tunel ovlivňuje jen to, který server odpovídá na dotaz.

Ve druhém chrání šifrované DNS samotnou výměnu DNS. DNS přes HTTPS a DNS přes TLS obalují dotazy na zvolený resolver a nepřenášejí pakety žádné jiné aplikace. Také neskrývají názvy dotazů před resolverem, který jste si vybrali, což je jiná hranice důvěry než skrývání před místní sítí.

Ve třetím spolupracující klient kóduje jiná data do DNS zpráv a spolupracující koncový bod je rekonstruuje. Běžná cesta resolveru se stává transportem a resolver je nyní součástí datové cesty, nikoli jmennou službou.

Ověřte, co DNS zprávy přenášejí

Změňte resolver a sledujte, zda se změní cesta provozu aplikace. Pokud se aplikace stále připojuje na stejné adresy přes stejné sockety, změnili jste překlad jmen a nic víc.

Tunel přenášený přes DNS potřebuje odpovídající uspořádání na straně serveru. Iodine je zdokumentovaný příklad: jeho dokumentace projektu popisuje IP tunel přes DNS a vyžaduje serverovou komponentu, která rozumí kódování. Zadání adresy veřejného resolveru v Androidu tento koncový bod neposkytne a marketingový termín sdílený dvěma produkty není specifikace protokolu.

Zachycení je rozhodující kontrola. Pokud vidíte běžné dotazy na resolver a nic jiného, tunel neexistuje. Pokud vidíte užitečné zatížení zakódované v názvech dotazů a odpovědích, našli jste nosič a další otázkou je, kolik toho dokáže přenést.

Ověřte kapacitu, než se zavážete

DNS bylo navrženo pro dotazy a odpovědi, ne pro hromadné doručování. Režie kódování, limity velikosti zpráv a chování resolveru si berou svůj podíl z nominální cesty, takže užitečná kapacita je nižší, než naznačuje podkladové spojení. S každým číslem propustnosti, které jste neměřili na své vlastní cestě, zacházejte jako s hypotézou, ne jako s rozpočtem. Měřte oba směry, protože odesílání a stahování mohou na nosiči založeném na dotazu a odpovědi narazit na různé limity.

Klient také musí rozhodnout, který provoz do tunelu vstoupí. Místní rozhraní služby VPN může sbírat pakety, ale rozhraní nic neříká o tom, jak je vzdálený transport chrání nebo předává. Fragmentace a opakovaný přenos se chovají jinak, když je nosičem protokol typu dotaz-odpověď namísto proudu, a spojení, které zůstává otevřené, říká málo o interaktivní latenci.

Měřte s provozem, který hodláte přenášet. Tunel, který se zdá dobrý pro periodický puls, může být nepoužitelný pro interaktivní relaci, a platí to i obráceně.

Ověřte zabezpečení nosiče

Nepředpokládejte, že zapouzdření DNS poskytuje důvěrnost nebo silnou autentizaci. Cesta resolveru a koncový bod tunelu vidí to, co implementace odhaluje, a tato expozice se liší podle návrhu.

Šifrování a volba nosiče jsou oddělené vlastnosti. Tunel lze šifrovat přes běžnou IP cestu a tunel přenášený přes DNS lze postavit s ochranou užitečného zatížení i bez ní. Každopádně ponechte HTTPS aplikace na místě a hodnoťte skutečný bezpečnostní návrh tunelu, ne jeho název.

Pokud je požadavkem soukromí před místní sítí, šifrované DNS a datový tunel odpovídají na různé jeho části. Než si jeden vyberete, zapište si, před kterým pozorovatelem se bráníte.

Přizpůsobte opravu skutečné závadě

U běžné pomalé VPN přidává nahrazení tunelem přes DNS omezený transport navrch problému. Neopravuje kvalitu rádia, zahlcení ani zatížení serveru a obvykle je činí viditelnějšími.

U selhání privátních jmen nejprve prozkoumejte zamýšlené zásady resolveru: který server má odpovídat, která jména spadají do rozsahu a zda je klient smí používat. Potom zvolte autorizovaný transport, který požadavku vyhovuje, a uchovávejte konfiguraci resolveru v záznamu změn, aby příští incident nezačal stejné hledání znovu.

Kontrolní seznam je krátký: určete uspořádání, potvrďte, co zprávy přenášejí, změřte kapacitu a poté projděte důvěru. Každý krok, který neodpovídá symptomu, znamená, že zbývající dvě uspořádání jsou stále ve hře.