Które połączenie odpowiada: domeny routingu dla DNS VPN z dzielonym tunelem

Zwykłe przeglądanie zostaw na połączeniu lokalnym, a nazwy firmowe rozwiązuj przez serwer DNS dostarczany przez tunel. Wyłączenie trasy domyślnej VPN daje pierwszą połowę i zostawia drugą niezbudowaną. Dalej są brakujące ustawienie, znak interpunkcyjny, który zmienia jego znaczenie, i jedyne polecenie pokazujące, które połączenie naprawdę odpowiedziało. W całym tekście zakładamy NetworkManager i systemd-resolved, bo właśnie ta para jest miejscem, gdzie zwykle zaczyna się zamieszanie.

Krok pierwszy: oddziel trasę od resolvera

ipv4.never-default odpowiada na pytanie o routing i powstrzymuje NetworkManager przed zainstalowaniem tego połączenia jako drogi dla całego ruchu IPv4. Domena routingu DNS odpowiada na inne pytanie: które serwery nazw którego połączenia otrzymują zapytanie o pasujący sufiks. Żadne nie implikuje drugiego, a profil może latami mieć jedno, gdy brakuje drugiego. Tylko trasa oznacza, że tunel niesie podsieci firmy, a jego resolver odpowiada na nazwy firmy, reszta zostaje nietknięta.

Ustaw tylko właściwość trasy, a nazwy wewnętrzne zawiodą, zwykle z przekroczeniem czasu, które brzmi jak zepsuty tunel. Ustaw tylko domenę, a po cichu dodałeś sufiks wyszukiwania do każdej krótkiej nazwy na maszynie. Oba błędy wysyłają zgłoszenie do serwera VPN, który rzadko jest tą częścią, która jest zła.

Krok drugi: dodaj do profilu domenę tylko do routingu

Załóżmy, że połączenie nazywa się corp-vpn, sufiks firmy to internal.example, a resolver tunelu jest już osiągalny. Najpierw odczytaj bieżące wartości, bo poniższe polecenia zmieniają właściwości, które mogą już mieć wpisy.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Zastąp własną nazwą połączenia i sufiksem, bo powyższe wartości są ilustracyjne. Znak plus jest ważniejszy, niż wygląda: z nim wartość dopisuje się do istniejącej listy, a bez niego właściwość jest zastępowana i niepowiązane domeny znikają z profilu, który działał wczoraj. Tylda zmienia zachowanie, a nie styl, i akapit poniżej wyjaśnia, co wybiera. Zachowaj czytanie przed pisaniem, aby forma zastąpienia nigdy cię nie zaskoczyła.

Wiodąca tylda oznacza domenę tylko do routingu, więc pasujące zapytania idą do serwerów tego połączenia, a sufiks nie jest dopisywany do krótkich nazw. Usuń tyldę, a ten sam ciąg staje się także sufiksem wyszukiwania, czyli innym wynikiem, którego ludzie rzadko chcą. Oba ustawienia powyżej są IPv4, więc profil dwustosowy potrzebuje ipv6.never-default i tej samej domeny routingu w ipv6.dns-search, inaczej strona IPv6 nadal używa trasy domyślnej i nazwy wewnętrzne tam zawodzą.

Krok trzeci: zapytaj resolvectl, które połączenie odpowiedziało

Uruchom resolvectl status i odczytaj serwery DNS oraz domeny każdego połączenia, potem uruchom resolvectl query host.internal.example na prawdziwej nazwie wewnętrznej, o którą wolno ci pytać. Drugie polecenie to jedyny bezpośredni dowód, że domena routingu robi swoje, bo nazywa połączenie, które odpowiedziało. Sam wykaz stanu dowodzi konfiguracji; zapytanie dowodzi rozwiązania.

systemd-resolved wybiera najlepiej pasującą domenę routingu, więc bardziej szczegółowa domena na innym połączeniu nadal może wygrać wyścig. Jeśli zapytanie wróci z połączenia, którego się nie spodziewałeś, przeczytaj listy domen, zanim dotkniesz serwera DNS VPN. Domena główna ~. pasuje do wszystkiego, a jeśli już istnieje, twoja szczegółowa domena nadal wygrywa dla swoich nazw, podczas gdy połączenie odpowiada na znacznie więcej, niż prosiłeś. Usuń lub zawęź ten wpis główny, gdy intencją były tylko nazwy firmy.

Jeśli połączenie VPN w ogóle nie wymienia serwera DNS, klient nigdy go nie zarejestrował. Domena routingu bez serwera za sobą zawodzi inaczej niż brakująca domena, więc najpierw napraw rejestrację.

Krok czwarty: gdy nazwa się rozwiązuje, ale usługa nie

Poprawna odpowiedź dowodzi tylko, że rozwiązanie zadziałało, a aplikacja nadal potrzebuje trasy do otrzymanego adresu. Ta trasa musi przetrwać skonfigurowaną przed chwilą dzieloną trasę domyślną, więc sprawdź ją, zanim znowu obwinisz DNS. Potem sprawdź osiągalność na porcie usługi, bo udział plików lub usługa katalogowa zawodzi przy rozwiązaniu, routingu lub uwierzytelnianiu i w każdym przypadku daje bardzo podobne komunikaty. Trzymaj te trzy warstwy osobno, gdy raportujesz wynik, inaczej następna osoba ponownie sprawdza DNS, który już był poprawny.

Zmiana w Sambie, która krąży obok tego pytania, dotyczy warstwy dostępu, a nie wyboru DNS. Zastosowanie jej do awarii rozwiązywania nazw to sposób, w jaki mały problem zyskuje drugi.

Krok piąty: nie zastępuj resolvera, aby naprawić brakującą domenę

Porada, która nadpisuje plik resolvera lub instaluje inny menedżer resolvera, rozwiązuje inny problem. To zmiany integracji systemu z własnymi trybami awarii i żadna z nich nie dodaje domeny routingu, której nigdy nie skonfigurowano. Ustal, który komponent posiada rozwiązywanie nazw na maszynie, zanim go zastąpisz, bo na pulpicie NetworkManager z systemd-resolved ta własność jest już zdefiniowana. Walka z nią to sposób, w jaki działająca konfiguracja staje się czymś, czego nikt nie potrafi odtworzyć.

Kolejność pracy: potwierdź, że tunel dostarcza resolver, dodaj domenę tylko do routingu, połącz ponownie przez kontrolki profilu, zweryfikuj połączenie, które odpowiada, a potem przetestuj usługę na jej porcie. Ta sekwencja zostawia wynik, który możesz przekazać następnej osobie bez drugiej rozmowy.