Jak rozwiązać problem ze zdalną aplikacją, która działa po adresie IP, ale nie po nazwie domenowej

Jeśli aplikacja działa po adresie IP, ale nie po domenie, serwer jest osiągalny, a problem zwykle dotyczy DNS, routingu opartego na nazwie hosta, TLS lub przekierowań.

Zdalny dostęp po adresie IP potwierdza, że jakaś ścieżka sieciowa dociera do serwera domowego, ale żądanie kierowane do domeny zawiera dodatkowe informacje identyfikacyjne z DNS, nazwy serwera TLS, nagłówka HTTP Host oraz skonfigurowanego publicznego adresu URL aplikacji. Najszybsza diagnoza polega na zachowaniu tego samego klienta, portu i serwera oraz sprawdzeniu po kolei każdej warstwy identyfikacji, zamiast jednoczesnej zmiany odwrotnego serwera proxy, certyfikatu i rekordów DNS.

Potwierdź, że test adresu IP dociera do właściwej usługi

Zapisz dokładny adres IP, port, protokół i odpowiedź, które działają zdalnie. Sprawdź, czy adres IP otwiera właściwą aplikację, domyślną stronę odwrotnego serwera proxy, panel logowania routera czy inną usługę korzystającą z tego samego publicznego adresu.

Przewodnik po konfiguracji odwrotnego serwera proxy w homelabie wyjaśnia, że proxy może obsługiwać kilka aplikacji pod jednym adresem, ponieważ przed wybraniem usługi nadrzędnej analizuje żądany nagłówek Host.

Jeśli adres IP prowadzi tylko do strony domyślnej, potwierdza to osiągalność proxy, ale nie dowodzi, że działa trasa do docelowej aplikacji. Zachowaj jeden rozpoznawalny element odpowiedzi, na przykład tytuł strony lub nagłówek, aby późniejsze testy wskazywały właściwy host wirtualny.

Porównaj publiczny DNS z działającym adresem IP

Odpytaj domenę za pośrednictwem autorytatywnego serwera nazw oraz co najmniej jednego zewnętrznego serwera rekurencyjnego. Zapisz każdą odpowiedź A i AAAA, wartość TTL oraz informację, czy rekord CNAME wskazuje inną nazwę hosta.

Materiały dotyczące self-hostingu wskazują, że zapisane w pamięci podręcznej odpowiedzi mogą pozostać aktywne do wygaśnięcia poprzedniej wartości TTL, dlatego niedawna zmiana może sprawić, że niektórzy klienci nadal korzystają z dawnego miejsca docelowego DNS po poprawieniu rekordu autorytatywnego.

Jeśli rekord A różni się od działającego adresu IP, popraw rekord lub aktualizator DDNS. Jeśli rekord A jest prawidłowy, ale AAAA wskazuje nieosiągalną ścieżkę IPv6, przetestuj osobno każdą rodzinę adresów i usuń lub napraw nieprawidłowy rekord.

Połącz się z działającym adresem IP, zachowując domenę

Użyj klienta, który może połączyć się ze znanym działającym adresem IP, wysyłając jednocześnie domenę jako nagłówek HTTP Host i nazwę serwera TLS. Zmienia to miejsce docelowe, ale zachowuje tożsamość oczekiwaną przez proxy i certyfikat.

Server Fault wyjaśnia, że odwrotny serwer proxy HTTP może używać nagłówka Host do wyboru trasy, podobnie jak hosty wirtualne oparte na nazwie.

Jeśli żądanie z zachowaną domeną działa, problemem jest warstwa DNS. Jeśli dociera do proxy, ale zwraca niewłaściwą witrynę lub błąd 404, sprawdź dopasowanie hosta wirtualnego i priorytet tras. Jeśli TLS kończy się błędem przed obsługą HTTP, sprawdź SNI i wybór certyfikatu.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź SNI TLS i tożsamość certyfikatu

Porównaj certyfikat zwracany dla domeny z certyfikatem zwracanym dla samego adresu IP. Zapisz nazwy podmiotu, wystawcę, datę wygaśnięcia oraz informację, czy proxy przedstawia domyślny certyfikat.

SNI przenosi nazwę hosta w komunikacie TLS ClientHello przed zaszyfrowanym żądaniem HTTP, umożliwiając proxy wybór bezpiecznego hosta wirtualnego. Żądanie kierowane wyłącznie do adresu IP może więc nie zawierać nazwy hosta używanej podczas wyboru TLS, nawet jeśli dociera do tego samego odbiornika.

Napraw certyfikat domeny i trasę SNI, zamiast oczekiwać certyfikatu dla prywatnego lub dynamicznego adresu IP. Jeśli przed serwerem znajduje się CDN lub proxy TCP, potwierdź, że przekazuje ono SNI dla właściwej nazwy hosta albo kończy jego obsługę.

Upewnij się, że DNS wewnętrzny i zewnętrzny nie kierują różnymi ścieżkami

Porównaj wynik dla domeny z sieci komórkowej, publicznego resolvera i domowej sieci LAN. Podzielony DNS może celowo zwracać prywatny adres proxy w domu, a publiczny adres podczas dostępu zdalnego, ale obie odpowiedzi muszą prowadzić do tej samej logicznej trasy hosta.

Dyskusja w serwisie Level1Techs dotycząca homelabu pokazuje, że lokalny dostęp przez odwrotny serwer proxy może wymagać własnego projektu DNS, gdy publiczny DNS i routing domowy wybierają różne ścieżki wewnętrzne i zewnętrzne.

Jeśli tylko jeden resolver zwraca nieprawidłowy adres, napraw ten widok DNS. Jeśli publiczny adres działa po IP, ale domena nie działa nigdzie, skup się na Host, SNI, certyfikacie i tożsamości aplikacji, a nie na podzielonym DNS.

Sprawdź kanoniczne adresy URL i przekierowania, zanim uznasz DNS za naprawiony

Przeanalizuj każde przekierowanie po dotarciu domeny do aplikacji. Odwrotny serwer proxy lub aplikacja może kierować klientów do wewnętrznej nazwy hosta, starej domeny, niewłaściwego schematu, prywatnego portu albo nieaktualnego adresu URL wywołania zwrotnego.

Artykuł ZimaSpace o tym, czy podzielony DNS może naprawić problem występujący wyłącznie wewnątrz sieci, omawia pokrewny przypadek, w którym nazwa hosta jest prawidłowa, ale trasa różni się w zależności od lokalizacji.

Problem można uznać za rozwiązany dopiero wtedy, gdy autorytatywny DNS zwraca właściwy adres, domena wybiera prawidłowy certyfikat i trasę proxy, przekierowania zachowują publiczną nazwę hosta, a pełny zdalny przepływ działa bez zastępowania domeny adresem IP.