Twoja domena VPN w dnsmasq nie jest transferem strefy

Szukasz strefy firmowej w konfiguracji dnsmasq klienta, nie znajdujesz jej i wnioskujesz, że VPN nie wypchnął swojej domeny. To, co zostało wypchnięte, to wskazówka routingu, a nie strefa. Klient zapisuje domenę i resolver, który ma za nią odpowiadać, a zarządzany backend zamienia to na warunkowe przekazywanie. Szukanie w niewłaściwym miejscu daje pewną i całkowicie fałszywą diagnozę.

To, co zaakceptował klient, nie jest tym, co zaproponowała brama

Brama może zaproponować resolver, domenę i trasę potrzebną do dotarcia do tego resolvera, a klient może zaakceptować wszystkie trzy albo żadne z nich. Zaimportowany profil, skrypt pomocniczy lub polityka ignorująca wypchnięte opcje mogą pozostawić zaakceptowany zbiór pusty, podczas gdy strona serwera wygląda poprawnie. Zacznij od zapisanego stanu klienta, a nie od konfiguracji serwera, ponieważ ten stan jest tym, co resolver faktycznie otrzymuje. Jeśli zaakceptowanej domeny brakuje, nic dalszego nie będzie miało znaczenia. Sprawdź właściwości DNS połączenia, zanim przejrzysz jakikolwiek cache.

To rozróżnienie wyjaśnia większość zgłoszeń o domenie, która nigdy nie dotarła. Została zaproponowana i nie została zastosowana.

Dwa rodzaje wpisów domeny

Połączenie może nieść zwykłe domeny wyszukiwania i domeny tylko do routingu, a drugi rodzaj zaczyna się od tyldy. Domena wyszukiwania kieruje zapytania i pozwala rozwijać krótkie nazwy, co jest wygodne na stacji roboczej i zaskakujące na serwerze. Domena tylko do routingu mówi, że zapytania dla tego sufiksu mają trafiać do określonych serwerów bez zmiany sposobu rozwiązywania krótkich nazw. Zapisywanie tej samej domeny na oba sposoby nie jest redundancją, ponieważ oba wpisy robią różne rzeczy.

Dla prywatnej przestrzeni nazw zwykle chcesz formy tylko do routingu. Utrzymuje ona firmowy sufiks skierowany do firmowego resolvera i zostawia wszystko inne w spokoju.

localhost w resolv.conf nie jest błędem

Gdy używany jest lokalny resolver buforujący, plik systemowy wskazuje adres loopback i nic więcej. Ten wpis identyfikuje lokalnego nasłuchującego, a nie serwery nadrzędne, które przekazał mu menedżer. Firmowy adres będzie zasadnie nieobecny w pliku.

Zastąpienie tego wpisu publicznym resolverem to klasyczna błędna poprawka. Przywraca publiczne rozwiązywanie nazw i w tej samej zmianie odrzuca politykę warunkową.

Nie myl backendów

Zarządzana instancja dnsmasq i systemowy resolver to różne programy z różną konfiguracją i różnymi widokami stanu. Polecenie stanu dla jednego nie mówi nic użytecznego o drugim.

Ustal, którego backendu ma używać menedżer, a następnie czytaj wygenerowaną konfigurację tego backendu, a nie plik ogólnodystrybucyjny, który przypadkiem istnieje. Menedżer zapisuje własną konfigurację instancji i obsługuje niestandardowe opcje dla tej instancji, więc edycja niepowiązanego pliku globalnego nic nie zmienia i wygląda jak zmiana bez efektu. Uruchamianie drugiego daemona na porcie 53 jest gorsze niż bezużyteczne, ponieważ teraz dwa programy nie zgadzają się co do tego, kto jest właścicielem portu. Najpierw ustal właściciela, a potem edytuj tam, gdzie ten właściciel czyta.

Testuj przestrzeń nazw, nie tylko odpowiedź

Zapytaj o jedną dozwoloną nazwę prywatną i jedną publiczną nazwę kontrolną zwykłą ścieżką aplikacji. Bezpośrednie zapytanie do serwera firmowego dowodzi, że rekord istnieje; nie dowodzi, że klient wybrał ten serwer. Drugie zapytanie jest tym, które testuje politykę.

Następnie powtórz to po ponownym połączeniu i po rozłączeniu. Skojarzenie powinno podążać za cyklem życia połączenia, a nazwy prywatne powinny przestać się rozwiązywać, gdy tunel zniknie, zamiast wracać do publicznego resolvera, który odpowiada za ten sam sufiks. Jeśli jednak wrócą, znalazłeś wyciek, co jest inną wadą niż zepsute wyszukiwanie. Zapisz, który backend działał, jakie domeny zastosowano i co zwróciło każde zapytanie.