Nieaktualny rekord DDNS czy zepsuty punkt końcowy VPN: jak je odróżnić

Z zewnątrz nieaktualna nazwa hosta i zepsuty VPN wyglądają identycznie. Klient rozwiązuje nazwę, nazwa wskazuje gdzieś, a połączenie kończy się przekroczeniem czasu lub zostaje odrzucone. Jedno to problem aktualizacji DNS, drugie to problem uwierzytelniania lub przekazywania, a różnica staje się oczywista dopiero wtedy, gdy porównasz publikowany adres z adresem, który twoja linia faktycznie ma.

Dwie awarie, które wyglądają tak samo

Pierwsza awaria polega na tym, że rekord nadal wymienia wczorajszy adres WAN. Druga — że rekord jest poprawny, a tunel odrzuca cię z własnych powodów. Obie dają ten sam komunikat na kliencie, i pojawia się pokusa, by zacząć regenerować certyfikaty.

Kolejność ma tu znaczenie. Sprawdzenie DNS zajmuje minutę i jest odwracalne. Regeneracja CA nie jest ani jednym, ani drugim.

Najpierw porównaj adresy

Zapytaj właściciela sieci, jaki adres ma teraz linia, a potem zapytaj DNS, co publikuje. dig +short vpn.example.com daje odpowiedź, którą otrzyma twój klient, a dig @1.1.1.1 vpn.example.com pokazuje, czy inny resolver widzi coś innego. Jeśli te dwa się nie zgadzają, patrzysz na zachowanie pamięci podręcznej, a nie na zepsuty aktualizator.

Odpowiedź rekurencyjna może pozostawać w tyle za aktualizacją o swój TTL, więc trzymaj rekord autorytatywny i to, co zapisał w pamięci podręcznej twój laptop, w osobnych pudełkach.

Czym naprawdę jest poświadczenie aktualizatora

Starsze urządzenia DDNS często uwierzytelniają się samym hasłem konta, dlatego zmiana tego hasła po cichu je psuje. Nadal ponawiają próby ze starą wartością i nie zgłaszają nic użytecznego. Wytyczne No-IP dotyczące hasła urządzenia dokumentują dokładnie ten problem zgodności na starszym sprzęcie, a rozsądną odpowiedzią jest poświadczenie aktualizacji o ograniczonym zakresie, a nie słabsze hasło konta.

Nowsze mechanizmy wydają osobny token lub klucz aktualizacji z własnym cyklem życia. To jest wartość, którą należy rotować do routera, i ta, którą należy zapisać w inwentarzu poświadczeń. To także nie jest wartość, którą warto wklejać do wątku czatu podczas debugowania.

Sprawdź niejawny stan aktualizatora: czas ostatniego sukcesu, kategorię odpowiedzi i nazwę hosta, którą uważa za swoją. Odrzucenie poświadczenia i awaria łączności wymagają różnych poprawek.

Czego nie zrobi poprawka DNS

Poprawienie rekordu nie tworzy osiągalności przychodzącej. Jeśli linia siedzi za NAT-em na poziomie operatora, żadna nazwa hosta nie sprawi, że połączenie przychodzące zadziała. Nie otwiera to też reguły firewalla ani nie przekazuje portu. I nigdy nie jest powodem do wyłączenia weryfikacji serwera na kliencie, co jest krokiem, który ludzie robią, gdy uznają, że problemem musi być certyfikat.

Odwrotnie, zmiana hasła VPN nie jest poprawką nieaktualnego DNS. Dodaje tylko drugą awarię do tego samego zgłoszenia.

Połącz się ponownie i udowodnij to od początku do końca

Gdy rekord autorytatywny jest poprawny, klient może nadal trzymać stare zapytanie. Użyj jego obsługiwanego ponownego połączenia lub odświeżenia punktu końcowego i daj mu chwilę zamiast walić w połącz. Następnie udowodnij ścieżkę w czterech krokach: rozwiąż nazwę, potwierdź adres, sprawdź, czy nasłuchujący jest osiągalny, i uwierzytelnij się. Cztery osobne wyniki, cztery osobne odpowiedzi.

Trzymaj aktualizator na liście kontrolnej rotacji obok konta VPN. Jeden zamierzony właściciel rekordu, ważne poświadczenie i obserwowalny sukces to to, co zapobiega kolejnej wersji tego zgłoszenia.