Dlaczego Dynamiczny DNS aktualizuje nieprawidłowy publiczny adres?

Dynamiczny DNS aktualizuje błędny adres, gdy aktualizator obserwuje inny interfejs lub wyjście internetowe niż te, do których muszą dotrzeć zdalni klienci.

W sieci domowej router może zgłaszać prywatny adres WAN za inną bramą, aktualizator po stronie serwera może widzieć wyjście VPN lub proxy, aktualizator IPv6 może nadpisać rekord IPv4, lub dwóch klientów może aktualizować tę samą nazwę hosta z różnych lokalizacji. Diagnoza zaczyna się od wybrania jednego źródła prawdy dla adresu publicznego, a następnie dokładnego zidentyfikowania, który aktualizator, rekord, rodzina adresów i metoda wykrywania wygenerowały błędną wartość.

Porównaj trzy adresy jednocześnie

Zapisz rekord DDNS, adres WAN routera oraz adres publiczny obserwowany przez zewnętrzną usługę IPv4 lub IPv6. Dodaj znaczniki czasu, aby prawidłowa, niedawna zmiana nie została pomylona z błędną aktualizacją.

Przypadek z społeczności TP-Link pokazał router zgłaszający adres z puli NAT dostawcy, podczas gdy zewnętrzny internet widział inny adres, co powodowało, że nazwa hosta DDNS wskazywała na błędny adres po stronie WAN.

Jeśli wszystkie trzy adresy się zgadzają, problemem prawdopodobnie jest buforowanie DNS lub zdalna dostępność, a nie wartość aktualizacji. Jeśli rekord DDNS zgadza się z routerem, ale nie z adresem zewnętrznym, zbadaj NAT upstream; jeśli nie zgadza się z żadnym, sprawdź konfigurację i logi aktualizatora.

Określ, jak aktualizator wykrywa adres

Ustal, czy klient DDNS odczytuje nazwany interfejs, pyta router, analizuje lokalną bramę, używa adresu źródłowego żądania aktualizacji, czy zapytuje zewnętrzną usługę „jaki jest mój IP”.

W dyskusji społeczności Zyxel pytano, dlaczego zapora za innym routerem NAT nie może automatycznie aktualizować prawdziwego adresu publicznego, gdy zna tylko prywatny adres WAN upstream.

Wybierz wykrywanie zewnętrzne, gdy aktualizator znajduje się za NAT i dostawca to obsługuje. Wybierz wykrywanie interfejsu tylko wtedy, gdy ten interfejs faktycznie posiada adres publiczny; w przeciwnym razie działający poprawnie aktualizator może z założenia publikować błędną wartość.

Sprawdź podwójny NAT i CGNAT

Sprawdź, czy adres WAN routera mieści się w zakresie prywatnym lub współdzielonym oraz czy inny modem lub brama ISP wykonuje pierwszy NAT. Dynamiczny DNS może publikować adres, ale nie może tworzyć przekierowania przychodzącego przez sieć upstream, której nie kontrolujesz.

Przypadek z niemieckiego forum wsparcia Synology zgłosił, że NAT dostawcy spowodował, iż DDNS wykrył adres, który nie był faktycznym publicznym punktem końcowym.

Jeśli kontrolujesz router upstream, ustaw router downstream w tryb mostu lub przekieruj wymagany ruch przez obie warstwy. Jeśli ISP używa CGNAT, poproś o adres publiczny lub użyj tunelu wychodzącego albo przekaźnika zamiast wielokrotnej zmiany klienta DDNS.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Oddziel aktualizacje IPv4 i IPv6

Sprawdź rekordy A i AAAA niezależnie i porównaj każdy z zewnętrznym testem dla tej samej rodziny adresów. Nie zakładaj, że jedna udana aktualizacja IPv6 potwierdza poprawność rekordu IPv4.

Klient skonfigurowany do monitorowania jednego interfejsu może publikować tymczasowy adres IPv6, adres z delegowanym prefiksem, który później się zmienia, lub adres IPv4 z wyjścia VPN. Zachowaj oddzielne zadania aktualizacji i rekordy dostawcy, gdy rodziny adresów mają różne cykle życia.

Wyłącz tylko podejrzaną aktualizację rodziny adresów i powtórz test. Jeśli zdalny dostęp zostanie przywrócony po usunięciu błędnego rekordu AAAA lub A, napraw tę ścieżkę przed przywróceniem DNS dual-stack.

Znajdź duplikaty klientów i błędne cele rekordów

Wypisz każdy router, NAS, kontener, skrypt, host w chmurze i urządzenie mobilne, które ma uprawnienia do aktualizacji nazwy hosta. Dwóch ważnych klientów w różnych lokalizacjach może wielokrotnie nadpisywać swoje zmiany.

Użytkownicy Dynu udokumentowali przypadki, gdy jeden klient aktualizacji spowodował, że wiele rekordów dzieliło jeden adres IP, ponieważ konto lub konfiguracja klienta celowały w więcej rekordów niż zamierzano.

Przydziel każdej lokalizacji i rodzinie adresów odrębną nazwę hosta, token i zadanie aktualizacji. Cofnij nieużywane uprawnienia i potwierdź, że log wskazuje dokładny rekord zmieniany przed zaufaniem komunikatowi o sukcesie.

Zweryfikuj rekord przez rzeczywistą zmianę adresu

Po poprawieniu metody wykrywania i właściciela aktualizatora wymuś bezpieczne ponowne połączenie WAN lub poczekaj na następną prawidłową zmianę adresu. Zapisz nowy adres zewnętrzny, log aktualizacji, autorytatywną odpowiedź DNS, odpowiedź resolvera rekurencyjnego oraz wynik połączenia zdalnego.

Przewodnik ZimaSpace wyjaśniający, dlaczego zdalny dostęp korzysta ze starego stanu IP, opisuje kolejny etap po tym, jak wartość DDNS staje się poprawna.

Problem jest rozwiązany tylko wtedy, gdy jeden zatwierdzony aktualizator publikuje poprawny adres IPv4 lub IPv6, żaden drugi klient go nie nadpisuje, autorytatywna odpowiedź zmienia się w oczekiwanym czasie, a zewnętrzny klient dociera do zamierzonej usługi domowej.