Nazwa punktu końcowego VPN a nazwa prywatnej usługi: dwóch właścicieli

Dwie nazwy mogą opisywać ten sam oddział i odpowiadać na zupełnie różne pytania. vpn.branch.example mówi zdalnemu peerowi, gdzie znaleźć punkt końcowy VPN, i musi zostać rozwiązana, zanim powstanie jakikolwiek tunel. inventory.branch.example mówi upoważnionemu użytkownikowi, gdzie mieszka prywatna aplikacja, i ma znaczenie dopiero po podniesieniu tunelu. Utrzymanie jednej nie robi nic dla drugiej.

Nazwij oba rekordy, zanim zaczniesz debugować którykolwiek

Zapisz oba wraz z ich właścicielami. Dla punktu końcowego zapisz, kto aktualizuje publiczny adres i jak klient VPN odświeża swoją odpowiedź. Dla usługi zapisz, kto jest właścicielem prywatnego adresu, która strefa trzyma rekord i które resolvery powinny za niego odpowiadać.

Ta krótka lista zapobiega najczęstszej błędnej diagnozie w tej dziedzinie: restartowaniu działającego tunelu oddziału, aby naprawić rekord, który żyje wyłącznie w jego wnętrzu. Tunel jest transportem dla nazwy usługi, a nie jej autorytetem.

Gdy proponowana jest zmiana, zapytaj, którego z dwóch rekordów dotyczy. Jeśli nikt nie potrafi odpowiedzieć, zmiana nie jest gotowa do zaplanowania.

Punkt końcowy musi zostać rozwiązany, zanim powstanie jakikolwiek tunel

Załóżmy, że połączenie internetowe oddziału otrzymuje nowy publiczny adres. Aktualizator punktu końcowego publikuje nowy adres, a zdalna implementacja VPN musi móc odczytać zmienioną odpowiedź. Którykolwiek resolver dostarcza tę odpowiedź, musi być osiągalny bez tunelu, inaczej klient goni nazwę, którą może rozwiązać dopiero po połączeniu się z tym, czego nie potrafi znaleźć.

Warto powiedzieć tę zależność rozruchową wprost, bo łatwo ją stworzyć przez pomyłkę, gdy wszystkie wewnętrzne resolvery siedzą za VPN. Utrzymuj ścieżkę przed tunelem do wyszukiwania punktu końcowego i potwierdź zachowanie klienta przy ponownym połączeniu, zamiast zakładać, że nowa odpowiedź jest przejmowana natychmiast.

Dynamiczny DNS ma też granice, których aktualizacja rekordu nie może przekroczyć. Aktualizacja rekordu nie otwiera portu zapory, nie tworzy mapowania NAT i nie dowodzi tożsamości peera. Opublikowany adres z zamkniętym portem daje klienta, który poprawnie rozwiązuje nazwę i nadal nie może się z niczym połączyć.

Wreszcie, działający klient może nadal używać zbuforowanego punktu końcowego, dopóki nie połączy się ponownie. Oddziel w notatkach publikację, bufor i politykę ponownego łączenia, aby przestarzały peer nie został wzięty za zepsuty aktualizator.

Nazwa usługi opisuje, gdzie mieszka aplikacja

Załóżmy teraz, że tunel pozostaje zdrowy, ale serwer inwentarza przenosi się z 172.26.14.20 na 172.26.14.35. Publiczny rekord punktu końcowego nie jest dotknięty, natomiast prywatny rekord usługi musi się zmienić. Użycie adresu zarezerwowanego dla tej usługi lub przypisania statycznego czyni to rzadszym; upoważniona ścieżka aktualizacji obsługuje przypadki, gdy jest to zamierzone.

Mieszają się tu dwa mechanizmy aktualizacji. RFC 2136 definiuje protokół dodawania i usuwania rekordów DNS w strefie, podczas gdy komercyjny dostawca dynamicznego DNS może udostępniać zupełnie inne API HTTP do innego celu. Użycie jednego nie oznacza, że drugie istnieje w Twoim środowisku. Sprawdź, który mechanizm Twoja strefa faktycznie akceptuje, zanim napiszesz przeciwko niemu aktualizator.

Poprawna odpowiedź prywatna to tylko pierwszy warunek. Aby zdalny wywołujący mógł jej użyć, klient potrzebuje resolvera przenoszącego strefę prywatną, polityki zezwalającej na zapytania do tego resolvera oraz przekazywania dla adresu, który wraca. Nazwa rozwiązująca się na adres nieosiągalny dla klienta powoduje przekroczenie limitu czasu, które wygląda jak awaria serwera.

Przetestuj obie ścieżki osobno

Sprawdź punkt końcowy z zewnątrz tunelu, a usługę od środka, i zachowaj wyniki jako dwa niezależne fakty:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Jeśli pierwsze zapytanie zawiedzie, problemem jest publiczna publikacja lub ścieżka rozwiązywania przed tunelem i żadna wewnętrzna zmiana nie pomoże. Jeśli drugie zwróci adres, ale trzecie nie pokaże trasy przez tunel, warstwa DNS jest w porządku, a polityka przekazywania nie.

Uruchamiaj parę po każdej zmianie adresu i notuj, który rekord się przesunął. Przekazanie, które mówi tylko „DNS został zaktualizowany”, zostawia następnego inżyniera zgadującego, który z dwóch cykli życia faktycznie się odbył.