Prywatna nazwa DNS czy samo IP? Zdecyduj, zanim to udostępnisz

Dwie kwestie mieszają się, gdy prywatna usługa zostaje otwarta dla użytkowników zdalnych. Pierwsza to, jakiej nazwy mają używać klienci; druga to, jakie źródła usługa ma dopuszczać. Odpowiedz na nie w tej kolejności, bo poprawna nazwa za błędną regułą dostępu nadal zawodzi, a poprawna reguła za nazwą, która się nie rozwiązuje, nigdy nie zostaje przetestowana.

Warunek pierwszy: jaką ścieżkę resolvera mają klienci?

Prywatna nazwa działa tylko wtedy, gdy resolver klienta potrafi na nią odpowiedzieć. To oznacza, że upoważniony klient zdalny musi dotrzeć do serwera DNS, który trzyma strefę, albo przez tunel, albo przez resolver, który organizacja już prowadzi dla użytkowników zdalnych. Tunel jest transportem, nie katalogiem. Daje klientowi ścieżkę do resolvera i nie mówi mu, o którą strefę pytać.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Publiczny resolver nie pozna prywatnej strefy dlatego, że laptop połączył się z VPN.

Przyrostek zasługuje na tę samą uwagę. Użyj subdomeny domeny, którą organizacja kontroluje, aby własność i planowanie certyfikatów pozostały jawne. Unikaj .local: specyfikacja multicast DNS wiąże ten przyrostek z rozwiązywaniem link-local, a trasowany tunel nie odtwarza tego zachowania za ciebie.

Warunek drugi: jakie źródło otrzymuje usługa?

Reguły dopuszczania są pisane wobec adresów, więc użytecznym pytaniem jest, jaki adres usługa widzi po routingu i tłumaczeniu. Dla przykładowej usługi pod 10.20.30.40 klienci biurowi przychodzą z 10.20.30.0/24, a klienci zdalni z osobnej puli, na przykład 10.99.0.0/24.

Jeśli brama tłumaczy zdalną pulę, usługa widzi tłumacza, a reguła napisana dla 10.99.0.0/24 nie będzie pasować.

Czytaj to od strony usługi, a nie od strony klienta. Dziennik nasłuchu lub przechwycenie pakietów na hoście usługi pokazuje źródło, które faktycznie dotarło; adres samego klienta jest tylko domysłem co do tego, co przetrwało ścieżkę.

Warunek trzeci: czy nazwa jest związana z usługą, czy z hostem?

Nazwa wskazująca adres jednej maszyny wiąże każdego klienta z tą maszyną. Nazwa wskazująca moduł równoważenia obciążenia lub stabilny adres usługi przetrwa wymianę hosta za nią. Wybieraj świadomie, bo zmiana tego później oznacza zmianę zakładek każdego klienta i podmiotu każdego certyfikatu.

Dla jednej wewnętrznej usługi bezpośredni rekord jest zwykle w porządku i łatwiejszy do przemyślenia.

Dla wszystkiego, co będzie wymieniane, odbudowywane lub skalowane, stabilny front jest wart dodatkowej konfiguracji. Test jest prosty: jeśli możesz wymienić backend bez informowania użytkowników, nazwa jest związana z usługą; jeśli nie, jest związana z hostem.

Przetestuj obie decyzje osobno

Najpierw rozwiąż, potem się połącz. Test rozwiązywania, który zwraca oczekiwany adres, dowodzi ścieżki nazwy i nic nie mówi o dostępie. Test połączenia dowodzi ścieżki i reguły razem, więc uruchom go dopiero po udanym rozwiązaniu.

curl -sv --max-time 5 https://files.corp.example/health

Następnie przetestuj raz zabronione źródło i zapisz wynik.

Trzymaj oba zapisy osobno w dokumentacji: nazwę i jej strefę, dopuszczone źródła i właściciela reguły. Gdy jeden się zmienia, drugi nie musi.

Gdzie decyzja zwykle idzie nie tak

Częstą awarią jest usługa publikowana pod nazwą, która rozwiązuje się tylko w sieci biurowej, z regułą dopuszczania, która dopuszcza tylko zakres biurowy. Użytkownicy zdalni zgłaszają wtedy zepsutą usługę, która w rzeczywistości jest dwoma osobnymi pominięciami. Drugą częstą awarią jest odwrotność: szeroka reguła dopuszczania dodana, by usunąć problem z nazwą, zostawia usługę osiągalną ze źródeł, których nikt nie zamierzał. Oba są pominięciami w konfiguracji i z perspektywy użytkownika wyglądają tak samo.

Żadnego z błędów nie widać z jednego udanego testu. Dlatego obie decyzje zasługują na osobne zapisy i osobne testy, nawet gdy podejmuje je ta sama osoba.

Zapisz oba, zanim usługa wejdzie do produkcji, bo następną zmianę będzie łatwiej przemyśleć. Zapis jest krótki: jedna linia dla nazwy i jej strefy, jedna linia dla dopuszczonych źródeł i właściciela reguły.