VPN przez DNS to nie to samo co serwer DNS dla VPN

VPN przez DNS opisuje ideę transportu i nie jest synonimem kierowania urządzenia na własny resolver. Pytanie, które rozstrzyga zamieszanie, jest proste: co właściwie przenoszą komunikaty DNS? Zwykły VPN może zainstalować resolver, aby objęte aplikacje znajdowały prywatne nazwy, a zmiana tego resolvera zmienia tylko rozwiązywanie nazw. Wykonaj poniższe kontrole po kolei, ponieważ trzy układy dzielą słownictwo i prawie nic więcej.

Rozdziel trzy układy

W pierwszym układzie VPN dostarcza resolver lub ustawienie polityki nazw. Dane aplikacji nadal podróżują przez własne połączenia sieciowe, a tunel wpływa tylko na to, który serwer odpowiada na zapytanie.

W drugim szyfrowany DNS chroni samą wymianę DNS. DNS przez HTTPS i DNS przez TLS opakowują zapytania do wybranego resolvera i nie przenoszą pakietów żadnej innej aplikacji. Nie ukrywają też nazw zapytań przed wybranym resolverem, co jest inną granicą zaufania niż ukrywanie ich przed siecią lokalną.

W trzecim współpracujący klient koduje inne dane w komunikatach DNS, a współpracujący punkt końcowy je odtwarza. Zwykła ścieżka resolvera staje się transportem, a resolver jest teraz składnikiem ścieżki danych, a nie usługą nazw.

Sprawdź, co przenoszą komunikaty DNS

Zmień resolver i obserwuj, czy zmienia się ścieżka ruchu aplikacji. Jeśli aplikacja nadal łączy się z tymi samymi adresami przez te same gniazda, zmieniłeś rozwiązywanie nazw i nic więcej.

Tunel przenoszony przez DNS wymaga odpowiedniego układu po stronie serwera. Iodine jest udokumentowanym przykładem: jego dokumentacja projektu opisuje tunel IP przez DNS i wymaga komponentu serwera, który rozumie kodowanie. Wprowadzenie adresu publicznego resolvera w Androidzie nie zapewnia tego punktu końcowego, a termin marketingowy wspólny dla dwóch produktów nie jest specyfikacją protokołu.

Przechwycenie jest rozstrzygającą kontrolą. Jeśli widzisz zwykłe zapytania do resolvera i nic więcej, nie ma tunelu. Jeśli widzisz ładunek zakodowany w nazwach zapytań i odpowiedziach, znalazłeś nośnik, a następne pytanie brzmi, ile może przenieść.

Sprawdź pojemność, zanim się zobowiążesz

DNS zaprojektowano do zapytań i odpowiedzi, a nie do dostarczania masowego. Narzut kodowania, limity rozmiaru komunikatów i zachowanie resolvera biorą swoją część nominalnej ścieżki, więc użyteczna pojemność jest mniejsza, niż sugeruje łącze bazowe. Każdą liczbę przepustowości, której nie zmierzyłeś na własnej ścieżce, traktuj jako hipotezę, a nie budżet. Mierz oba kierunki, ponieważ wysyłanie i pobieranie mogą trafić na różne granice na nośniku typu zapytanie-odpowiedź.

Klient musi też zdecydować, który ruch wchodzi do tunelu. Lokalny interfejs usługi VPN może zbierać pakiety, ale interfejs nic nie mówi o tym, jak zdalny transport je chroni lub przekazuje. Fragmentacja i retransmisja zachowują się inaczej, gdy nośnikiem jest protokół zapytania i odpowiedzi, a nie strumień, a połączenie pozostające otwarte niewiele mówi o opóźnieniu interaktywnym.

Mierz ruchem, który zamierzasz przenosić. Tunel, który wydaje się dobry dla okresowego sygnału, może być bezużyteczny dla sesji interaktywnej, i odwrotnie również to prawda.

Sprawdź bezpieczeństwo nośnika

Nie zakładaj, że enkapsulacja DNS zapewnia poufność lub silne uwierzytelnianie. Ścieżka resolvera i punkt końcowy tunelu widzą to, co ujawnia implementacja, a to ujawnienie różni się w zależności od projektu.

Szyfrowanie i wybór nośnika to odrębne właściwości. Tunel można szyfrować na zwykłej ścieżce IP, a tunel przenoszony przez DNS można zbudować z ochroną ładunku lub bez niej. W każdym razie zachowaj HTTPS aplikacji na miejscu i oceniaj rzeczywisty projekt bezpieczeństwa tunelu, a nie jego nazwę.

Jeśli wymaganiem jest prywatność wobec sieci lokalnej, szyfrowany DNS i tunel danych odpowiadają na różne jej części. Zanim wybierzesz jeden, zapisz, przed jakim obserwatorem się bronisz.

Dopasuj poprawkę do rzeczywistej awarii

W przypadku zwykłego wolnego VPN zastąpienie tunelem przenoszonym przez DNS dodaje ograniczony transport na wierzch problemu. Nie naprawia jakości radiowej, przeciążenia ani obciążenia serwera i zwykle czyni je bardziej widocznymi.

W przypadku awarii nazw prywatnych najpierw sprawdź zamierzoną politykę resolvera: który serwer powinien odpowiadać, które nazwy są w zakresie i czy klient może go używać. Następnie wybierz autoryzowany transport odpowiadający wymaganiu i przechowuj konfigurację resolvera w rejestrze zmian, aby następny incydent nie zaczynał tych samych poszukiwań od nowa.

Lista kontrolna jest krótka: zidentyfikuj układ, potwierdź, co przenoszą komunikaty, zmierz pojemność, a następnie przejrzyj zaufanie. Każdy krok niezgodny z objawem oznacza, że pozostałe dwa układy nadal są w grze.