ddclient publikuje wyjście VPN: napraw źródło wykrywania

Twoja nazwa DNS wskazuje teraz na adres dostawcy VPN, a dziennik aktualizacji wygląda całkiem zdrowo. To połączenie jest normalne. Sonda wykrywania oparta na sieci pyta zewnętrzną usługę, jaki źródłowy adres widzi, a gdy żądanie wychodzi przez VPN z pełnym tunelem, odpowiedzią jest wyjście VPN, a nie domowy adres WAN. Aktualizator wykonał swoją pracę; praca była skierowana na błędną obserwację.

Potwierdź, do czego nazwa ma docierać

Publiczna nazwa dla przychodzącej usługi domowej potrzebuje adresu, przez który zatwierdzone połączenia przychodzące mogą dotrzeć do tej usługi. Publikowanie współdzielonego wyjścia dostawcy nie organizuje tam przekierowania przychodzącego i żadna konfiguracja DNS tego przekierowania nie tworzy. Zdecyduj o tym, zanim dotkniesz aktualizatora, bo to określa, który adres jest poprawny.

Prywatna nazwa dla adresu tunelu klienta VPN to inny problem z inną odpowiedzią: należy do prywatnego DNS i wcale nie potrzebuje publicznej usługi wykrywania. Mieszanie obu wymagań to sposób, w jaki działająca konfiguracja zaczyna publikować adres, o który nikt nie prosił.

Adresy interfejsów też wymagają interpretacji. Adres laptopa za domowym routerem to nie publiczny adres WAN, a nawet adres WAN routera może znajdować się za NAT operatora, gdzie jego publikacja nie da przychodzącej osiągalności.

Odtwórz wartość, zanim cokolwiek zmienisz

Obserwuj obie ścieżki osobno. Gdy tunel jest włączony, sonda zgłasza wyjście; gdy tunel jest wyłączony albo sonda jest przypięta do interfejsu fizycznego, zgłasza adres domowy: curl --interface eth0 https://ifconfig.me. Jeśli te dwie odpowiedzi się różnią, odtworzyłeś usterkę bez dotykania aktualizatora.

Następnie uruchom klienta w trybie, który sprawdza konfigurację bez wykonywania aktualizacji, na przykład ddclient -verbose -noexec, i odczytaj, którą metodę wykrywania wybrał. Szczegółowe wyjście podaje metodę i uzyskaną wartość, a to jest fakt, którego potrzebujesz przed jakąkolwiek edycją.

Skieruj wykrywanie na wybraną ścieżkę

Jeśli nazwa ma publikować domowy adres WAN, wykrywanie musi obserwować właśnie ten adres. Działają trzy opcje, w przybliżonej kolejności preferencji: pozwól routerowi publikować przez jego własny obsługiwany aktualizator; użyj wykrywania stanu routera w ddclient wobec strony, którą router naprawdę serwuje; albo zachowaj sondę internetową, ale przypnij ją do interfejsu fizycznego, aby wychodziła poza tunelem.

Dla ścieżki stanu routera nowsze wydania ddclient używają rodziny opcji usev4 i fwv4, z opcjonalnym wzorcem pomijania dla otaczającego tekstu strony. Sprawdź README dla zainstalowanej wersji, bo starsze wydania zapisują ten sam pomysł przez use i fw, a nazwa opcji skopiowana z niewłaściwego wydania zawodzi przy starcie.

Jeśli zachowasz wykrywanie sieciowe, pamiętaj, że trasowanie sondy i trasowanie wywołania API aktualizacji to osobne decyzje. Wywołanie aktualizacji dostarcza rekord; sonda decyduje, jaka wartość zostanie dostarczona.

Utrzymuj sekrety i wersje w porządku

Poświadczenia routera i tokeny dostawcy należą do chronionego pliku konfiguracyjnego, a nie do wiersza poleceń, który trafia do historii powłoki. Szczegółowe ślady mogą zawierać jedno i drugie, więc zredaguj je przed wklejeniem do zgłoszenia. Metoda wykrywania wymagająca zeskrobania uwierzytelnionej strony routera wymaga też utrzymania tych poświadczeń w działaniu przez aktualizacje firmware. Przechowuj je z taką samą troską jak token dostawcy.

Plik ddclient README dokumentuje podejścia do wykrywania i nazwy ich opcji. Nie mieszaj wyników IPv4 i IPv6 w jednym rekordzie i nie zakładaj, że opcja obecna w jednym wydaniu istnieje w innym.

Zweryfikuj wartość, potem osiągalność

Porównaj proponowany adres z zamierzonym punktem końcowym, zanim pozwolisz na aktualizację na żywo, następnie po jednej autoryzowanej aktualizacji sprawdź autorytatywny DNS i uwzględnij pamięci podręczne resolverów. Niski TTL skraca czekanie; nie czyni błędnej wartości poprawną.

Dopiero gdy rekord jest poprawny, przetestuj usługę przychodzącą z niezależnej sieci, przy już zatwierdzonym wymaganym firewallu i przekierowaniu. Poprawny rekord A nie dowodzi osiągalnej usługi, a statyczny leasing VPN może uprościć nazewnictwo prywatne, nie naprawiając publicznej nazwy hosta wskazującej na niewłaściwy WAN.