Dwa VPN-y, jeden resolver: wygrywa ten, kto pisał ostatni

Połączone są dwa klienty VPN, jeden do pracy, drugi do sieci laboratoryjnej, a nazwy wewnętrzne są rozwiązywane tylko dla klienta, który połączył się ostatni. Ten wzorzec wygląda jak błąd w jednym z klientów. Zwykle jest to przewidywalny wynik dwóch programów, które zapisują tę samą konfigurację resolvera bez uzgodnienia, do kogo należy która nazwa.

Mit: najnowszy VPN posiada DNS

Nie ma ogólnej zasady, że wygrywa najnowsze połączenie. To, co się dzieje, zależy od mechanizmu platformy i od tego, jak każdy klient go zapisuje. Klient, który zastępuje plik resolvera, daje jeden wynik; klient, który dodaje domenę na połączenie, daje inny; klient, który nic nie robi, pozostawia poprzedni stan nietknięty.

Zaobserwowane zachowanie jest więc właściwością obu implementacji, a nie udokumentowanym priorytetem. Rozumowanie oparte wyłącznie na kolejności uruchamiania będzie czasem trafne, a czasem błędne w sposób trudny do odtworzenia. Zamiast tego zapisz mapowanie. Projekt, który żyje w dwóch klientach, nie jest projektem.

Przyporządkuj przestrzenie nazw do resolverów

Wypisz prywatne sufiksy i resolver wymagany przez każdą sieć, a następnie zdecyduj, gdzie mają trafić nazwy publiczne. Ta lista jest projektem. Bez niej klienty podejmują decyzję przez przypadek.

Platforma obsługująca DNS na połączenie lub domeny routingu może świadomie wyrazić podział: jedna domena trafia na jedno połączenie, inna domena na drugie, a wszystko pozostałe podlega jawnej wartości domyślnej. Dwa płaskie skrypty nadpisujące ten sam plik nie zachowają tego projektu, bo każdy z nich uważa, że posiada całą konfigurację.

W systemie Windows tabela zasad rozwiązywania nazw może kierować sufiksy do konkretnych serwerów, a klient VPN może tam instalować reguły. Sprawdzaj zasady, a nie listę adapterów, bo to nie lista adapterów rozwiązuje nazwę.

Utrzymuj ścieżkę bootstrap

Każdy klient musi znaleźć własny punkt końcowy, zanim będzie mógł korzystać z usługi, którą ten punkt oferuje. Jeśli nazwa hosta punktu końcowego może być rozwiązana tylko przez tunel, a tunel potrzebuje rozwiązanej nazwy hosta, masz cykliczną zależność, która objawia się przekroczeniem limitu czasu połączenia. Utrzymuj jedną ścieżkę bootstrap poza oboma tunelami. Nie kosztuje nic do dnia, w którym ratuje połączenie.

Patrz na ścieżkę do każdego resolvera, nie tylko na nazwę dla niego skonfigurowaną. Resolver osiągalny tylko przez drugi tunel zachowuje się jak brakujący, a objawem jest przekroczenie limitu czasu, a nie błąd routingu.

Nakładające się adresy nie są problemem DNS

Dwóch sieci prywatnych używających tego samego zakresu adresów nie da się naprawić kolejnością DNS. Jeśli oba tunele roszczą sobie 10.0.0.0/8, poprawnie rozwiązana nazwa nadal wskazuje adres, do którego host nie potrafi routować właściwego tunelu. Wymaga to rozwiązania na poziomie adresu, takiego jak odrębne zakresy, przestrzeń nazw lub tłumaczenie, a nie kolejnego ustawienia resolvera. Wczesne rozstrzygnięcie tego pozwala uniknąć długiego objazdu przez konfigurację DNS, która nigdy by nie działała.

Porównaj przydziały adresów obu tuneli, zanim obwinisz rozwiązywanie nazw. Gdy obie strony wypychają ten sam prefiks, host trzyma dla niego jedną trasę, a nazwa rozwiązana przez drugi tunel nadal trafia na adres należący do pierwszego tunelu. Odrębne zakresy, przestrzeń nazw dla każdej sieci lub tłumaczenie to poprawki; po połączeniu każdego klienta potwierdź, że tabela tras pokazuje zamierzoną ścieżkę.

Udowodnij to prawdziwymi aplikacjami

Wybierz dwa hosty istniejące tylko we własnej przestrzeni nazw i jedną nazwę publiczną, a następnie rozwiąż każdy z nich przez klienta, który powinien go posiadać. Poprawna odpowiedź oczekiwanego resolvera nie dowodzi, że aplikacja dociera do hosta, bo trasa do tego adresu nadal może zawieść. Po każdym zapytaniu wykonaj test połączenia z programu, który użytkownik naprawdę uruchomi.

Klient z własną opcją szyfrowanego DNS może obejść zasady, które właśnie sprawdziłeś, więc sprawdź to ustawienie w ramach przeglądu. Następnie połącz ponownie oba klienty w kolejności wspieranej przez dostawcę i powtórz zapytania; jeśli odpowiedzi zamieniają się przy zmianie kolejności, konkurencyjny zapisujący nadal posiada część konfiguracji. Zanim cokolwiek zmienisz, ustal, który komponent instaluje regułę - klient, profil systemu operacyjnego czy agent zarządzania. Zapisz kolejność i właścicieli, aby następna osoba nie musiała odkrywać ich ponownie.