Czy potrzebujesz dynamicznego DNS dla domowego serwera VPN?

Dynamiczny DNS naprawia nazwę, a nie drogę wejścia. Trzy kontrole decydują, czy nazwa hosta wystarczy dla domowego serwera VPN, czy droga wejścia jest zepsuta.

Większość awarii domowego VPN, o które mnie pytają, nie jest awariami DNS, a mimo to ludzie najpierw kupują abonament dynamicznego DNS. Zanim cokolwiek skonfigurujesz, zdecyduj, czy nazwa hosta jest tą częścią, która naprawdę jest zepsuta. Aktualizator przepisuje rekord, gdy adres przydzielony przez dostawcę się przesuwa; nie otworzy portu, nie przebije się przez NAT operatora ani nie sprawi, że działająca sesja WireGuard zauważy zmianę endpointu. Trzy warunki decydują, czy dynamiczny DNS to całe rozwiązanie, czy tylko jedna jego linia.

Warunek pierwszy: twój adres naprawdę się zmienia

Adresy domowe zmieniają się z błahych powodów: modem resynchronizuje się po zaniku prądu, dostawca przebalansowuje pulę, po długiej awarii przychodzi nowa dzierżawa. Na niektórych łączach zmieniają się też rzadko, a widziałem ten sam adres trwający rok; pakiety biznesowe często zawierają statyczny. Jeśli przez dwanaście miesięcy nic się nie zmieniło, jeden ręcznie edytowany rekord A to o jeden demon mniej do utrzymania.

Zmierz to, zamiast zgadywać. Odczytaj adres WAN na stronie statusu routera i porównaj go z tym, co widzi świat zewnętrzny. Uruchom to z maszyny w LAN:

curl -fsS https://api.ipify.org; echo

Jeśli obie wartości się różnią, coś tłumaczy przed twoim routerem i żadna aktualizacja nazwy hosta tego nie naprawi. Adres wewnątrz 100.64.0.0/10 to wspólny zakres dla NAT klasy operatora, i to zwykle dlatego poprawnie zaktualizowana nazwa nadal kończy się przekroczeniem czasu z zewnątrz.

Warunek drugi: klienci ponownie rozwiązują nazwę

Krótki TTL to część, którą ludzie pomijają. Resolwery rekurencyjne respektują TTL rekordu, ale stosy klientów cachują osobno, a tunel, który już stoi, niczego nie rozwiązuje ponownie. Podczas debugowania ustaw rekord na 60-300 sekund; to skraca okno, w którym podawana jest nieświeża odpowiedź, i nie przenosi połączonej sesji.

OpenVPN przy każdym ponownym połączeniu rozwiązuje na nowo linię remote vpn.example.net 1194 , a resolv-retry infinite każe mu ponawiać próby zamiast kończyć, gdy wyszukiwanie się nie powiedzie. Na serwerze float pozwala ustanowionej sesji podążać za peerem, którego adres źródłowy się zmienił. WireGuard jest bardziej dosłowny: wg-quick up przy zastosowaniu konfiguracji rozwiązuje Endpoint endpoint, a klient rozwiązuje go ponownie, gdy odbudowuje tunel, więc uścisk dłoni, który wciąż udaje się wobec starego adresu, udaje się aż do zatrzymania.

Ta różnica kształtuje plan. Jeśli klienci łączą się na żądanie, zmiana adresu kosztuje jedno ponowne połączenie. Jeśli trzymają sesję otwartą dniami, spodziewaj się, że tunel umrze przy następnym uścisku dłoni, i każ klientowi ponowić próbę, zamiast zakładać, że się utrzyma.

Warunek trzeci: droga wejścia jest wciąż otwarta

Dynamiczny DNS zmienia tylko to, gdzie wskazuje nazwa, i nic więcej. Przekierowanie portu na routerze, reguła zapory na hoście VPN i zgoda dostawcy na pakiety przychodzące muszą istnieć, zanim rekord zacznie mieć znaczenie. Patrz, na co celuje przekierowanie: jeśli jest przypięte do adresu WAN zamiast do interfejsu, zmiana adresu po cichu psuje przekierowanie i rekord zbiera winę.

Testuj z zewnątrz. Telefon na danych komórkowych z wyłączonym Wi-Fi to najtańszy uczciwy test; laptop w tej samej LAN już nie. Gdy nazwa rozwiązuje się na twój publiczny adres, a router nie ma pętli NAT, test od środka zawodzi, choć rekord jest całkowicie poprawny, i to wysyła większość ludzi edytować rekord, który nigdy nie był błędny.

Co uruchomić, gdy wszystkie trzy zachodzą

ddclient to najmniej zaskakujący aktualizator dla małego hosta. Minimalna konfiguracja publikuje adres, który widzi dostawca, co omija błąd podwójnego NAT:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Uruchamiaj go z timera systemd co kilka minut zamiast z pętli shell, i loguj odpowiedź dostawcy, zamiast zakładać sukces. Traktuj poświadczenie jak klucz, bo decyduje, dokąd trafia każdy klient: używaj ograniczonego tokena aktualizacji zamiast hasła konta, trzymaj plik w trybie 0600 i wysyłaj aktualizacje przez HTTPS.

Sprawdź, zanim się zobowiążesz

Jedno zapytanie mówi, co widzi reszta świata, i wypisuje TTL, którego trzeba doczekać po zmianie:

dig +noall +answer vpn.example.net @1.1.1.1

Porównaj ten adres z adresem WAN routera. Jeśli się zgadzają, nazwa robi swoje, a to, co nadal zawodzi, to osiągalność przychodząca, klucz albo klient, który nie rozwiązał ponownie. Jeśli się różnią, aktualizator publikuje zły interfejs, często dlatego, że działał na hoście VPN za routerem, a nie na samym routerze.

Miej wycofanie, które zajmuje minutę: zapisz ostatni działający adres i poprzedni TTL, żeby oba móc opublikować ręcznie, gdy dostawca ma złe popołudnie.

Gdy odpowiedź brzmi nie

Jeśli warunek pierwszy lub trzeci zawodzi, zmienia się decyzja, a nie konfiguracja. Za NAT operatora praktyczne opcje to poprosić dostawcę o publiczny adres, przenieść punkt wejścia na mały VPS ze stabilnym adresem, albo użyć nakładki, która trzyma własne spotkanie. Jeśli adres jest statyczny, pomiń aktualizator: jeden rekord A, jeden rekord AAAA, jeśli używasz IPv6, to samo przekierowanie portu.

Jeśli adres zmienia się, gdy klienci pozostają połączeni, uczciwa poprawka mieszka w kliencie: logika ponownego łączenia i interwał ponawiania, a nie szybszy aktualizator. Drugi dostawca tylko ukrywa interwał.

Zanim przejdziesz dalej, potwierdź cztery rzeczy po kolei:

  • Adres publikowany przez aktualizator zgadza się z adresem WAN routera.
  • TTL rekordu jest dość krótki, by zmiana pojawiła się w ciągu minut.
  • Przekierowanie portu jest przypisane do interfejsu, nie do stałego adresu.
  • Jeden prawdziwy klient połączył się ponownie i przepuścił ruch od ostatniej zmiany.

Jeśli wszystkie cztery zachodzą, zostaw konfigurację w spokoju; następna awaria to klucz albo reguła zapory, a nie problem z nazewnictwem. Jeśli któraś zawodzi, napraw ten wiersz, zanim dodasz kolejny ruchomy element. RFC 2136 opisuje sam mechanizm aktualizacji, jeśli chcesz zobaczyć, co demon kładzie na drucie.

Powiązane artykuły