Jak skonfigurować lokalne nadpisywanie DNS dla wielu odwrotnych serwerów proxy

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Utwórz jedno autorytatywne lokalne mapowanie dla każdej nazwy aplikacji i przypisz je do dokładnie jednego adresu odwrotnego proxy w każdej sieci klienckiej. Nie twórz konkurujących nadpisań wieloznacznych na wielu serwerach DNS.

Wiele proxy staje się źródłem nieporozumień, gdy ta sama domena publiczna jest używana wewnętrznie: laptop może pytać router, kontener może pytać lokalny resolver, a telefon może korzystać z szyfrowanego DNS. Rezultat może wyglądać jak błąd proxy lub certyfikatu, choć klient po prostu otrzymał nieprawidłowy adres. Przed dodaniem rekordów zinwentaryzuj nazwy, resolvery, nasłuchujące proxy i certyfikaty.

Przypisz nazwy do granic proxy

Wymień każdą nazwę FQDN aplikacji i proxy, które kończy jej połączenie TLS. Używaj konkretnych rekordów dla wyjątków, a wildcard rezerwuj wyłącznie dla domeny, której cała przestrzeń nazw należy do jednego proxy.

Unikaj przypisywania tej samej nazwie dwóch prywatnych rekordów A, chyba że oba proxy są celowo aktywne i skonfigurowane identycznie. DNS zwraca adresy, a nie stan usług, więc przypadkowe rekordy round-robin mogą kierować połowę klientów do proxy, któremu brakuje trasy lub certyfikatu.

Oddziel nazwy administracyjne od nazw przeznaczonych dla użytkowników. Jeśli nazwa hosta administratora nigdy nie może być rozwiązywana w sieci gościnnej, umieść ją w widoku lub resolverze dostępnym wyłącznie dla zaufanego VLAN-u, zamiast polegać na tym, że proxy ukryje ją później.

Umieść nadpisania w resolverze faktycznie używanym przez klientów

Utwórz lokalną strefę lub nadpisania hostów w usłudze DNS rozgłaszanej przez DHCP dla danej sieci. Każdą nazwę aplikacji kieruj na adres LAN należącego do niej proxy, a nie na kontener aplikacji i nie automatycznie na publiczny adres WAN.

Klienci i aplikacje mogą korzystać z różnych bibliotek resolvera i pamięci podręcznych, dlatego działanie DNS może pozostać niewidoczne. Sprawdź serwer wskazany w wynikach zapytania, zamiast zakładać, że użyto nadpisania na routerze.

Podczas testu wyłącz szyfrowany DNS po stronie klienta lub uwzględnij go w planie. Jeśli klient celowo omija lokalny DNS, nadpisania split-horizon nie mogą na niego wpływać; zamiast tego wybierz zarządzaną politykę DNS, publiczny rekord z routingiem hairpin lub resolver udostępniany przez VPN.

Dopasuj trasy proxy, TLS i adresy URL aplikacji

Na każdym proxy skonfiguruj wyłącznie przypisane do niego nazwy hostów i potwierdź, że certyfikat obejmuje te nazwy. Prawidłowa odpowiedź DNS, po której pojawia się nieprawidłowy certyfikat, dowodzi, że ruch dotarł do nasłuchującego proxy, ale nie do zamierzonego hosta wirtualnego.

Najpierw przetestuj trasę do serwera nadrzędnego z poziomu proxy, a następnie przetestuj publiczną nazwę hosta z poziomu klienta. Jeśli bezpośredni dostęp do serwera nadrzędnego działa, ale nazwa hosta zwraca domyślną witrynę, popraw dopasowanie hosta w proxy, zanim ponownie zmienisz DNS.

W przypadku aplikacji hostowanych pod ścieżką zachowaj zgodność trasy proxy z bazowym adresem URL aplikacji. Przewodnik ZimaSpace dotyczący bezpiecznego usuwania dostępu do Jellyfin pokazuje również, dlaczego DNS, trasy proxy, przekierowania i listy kontroli dostępu muszą być śledzone razem.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zweryfikuj każdą sieć i określ procedurę wycofania zmian

Wykonaj zapytanie o FQDN bezpośrednio do zamierzonego lokalnego resolvera, a następnie przez standardową ścieżkę systemu operacyjnego. Obie odpowiedzi powinny wskazywać to samo proxy dla danej sieci, a TTL powinien być zgodny z lokalną polityką.

Otwórz aplikację z zaufanej sieci LAN, gościnnego lub multimedialnego VLAN-u oraz VPN, jeśli ma to zastosowanie. Zapisz rozpoznany adres, nazwę certyfikatu, kod stanu HTTP i końcowe przekierowanie; obserwacje te pozwalają ustalić, czy problem dotyczy DNS, TLS, routingu proxy czy aplikacji.

Usuń nieaktualne duplikaty rekordów dopiero po pomyślnym przejściu testów przez wszystkich klientów. Wycofaj najnowsze nadpisanie, jeśli różni klienci naprzemiennie trafiają do różnych proxy, i wstrzymaj rozszerzanie wildcardu, dopóki logi resolvera nie potwierdzą, który serwer odpowiedział na każde nieudane żądanie.