Dlaczego rezerwacja DHCP nie jest statycznym IP dla twojego serwera VPN

Rezerwacja pasuje do identyfikatora klienta, a nie do maszyny, i nigdy nie czyni twojego publicznego IP statycznym. Co naprawdę przesuwa adres domowego serwera VPN.

Przeniosłem domowe pudełko VPN z Wi-Fi na Ethernet i jego „stały“ adres zmienił się jeszcze tego wieczoru. Na routerze nic nie było zepsute. Rezerwacja pasowała do karty bezprzewodowej, a tej karty nie było już na drodze.

To samo nieporozumienie ma drugą połowę. Naprawienie adresu LAN nic nie robi dla adresu, z którym łączą się twoi znajomi, i nie ma nic wspólnego z prywatną pulą, którą VPN daje klientom. Trzy adresy, trzy osobne tryby awarii, i tylko jeden z nich jest zadaniem rezerwacji.

Rezerwacja pasuje do klienta, a nie do urządzenia

W DHCPv4 rezerwacja jest powiązana z adresem sprzętowym klienta; w DHCPv6 z DUID, który klient powinien zachować. Pole hostname to etykieta dla ludzi. Router naprawdę porównuje identyfikator, który przychodzi w żądaniu.

Czytaj wpis jako warunek: kiedy ten identyfikator prosi, daj mu ten adres. Odnowienia utrzymują tę samą dzierżawę, dopóki dopasowanie się trzyma, a restart po prostu pyta ponownie. Gdy identyfikator się zmieni, żądanie mija rezerwację i klient bierze to, co oferuje pula dynamiczna. Bez błędu, bez ostrzeżenia, po prostu inny adres.

OpenWrt wyraźnie pokazuje kształt. Jeden blok config host w /etc/config/dhcp wiąże nazwę, MAC i adres razem, i dokumentacja dzierżaw statycznych wyjaśnia, jak ten wpis współdziała z pulą. Inne routery ukrywają te same trzy pola pod innymi etykietami.

Gdzie dopasowanie cicho się urywa

Wymiana sprzętu to zwykły przypadek. Wymień kartę sieciową albo przenieś maszynę między Ethernet a Wi-Fi, a adres, który widzi router, zmienia się razem z nią. Stara rezerwacja zostaje na liście i wciąż wygląda poprawnie.

Przeinstalowanie to drugi przypadek i najmocniej gryzie przy IPv6. Świeża instalacja może wygenerować nowy DUID, podczas gdy stara dzierżawa IPv4 jest jeszcze ważna, więc adres v4 przeżywa jakiś czas, a wpis v6 przestaje obowiązywać bez żadnej widocznej zmiany.

Trzeci to przypięty identyfikator klienta. Kilka klientów DHCP pozwala ustawić ciąg identyfikatora zamiast używać MAC. Jeśli aktualizacja albo przepisanie konfiguracji zgubi to ustawienie, dopasowanie znika, choć maszyna się nie ruszyła.

Czwarty to duplikacja: stary blok i nowy blok dla tego samego hosta. Serwer odpowiada tą regułą, która pasuje, często adresem z puli, którego chciałeś uniknąć. Usuń stary wpis, zamiast dodawać drugi.

Konfiguracja po stronie hosta i ile kosztuje

Ustawienie adresu na hoście usuwa pytanie o dopasowanie całkowicie. Interfejs wstaje z tym adresem niezależnie od tego, czy DHCP odpowiada, i tego właśnie chcesz od maszyny, która musi być osiągalna po restarcie routera.

Ceną jest własność. Teraz ty dostarczasz prefiks, bramę i resolvery, i sam musisz trzymać adres poza pulą dynamiczną. W Ubuntu z netplanem niesie go /etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Użytkownicy NetworkManagera dochodzą do tego samego stanu za pomocą nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, a potem nmcli con up "Wired connection 1". Zastosuj netplan z netplan try przy pierwszej próbie, a nie z netplan apply; źle wpisana brama zdejmuje pudełko z sieci i zostawia cię szukającego konsoli.

Mimo to zostaw pasującą rezerwację. Nie jest zbędna. Wpis zapisuje adres po stronie routera i nie pozwala serwerowi DHCP dać tego adresu urządzeniu gościa, jeśli ktoś później powiększy pulę.

Stabilny adres LAN nie jest publicznym punktem końcowym

Skieruj przekierowanie portu na 192.168.50.10, a reguła przetrwa każdą zmianę po stronie LAN. Stabilnego adresu internetowego ci nie da. Twój publiczny IP należy do dostawcy i może się przesunąć przy ponownym połączeniu albo wymianie modemu, do czego służy dynamiczny DNS.

Za NAT-em operatorskim nie ma w ogóle publicznego IPv4 do przekierowania i żadna rezerwacja go nie tworzy. Najpierw sprawdź stronę WAN routera: jeśli adres jest w zakresie współdzielonym, przekierowanie przychodzące nie może działać, choćby rezerwacja była najczystsza.

Trzeci adres to pula tunelu, często coś jak 10.8.0.0/24. Te adresy istnieją tylko wewnątrz tunelu i nigdy nie pojawiają się w sieci LAN. Mylenie ich z adresem LAN serwera to sposób, w jaki port trafia ostatecznie do klienta, który jest online tylko wtedy, gdy jest połączony.

Sprawdź ścieżkę w kolejności, w której się psuje

Zacznij od routera. Porównaj wpis w tabeli dzierżaw z celem rezerwacji; jeśli serwer wziął adres z puli, identyfikator jest zły, a ip link show na hoście daje ci wartość do porównania.

Potem host. ip -4 addr show eth0 powinien pokazać oczekiwany adres i prefiks. Drugi adres na tym samym interfejsie zwykle znaczy, że DHCP wciąż działa obok twojej konfiguracji statycznej.

Potem przekierowanie. Potwierdź, że cel nadal równa się adresowi, który właśnie sprawdziłeś, i że coś nasłuchuje z ss -lntp. Przekierowanie na zamknięty port wygląda z zewnątrz dokładnie jak zepsute przekierowanie.

Skończ z zewnątrz, na telefonie z wyłączonym Wi-Fi. Ten jeden test oddziela „adres lokalny jest zły“ od „publiczna osiągalność jest zepsuta“, dwa problemy, które ta konfiguracja ciągle miesza.

Zapisz trzy adresy, LAN, publiczny i pulę tunelu, i zaznacz, który system posiada każdy. Gdy w przyszłym miesiącu połączenie zawiedzie, będziesz wiedzieć, który sprawdzić, zamiast zmieniać wszystkie trzy naraz.

Powiązane artykuły