Tunel działa, więc dlaczego prywatna nazwa nadal zawodzi?

Wszystko w połączeniu wygląda dobrze: tunel działa, a konsola pokazuje prywatny punkt końcowy, ale każde żądanie zawodzi na rozwiązywaniu nazw. Naturalnym krokiem jest obwinienie tunelu, który zwykle okazuje się niewinny. Zapytanie trafia do serwera, który nic nie wie o strefie prywatnej. Żadna zmiana routingu nie zmieni tej odpowiedzi, bo problem polega na tym, kogo zapytano.

Który resolver otrzymał zapytanie?

Znajdź resolver przypisany do każdego łącza, zanim w ogóle spojrzysz na tunel. Linux pokazuje serwery dla każdego łącza przez polecenie stanu resolvera, a macOS pokazuje resolvery z zakresem w zrzucie konfiguracji DNS. Jeśli odpowiedź nadal pochodzi od domowego routera, łącze tunelu nigdy nie zostało zapytane.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Mieszają się tu dwa etapy: serwer wypychający adres resolvera i klient instalujący go na aktywnym łączu. Profil może zawierać tę opcję, a log może pokazywać, że dociera, podczas gdy system operacyjny nadal używa starego serwera. Porównaj log z tym, co zgłasza łącze, i zaufaj łączu.

Użyj adresu, na który sieć chmurowa naprawdę odpowiada

Sieci chmurowe zwykle odpowiadają na prywatne nazwy przez zarezerwowany adres przesunięty o dwa od podstawy zakresu, więc sieć zaczynająca się od 10.0.0.0 odpowiada na 10.0.0.2. Niektórzy dostawcy publikują też lokalny dla łącza resolver, który działa bez znajomości zakresu, co pomaga, gdy sieć zbudował ktoś inny. Zapytaj adres kandydata bezpośrednio, zanim wyślesz go komukolwiek. Adres, który nie jest resolverem, wygląda dokładnie jak odrzucenie przez zaporę, bo zapytanie po prostu nigdy nie dostaje odpowiedzi.

Jeśli bezpośrednie zapytanie odpowiada od wewnątrz sieci, ale nie przez tunel, resolver jest w porządku, a ścieżka między dwoma punktami nie. Ten wynik przenosi dochodzenie na trasy, przekazywanie i reguły dostępu, a nie na profil klienta.

Tunel nie przenosi przestrzeni nazw

Pakiety przechodzą; nazwy nie. Każdej stronie trzeba powiedzieć, która przestrzeń nazw należy do drugiej, a to osobny obiekt należący do tego, kto trzyma strefę. Zwykłą formą jest przekazywanie dla jednej przestrzeni nazw, skierowane do resolvera osiągalnego przez tunel.

W praktyce każdy kierunek potrzebuje własnej reguły, bo strona posiadająca strefę musi wysłać zapytanie dalej. Oba kierunki wymagają, aby źródło zapytania było rutowane i dozwolone, a strona odpowiadająca musi zwracać odpowiedzi przez tunel, a nie do internetu. Utrzymuj przekazywanie wąskie, tak aby tylko prywatna przestrzeń nazw zależała od łącza. Wysyłanie każdego zapytania przez nie zamienia małą zależność w całkowitą awarię w chwili, gdy tunel padnie.

Przejdź granice po kolei

Przetestuj resolver zainstalowany na aktywnym łączu, potem bezpośrednie zapytanie do tego resolvera, potem to samo zapytanie z drugiej strony, a na końcu aplikację używającą tej samej nazwy. Każdy krok izoluje jedną granicę, więc awaria mówi, gdzie patrzeć, zamiast zaczynać dochodzenie od nowa. Odpowiedź, która działa, gdy aplikacja zawodzi, wskazuje na zaufanie certyfikatu lub politykę API, a nie na DNS. Te usterki są prawdziwe i żadna zmiana resolvera ich nie naprawi.

Zapisz, który krok zawiódł. Ta jedna linia to wszystko, czego potrzebuje następna osoba, a jej zapisanie zajmuje dziesięć sekund.

Trzymaj łańcuch tam, gdzie następna osoba go znajdzie

Zapisz wypchnięty resolver, regułę przekazywania, dozwolone źródło zapytań i odpowiadający punkt końcowy w jednym miejscu. Gdy prywatna nazwa znowu zawiedzie, zapis pokaże, czy tunel się przesunął, czy adres resolvera się zmienił, czy reguła została zwężona. Bez tego każdy incydent zaczyna się od zera i kończy tymi samymi trzema domysłami.

Trzymaj zapis wystarczająco krótki, by pozostał dokładny: cztery linie, data i nazwisko właściciela każdej części. Nieaktualny zapis jest gorszy niż żaden, bo wygląda autorytatywnie, choć jest błędny.