Co powoduje, że lokalny DNS zwraca właściwy adres IP, ale niewłaściwą usługę?

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.

Lokalny DNS może zwracać prawidłowy adres IP NAS-a, a mimo to otwierać niewłaściwą usługę, gdy współdzielony odwrotny serwer proxy kieruje nazwę hosta do innego hosta wirtualnego.

Na domowym serwerze ZimaSpace kilka aplikacji może współdzielić jeden adres LAN za pośrednictwem Nginx, Traefik, Caddy lub innego odwrotnego serwera proxy. DNS wybiera tylko docelowy adres IP. Przeglądarka nadal wysyła nazwę hosta przez SNI TLS i nagłówek HTTP Host, a proxy decyduje, który kontener otrzyma żądanie.

Sprawdź, czy odpowiedź Split-DNS jest rzeczywiście zamierzona

Porównaj rekord lokalny z publicznym i potwierdź, że obie nazwy hostów mają kończyć się na tym samym odwrotnym serwerze proxy.

Praktyczny poradnik dotyczący Split-DNS w homelabie na temat Split-DNS może zwracać prywatną ścieżkę pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Pozostaw nazwę hosta w przeglądarce bez zmian, zmieniając wyłącznie adres zwracany przez wewnętrzny DNS.

Potwierdź, że proxy kieruje ruchem na podstawie nazwy hosta

Wyślij żądania z oczekiwaną nazwą hosta i porównaj je z dostępem bezpośrednio przez adres IP do tego samego NAS-a.

Praktyczny poradnik dotyczący odwrotnego proxy w homelabie na temat nagłówek Host wybiera backend pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Jeśli bezpośrednie otwarcie adresu IP uruchamia domyślną aplikację, a otwarcie nazwy hosta — właściwą aplikację, problem nie leży w DNS; routing hostów wirtualnych działa zgodnie z założeniami.

Sprawdź, czy nagłówek Host jest przepisywany

Sprawdź nagłówki Host i forwarded-host w proxy oraz backendzie.

Praktyczne wyjaśnienie kwestii bezpieczeństwa i HTTP na temat zmiany nagłówka Host może zmienić routing pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Popraw wyłącznie warstwę, która przepisuje nazwę hosta. Nie dodawaj zduplikowanych rekordów DNS, aby skompensować błąd routingu HTTP.

Sprawdź SNI TLS przed routingiem HTTP

Wiele aplikacji HTTPS korzystających z jednego adresu IP nadal musi otrzymać nazwę hosta potrzebną do wybrania właściwego certyfikatu i hosta wirtualnego.

Praktyczny poradnik dotyczący SNI na temat SNI wybiera spośród witryn HTTPS na jednym adresie IP pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Porównaj nazwę w certyfikacie z trasą backendu. Certyfikat należący do innej aplikacji wskazuje, że wybór został dokonany nieprawidłowo, zanim żądanie dotarło do właściwej usługi.

Sprawdź domyślnego hosta wirtualnego

Jeśli żadna reguła nazwy hosta nie pasuje, wiele serwerów proxy zwraca domyślny serwer, który może należeć do innej aplikacji.

Praktyczny artykuł dotyczący rozwiązywania problemów z Nginx na temat niepasująca nazwa hosta może trafić do domyślnego serwera pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Utwórz jawne reguły dla nazw hostów i neutralną odpowiedź domyślną, zamiast pozwalać, aby jedna aplikacja stała się serwerem przechwytującym żądania dla każdej nieznanej domeny.

Oddziel routing DNS od routingu proxy

Traktuj DNS jako mechanizm wyboru adresu, a odwrotne proxy jako mechanizm wyboru aplikacji.

Przystępne wyjaśnienie różnicy między DNS a odwrotnym proxy na temat DNS i odwrotne proxy rozwiązują problemy na różnych warstwach routingu pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.

Wykonaj ponowny test z dokładną nazwą hosta aplikacji z klienta w sieci LAN. Prawidłowy wynik to oczekiwany certyfikat, trasa proxy i backend — bez zakładek z bezpośrednim adresem IP.

Powtórz test dokładnej ścieżki do serwera domowego

Po zmianie jednej zmiennej powtórz ten sam przepływ pracy z NAS-em lub usługą hostowaną samodzielnie, używając tego samego klienta, zamiast przełączać się na inny test, który może korzystać z innej ścieżki.

Powiązany poradnik ZimaSpace na temat powiązanej ścieżki sieciowej serwera domowego pomaga zachować powiązanie końcowej weryfikacji z tym samym środowiskiem usług hostowanych samodzielnie.

Naprawę można uznać za zakończoną dopiero wtedy, gdy pierwotny objaw pozostaje usunięty po ponownym połączeniu, restarcie usługi oraz drugim kontrolowanym transferze lub żądaniu.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.