Prywatny DNS Pritunla nie działa? Dodaj wąską trasę resolwera

Prywatne nazwy są rozwiązywane dla wszystkich w sieci firmowej i wygasają dla wszystkich w VPN. Resolwer odpowiada bramie, trasa do niego istnieje, a zapytanie i tak nigdy nie dostaje odpowiedzi. Brakuje nie innego publicznego resolwera ani szerszej trasy: brakuje adresu źródłowego, na który prywatny serwer DNS jest gotów odpowiedzieć.

Potwierdź, że resolwer odrzuca Twoją pulę klientów

Zacznij od dowodu, że awaria dotyczy źródła, a nie osiągalności. Z podłączonego klienta odpytaj prywatny resolwer bezpośrednio i obserwuj, czy żądanie kończy się przekroczeniem czasu, czy wraca jako odmowa. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 kończące się przekroczeniem czasu, podczas gdy to samo zapytanie z bramy kończy się sukcesem, wskazuje na politykę dostępu na resolwerze. Odpowiedź SERVFAIL wskazuje zupełnie inne miejsce, zwykle strefę lub przekazujący wyżej.

Zanotuj adres klienta przed testem. ip -4 addr show tun0 na kliencie albo dzierżawa pokazana w konsoli mówi, którą pulę widzi resolwer.

Następnie potwierdź, że ścieżka w ogóle istnieje. Trasa wysyłająca adres resolwera do tunelu jest warunkiem wstępnym, a nie rozwiązaniem; jeśli pakiety nigdy nie docierają, polityka źródła w ogóle nie jest brana pod uwagę. Sprawdź to za pomocą ip route get 10.40.0.53 na kliencie.

Dodaj jedną trasę do hosta zamiast tłumaczyć wszystko

Wytyczne Pritunla dotyczące prywatnego DNS opisują wąskie lekarstwo: trasę /32 z NAT dla adresu resolwera, z tym adresem wybranym jako serwer DNS klientów. Trasa zmienia źródło widziane przez resolwer tylko dla ruchu DNS. Ruch aplikacji zachowuje wybrany dla niego projekt zachowujący źródło.

Skonfiguruj ją przez obsługiwanego właściciela tras serwera, po sprawdzeniu istniejących tras pod kątem nakładania się. W powyższym przykładzie celem jest 10.40.0.53/32 z włączonym NAT, a pula klientów pozostaje 10.90.0.0/24. Nie tłumacz całego zakresu prywatnego, aby naprawić jedną usługę, ponieważ każda dalsza polityka opierająca się na rzeczywistym adresie klienta zacznie widzieć zamiast niego bramę. Potwierdź adres, który resolwer faktycznie otrzymuje, obserwując jego dziennik zapytań podczas testowego wyszukiwania. Sama trasa do hosta nic nie dowodzi o tłumaczeniu ani pozwoleniu.

Resolwer nadal musi zezwalać przetłumaczonemu źródłu na UDP i TCP, a jego odpowiedzi muszą móc wrócić. Zmiana źródła nie może utworzyć brakującej strefy ani rekordu.

Zdecyduj, czy zapytanie wysyła serwer, czy klient

Pritunl dokumentuje także układ proxy DNS powiązany z VPN Client DNS Mapping, w którym serwer przekazuje zapytania wyżej w imieniu klientów. W tym modelu źródło wyżej należy do własnego kontekstu sieciowego serwera, a wyjątek po stronie klienta to złe rozwiązanie.

Zidentyfikuj, który model jest aktywny, zanim cokolwiek dodasz. Trzy nakładające się naprawy, proxy, nadpisanie resolwera na kliencie i ręczny skrypt NAT zwykle oznaczają, że nikt nie ustalił: który komponent ma wysyłać zapytanie. Sprawdź też bootstrap: resolwer tylko prywatny nie może być jedynym sposobem znalezienia punktu końcowego przed istnieniem tunelu, a trwała zmiana resolwera nie powinna przeżyć połączenia.

Przetestuj prywatne wyszukiwanie, a nie publiczną stronę internetową

Po zastosowaniu zmiany i ponownym połączeniu sprawdź efektywną konfigurację resolwera klienta, a następnie rozwiąż nazwę, o której wiesz, że istnieje tylko w strefie prywatnej. dig intranet.example.net bez jawnego serwera pokazuje, czego klient faktycznie używa. Następnie wyślij żądanie na adres zwrócony przez to wyszukiwanie, ponieważ rozwiązywanie i dostęp do usługi to osobne kroki. Przeglądarka ładująca publiczne witryny przez DNS-over-HTTPS niczego nie dowodzi o prywatnej ścieżce resolwera systemu operacyjnego. Publiczny resolwer pomocniczy też nie jest autorytetem dla strefy wewnętrznej.

Zapisz adres resolwera, trasę /32 i ustawienie DNS klienta razem w notatkach serwera. Połowa tej konfiguracji przywrócona sama odtwarza pierwotną awarię.

Na koniec potwierdź, że tunel nadal kieruje ruch do celu aplikacji po udanym DNS. Trasa, dostęp do usługi i uwierzytelnianie pozostają niezależne od rozwiązywania nazw, a działające wyszukiwanie nic nie mówi o przepustowości. Jeśli prywatna strona jest wolna, ale się rozwiązuje, resolwer wykonał swoją pracę, a problem przeniósł się na ścieżkę.