Dzielony DNS i VPN: reguły domen nie są trasami IP

Twój laptop rozwiązuje intranet.corp przez tunel, podczas gdy gitlab.com nadal idzie do resolvera dostawcy, i to jest układ, który działa zgodnie z projektem. Powstał z dwóch odrębnych decyzji: reguła dopasowania nazwy wybrała resolver, a trasa przyniosła odpowiedź z powrotem. Zepsuj którąkolwiek z nich, a przeglądarka pokaże błąd, który z zewnątrz wygląda tak samo. Większość raportów o dzielonym DNS opisuje drugi błąd, cytując przy tym dowody na pierwszy.

Dwie połowy żyją w różnych miejscach i zwykle są edytowane przez różnych ludzi. Jedna to polityka DNS przypięta do profilu VPN, druga to trasa, którą tunel instaluje lub wstrzymuje. Debugowanie zatrzymuje się, gdy nikt nie ustali, która połowa faktycznie się przesunęła.

Dwie decyzje ukryte w jednym żądaniu

Połowa nazwy to obiekt polityki, a nie trasa. W Windows to polityka rozwiązywania nazw w profilu VPN; na platformach Apple zbiór domen dopasowania w obiekcie ustawień DNS; w Linuksie domena routingu, wiersz dzielonego resolvera albo kolejność przełącznika usług nazw. Połowa ścieżki to zwykły routing, instalowany przez tunel lub ręcznie, i nie ma pojęcia, czym jest nazwa hosta. Profil, który dopuszcza sufiks, decyduje tylko, kto odpowie; nigdy nie czyni odpowiedzi osiągalną.

Szybki test objawów je rozdziela: zastąp nazwę adresem. Jeśli adres działa, ścieżka jest w porządku, a reguła błędna. Jeśli adres też zawodzi, reguła może być poprawna, a ścieżki może brakować.

Jak każda platforma wyraża tę samą regułę nazwy

Zamiar jest identyczny, a nazwy pól nie. Przykład skopiowany z jednego klienta do drugiego jest parsowany czysto i nigdy nie pasuje. Trzy formy wyglądają tak:

Domena dopasowania lub routingu to test sufiksu, więc intranet.corp obejmuje git.intranet.corp i nie obejmuje corp.intranet, a odwrócenie tego to najczęstszy błąd w całej konfiguracji. Windows nosi mapowanie jako politykę rozwiązywania nazw przypiętą do profilu, z własną kolejnością priorytetów wobec dowolnej listy sufiksów, którą interfejs już miał. Platformy Apple przypinają domeny dopasowania do obiektu ustawień DNS rozszerzenia sieciowego, a system stosuje je dla każdego ograniczonego resolvera. Żadna z tych form nie jest trasą i żadna nie może uczynić nieosiągalnego adresu osiągalnym. Referencja polityka rozwiązywania nazw w Windows wymienia nazwy pól i reguły priorytetów dla tej platformy, a nie są to te, których używają dokumenty Apple lub systemd.

Poprawna odpowiedź nadal potrzebuje ścieżki

Odpowiedź resolvera to tylko adres, a aplikacja nadal musi do niego dotrzeć. Projekt dzielonego tunelu często wypycha 10.20.0.0/16 i wstrzymuje trasę domyślną, więc wewnętrzna nazwa się rozwiązuje, a połączenie potem zawiesza. Odwrotny przypadek jest równie częsty: trasa istnieje, publiczny resolver odpowiada prywatnej nazwie NXDOMAIN, a awaria trafia do rejestru jako problem routingu. Testowanie ścieżki najpierw sprawia, że wpatrujesz się w trasy dla nazwy, która nigdy by się nie rozwiązała.

Istnieje też trzecia brama, której żadna połowa nie obejmuje. ACL na bramie, reguła zapory albo polityka po stronie klienta mogą odrzucić połączenie po tym, jak obie decyzje były poprawne. Gdy nazwa się rozwiązuje, trasa istnieje, a połączenie mimo to przekracza limit czasu, przestań testować DNS.

Testowanie nazw i ścieżek w stałej kolejności

Wybierz kolejność i się jej trzymaj, inaczej będziesz gonić krok, który zawiódł ostatnio. Rozwiąż udokumentowaną pełną nazwę wewnętrzną, potwierdź, że odpowiedź jest adresem, który tabela tras potrafi unieść, a potem powtórz z nazwą publiczną, aby dowieść, że tunel nie przechwycił wszystkiego. Na hoście systemd zapytanie i domena routingu resolvera są o jedno polecenie od siebie:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Klient Windows zadaje te same dwa pytania innymi poleceniami cmdlet. Drugie zgłasza interfejs, którego system faktycznie by użył:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Jeśli wyszukanie zwraca adres, a kontrola ścieżki wskazuje interfejs fizyczny, reguła nazw zadziałała, a trasa nie. Jeśli krótka nazwa zawodzi, podczas gdy pełna się rozwiązuje, błędna jest lista sufiksów, a nie resolver.

Gdzie porównanie zwykle idzie nie tak

Pierwszy błąd to pytanie niepowiązanego publicznego resolvera o nazwę prywatną i czytanie odmowy jako dowodu o VPN. Drugi to założenie, że działające publiczne wyszukanie dowodzi ścieżki resolvera tunelu. Trzeci to traktowanie dzielonego tunelowania i dzielonego DNS jako jednej decyzji projektowej, gdy wdrożenie może być poprawne w jednym i zepsute w drugim. Każdy błąd daje pewne wnioski z testu, który nigdy nie ćwiczył obwinianej części.

Przeglądarka z własnym bezpiecznym DNS też może ominąć regułę systemową, dlatego to, że jedna przeglądarka zawodzi, a inna działa, nie jest sprzecznością. Porównuj resolver, który odpowiedział, nie przeglądarkę, która się skarżyła.

Gdy obie połowy są widoczne, pozostałe pytanie jest pytaniem o politykę, a nie technicznym: które przestrzenie nazw należą do organizacji, kto jest właścicielem każdej odpowiedzi i które z nich powinny w ogóle opuścić maszynę. Zapisz to obok profilu, bo następna osoba, która dotknie reguły, będzie tego potrzebować.