Jak skonfigurować DNS split-horizon do wewnętrznego i zdalnego dostępu do aplikacji

Używaj wszędzie tej samej nazwy hosta aplikacji, ale zaufanym klientom wewnętrznym i klientom VPN zwracaj prywatny adres proxy, a klientom zewnętrznym publiczny punkt końcowy lub punkt końcowy tunelu. Zachowaj identyczną nazwę TLS na obu ścieżkach.

DNS z rozdzielonym widokiem jest przydatny, gdy hairpin NAT jest niedostępny lub gdy ruch lokalny powinien pozostać w sieci LAN. Zawodzi, gdy klienci omijają zamierzony resolver, utrzymują nieaktualne odpowiedzi lub gdy wewnętrzny punkt końcowy udostępnia inny certyfikat. Zdefiniuj oba widoki, obniż wartości TTL przed migracją i testuj rozpoznawanie nazw niezależnie od HTTPS.

Zdefiniuj widok wewnętrzny i zewnętrzny

Wybierz jedną nazwę FQDN dla każdej aplikacji. W publicznym DNS skieruj ją do zewnętrznie dostępnego proxy, tunelu lub bramy, a w wewnętrznym DNS nadpisz ją prywatnym adresem lokalnego proxy.

Nie twórz osobnej nazwy hosta dostępnej tylko wewnętrznie wyłącznie po to, aby uniknąć pracy z certyfikatem, chyba że aplikacja obsługuje dwa kanoniczne adresy URL. Jedna nazwa zapewnia spójność zakładek, wywołań zwrotnych i klientów mobilnych podczas zmiany lokalizacji.

Udokumentuj, które podsieci otrzymują widok wewnętrzny. Sieci gościnne mogą potrzebować odpowiedzi publicznej, podczas gdy zaufani klienci sieci LAN i klienci zdalnego dostępu VPN otrzymują odpowiedź prywatną za pośrednictwem przypisanego resolvera.

Zapewnij deterministyczny wybór resolvera

Rozgłaszaj wewnętrzny resolver przez DHCP oraz za pośrednictwem profilu VPN. Najpierw odpytaj go jawnie, a następnie wykonaj zapytanie za pośrednictwem systemu operacyjnego, aby wykryć lokalną pamięć podręczną lub ominięcie szyfrowanego DNS.

Pamięci podręczne resolverów i różne biblioteki DNS mogą powodować zaskakujące wyniki; ten katalog częstych trybów awarii DNS wyjaśnia, dlaczego zmiana na serwerze autorytatywnym może nie pojawić się od razu u klienta.

Opróżniaj tylko odpowiednie pamięci podręczne po potwierdzeniu, że rekord jest poprawny u źródła. Jeśli zarządzana przeglądarka korzysta z własnego szyfrowanego resolvera, zastosuj zatwierdzoną zasadę lub zaakceptuj ścieżkę publiczną zamiast wielokrotnie edytować lokalną strefę.

Dopasuj działanie proxy, certyfikatu i aplikacji

Oba punkty końcowe muszą przedstawiać certyfikat ważny dla wspólnej nazwy FQDN i kierować ten host do tej samej tożsamości aplikacji. Ostrzeżenie dotyczące certyfikatu oznacza, że DNS dotarł do punktu końcowego, ale punkt końcowy nie jest skonfigurowany dla żądanej nazwy.

Zweryfikuj przekierowania, WebSockets, adresy URL wywołań zwrotnych oraz zewnętrzny adres URL aplikacji. Lokalne proxy, które przekierowuje na adres IP lub inną nazwę hosta, niweczy projekt oparty na jednej nazwie.

Jeśli aplikacja korzysta z podścieżki, zachowaj synchronizację jej bazowego adresu URL i trasy proxy. Lista kontrolna ZimaSpace dotycząca aktualizacji kontenerów Jellyfin pomaga zachować ustawienia proxy, montowania i adresów URL przed wprowadzeniem zmiany.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przetestuj przejścia między dostępem wewnętrznym a zdalnym

W sieci Wi-Fi zapisz serwer DNS, zwrócony adres, certyfikat i wynik działania aplikacji. Powtórz test przez sieć komórkową przy wyłączonym Wi-Fi; adres powinien się zmienić, a nazwa hosta i tożsamość certyfikatu powinny pozostać takie same.

Połącz się z VPN z sieci zewnętrznej i powtórz test. Jeśli VPN powinien korzystać ze ścieżki prywatnej, ale otrzymuje odpowiedź publiczną, napraw przypisanie DNS lub routing, zanim zmienisz ustawienia aplikacji.

Na koniec przenieś klienta między sieciami i odczekaj czas TTL. Zakończ testy, gdy wszystkie trzy ścieżki będą deterministyczne; wycofaj wewnętrzne nadpisanie, jeśli klienci trafiają do niewłaściwego proxy lub nie możesz kontrolować używanego przez nich resolvera.