Czy Split DNS może naprawić aplikację hostowaną samodzielnie, która działa tylko niepoprawnie w Twoim domu?

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.

Can Split DNS Fix a Self-Hosted App That Fails Only Inside Your Home? - Zima Store Online

Tak, split DNS może naprawić problem występujący tylko wewnątrz sieci, gdy publiczna nazwa hosta powinna rozwiązywać się na inny lokalny adres w domu.

Aplikacja hostowana samodzielnie może działać przez dane mobilne, ponieważ publiczny DNS wskazuje na adres WAN domu, podczas gdy urządzenia w sieci LAN zawodzą, ponieważ router nie potrafi przekierować tego połączenia z powrotem przez publiczną regułę NAT. Split DNS unika tej pętli, zwracając lokalnym klientom adres reverse-proxy lub aplikacji, ale działa tylko wtedy, gdy ta sama nazwa hosta, certyfikat, trasa proxy i podstawowy URL aplikacji pozostają ważne na obu ścieżkach.

Najpierw Udowodnij, Że Publiczna Nazwa Działa Z Zewnątrz

Przetestuj dokładny URL aplikacji z danych mobilnych lub innej zewnętrznej sieci. Potwierdź rozwiązywanie DNS, TLS, trasowanie reverse-proxy, logowanie, przekierowania oraz funkcjonowanie aplikacji, które obecnie zawodzą wewnątrz domu.

Tailscale opisuje split DNS jako sposób na dostarczanie klientom różnych odpowiedzi DNS w zależności od kontekstu, zamiast zmuszać użytkowników wewnętrznych i zewnętrznych do korzystania z jednej identycznej trasy.

Jeśli aplikacja również zawodzi z zewnątrz, split DNS nie jest pierwszym rozwiązaniem. Napraw publiczny DNS, tunel lub przekierowanie portów, trasowanie proxy, TLS lub konfigurację aplikacji, zanim utworzysz drugą odpowiedź, która może ukryć pierwotną usterkę.

Sprawdź, Czy Problem Wewnątrz Sieci To Hairpin NAT

Z klienta domowego zapytaj o publiczną nazwę hosta i zanotuj zwrócony adres. Jeśli rozwiązuje się na publiczne IP domu, sprawdź, czy router obsługuje NAT loopback lub hairpin NAT dla tej przekierowanej usługi.

Wątek rozwiązywania problemów na Level1Techs zaleca lokalne nadpisanie DNS, które wskazuje domenę na wewnętrzny adres serwera, gdy hairpin NAT jest zawodny.

Porównaj awarię nazwy publicznej z bezpośrednim dostępem do lokalnego adresu reverse-proxy. Jeśli bezpośredni lokalny dostęp dociera do zamierzonego proxy lub aplikacji, a publiczne IP zawodzi tylko wewnątrz, split DNS jest dobrym rozwiązaniem.

Wskaż Wewnętrzną Odpowiedź Na Ten Sam Logiczny Punkt Wejścia

Utwórz wewnętrzny rekord DNS dla istniejącej publicznej nazwy hosta, ale skieruj go na adres LAN reverse-proxy lub kontrolowanego lokalnego punktu wejścia. Unikaj wskazywania bezpośrednio na backend, gdy użytkownicy zewnętrzni normalnie przechodzą przez proxy.

Porównanie split DNS wyjaśnia, że lokalni klienci mogą rozwiązywać tę samą domenę na prywatny adres wewnętrzny, podczas gdy klienci zewnętrzni nadal otrzymują adres publiczny.

Utrzymanie obu ścieżek na tym samym proxy zachowuje trasowanie oparte na nazwie hosta, politykę dostępu, nagłówki i certyfikaty. Omijanie proxy przez klientów domowych może załadować stronę, ale zepsuć uwierzytelnianie, wywołania zwrotne, WebSockety lub kontrole bezpieczeństwa istniejące tylko na proxy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zweryfikuj, Czy Każdy Wymagany Klient Używa Wewnętrznego Resolvera

Sprawdź serwer DNS używany przez telefony, laptopy, telewizory, kontenery i klientów VPN, którzy powinni otrzymywać wewnętrzną odpowiedź. Bezpieczny DNS w przeglądarce, mobilny Private DNS, resolver VPN lub twardo ustawiony publiczny serwer DNS mogą omijać domowy resolver.

Wskazówki dotyczące self-hostingu o split DNS ostrzegają, że awarie często występują, gdy VPN lub klient nadal używa niewłaściwego kontekstu resolvera, mimo że są w sieci wewnętrznej.

Zapytaj bezpośrednio wewnętrzny serwer DNS, a następnie porównaj tę odpowiedź z normalnym zapytaniem klienta. Jeśli serwer zwraca lokalny adres, a klient nie, napraw dystrybucję DNS przez DHCP, szyfrowany DNS, politykę VPN lub nadpisania klienta, zanim ponownie edytujesz rekord.

Zachowaj Tę Samą Nazwę Hostu Dla TLS i Wywołań Zwrotnych Aplikacji

Uzyskaj dostęp do aplikacji przez jej normalną domenę po aktywacji wewnętrznego rekordu. Nie zastępuj jej zakładką do prywatnego IP, ponieważ certyfikaty HTTPS i trasy reverse-proxy są zwykle powiązane z nazwą hosta.

Wewnętrzna ścieżka musi również zachować publiczny podstawowy URL aplikacji, URI przekierowania OAuth, adres webhooka i przekazywane nagłówki. Split DNS zmienia adres docelowy, a nie nazwę hosta, której powinien używać przeglądarka lub dostawca.

Jeśli aplikacja przekierowuje z powrotem na publiczne IP, generuje wewnętrzną nazwę hosta lub odrzuca nagłówek hosta, napraw ustawienia proxy i URL aplikacji. Sam DNS nie naprawi usługi skonfigurowanej z niespójnymi tożsamościami.

Zachowaj Split DNS Tylko Gdy Obie Ścieżki Pozostają Przewidywalne

Testuj z domowego Wi-Fi, Wi-Fi gościa, VPN, danych mobilnych oraz na jednym urządzeniu używającym Private DNS. Potwierdź, że każdy klient otrzymuje zamierzony adres i dociera do tej samej tożsamości aplikacji.

Przewodnik ZimaSpace wyjaśniający, dlaczego prywatna chmura działa tylko w jednej sieci, przedstawia odwrotny objaw i pomaga zweryfikować, że dwa widoki DNS pozostają celowo różne.

Split DNS jest właściwym rozwiązaniem, gdy usuwa uszkodzoną publiczną pętlę, zachowując tę samą domenę, certyfikat TLS, trasę proxy i zachowanie aplikacji. Użyj hairpin NAT, gdy router obsługuje go niezawodnie, a utrzymanie dwóch widoków DNS wprowadza więcej ryzyka niż korzyści.