Защо DHCP резервацията не е статичен IP за вашия VPN сървър

Резервацията съвпада с идентификатор на клиент, а не с машина, и никога не прави публичния ви IP статичен. Какво всъщност мести адреса на домашния VPN сървър.

Преместих домашна VPN кутия от Wi-Fi на Ethernet и „постоянният“ ѝ адрес се смени същата вечер. На рутера нищо не беше счупено. Резервацията съвпадаше с безжичния адаптер, а този адаптер вече не беше по пътя.

Има и втора половина на същото погрешно разбиране. Оправянето на LAN адреса не прави нищо за адреса, към който се свързват приятелите ви, и няма нищо общо с частния пул, който VPN дава на клиентите. Три адреса, три отделни режима на отказ и само един от тях е работа на резервацията.

Резервацията съвпада с клиент, а не с устройство

В DHCPv4 резервацията е вързана към хардуерния адрес на клиента; в DHCPv6 — към DUID, който клиентът се очаква да запази. Полето hostname е етикет за хора. Това, което рутерът всъщност сравнява, е идентификаторът, който пристига в заявката.

Четете записа като условие: когато този идентификатор поиска, дайте му този адрес. Подновяванията запазват същия наем, докато съвпадението се държи, а рестартът просто пита отново. Когато идентификаторът се смени, заявката пропуска резервацията и клиентът взема каквото динамичният пул предложи. Без грешка, без предупреждение, просто различен адрес.

OpenWrt показва формата ясно. Един блок config host в /etc/config/dhcp свързва име, MAC и адрес заедно, а документацията за статични наеми обяснява как този запис взаимодейства с пула. Други рутери крият същите три полета зад различни етикети.

Къде съвпадението тихо се пропуква

Смяната на хардуер е обичайният случай. Сменете мрежовата карта или преместете машината между Ethernet и Wi-Fi и адресът, който рутерът вижда, се мени с нея. Старата резервация остава в списъка и все още изглежда вярна.

Преинсталирането е вторият случай и удря най-силно по IPv6. Нова инсталация може да генерира нов DUID, докато старият наем за IPv4 е още валиден, така че адресът v4 оцелява известно време, а записът v6 спира да се прилага без видима редакция.

Третият е закован идентификатор на клиент. Няколко DHCP клиента позволяват да зададете низ за идентификатор, вместо да използвате MAC. Ако обновяване или пренаписване на конфигурацията изхвърли тази настройка, съвпадението изчезва, макар машината да не е мръднала.

Четвъртият е дублиране: остарял блок и нов блок за същия хост. Сървърът отговаря с това правило, което съвпадне, често с адреса от пула, който сте искали да избегнете. Изтрийте остарелия запис, вместо да добавяте втори.

Конфигурация от страната на хоста и какво струва

Задаването на адреса на хоста напълно премахва въпроса за съвпадението. Интерфейсът се вдига с този адрес независимо дали DHCP отговаря, и точно това искате от машина, която трябва да е достъпна след рестарт на рутера.

Цената е собственост. Сега вие осигурявате префикса, шлюза и резолверите и трябва сами да държите адреса извън динамичния пул. В Ubuntu с netplan това го носи /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]

Потребителите на NetworkManager стигат до същото състояние с nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, после nmcli con up "Wired connection 1". Приложете netplan с netplan try при първия опит, а не с netplan apply; сгрешен шлюз изкарва кутията от мрежата и ви оставя да търсите конзола.

Все пак дръжте съответстваща резервация. Тя не е излишна. Записът фиксира адреса от страната на рутера и спира DHCP сървъра да даде този адрес на гостуващо устройство, ако някой по-късно разшири пула.

Стабилният LAN адрес не е публична крайна точка

Насочете препращането на порта към 192.168.50.10 и правилото оцелява при всяка промяна от страната на LAN. То не ви дава стабилен интернет адрес. Публичният ви IP принадлежи на доставчика и може да се смени при повторно свързване или смяна на модема, за което служи динамичният DNS.

Зад NAT на ниво оператор изобщо няма публичен IPv4 за препращане и никаква резервация не го създава. Проверете страницата WAN на рутера преди всичко друго: ако адресът е в споделен диапазон, входящото препращане не може да работи, колкото и чиста да е резервацията.

Третият адрес е тунелният пул, често нещо като 10.8.0.0/24. Тези адреси съществуват само вътре в тунела и никога не се появяват в LAN. Бъркането им с LAN адреса на сървъра е начинът порт да се озове препратен към клиент, който е онлайн само докато е свързан.

Проверете пътя в реда, в който се чупи

Започнете от рутера. Сравнете записа в таблицата с наемите с целта на резервацията; ако сървърът е взел адрес от пула, идентификаторът е грешен и ip link show на хоста ви дава стойността за сравнение.

След това хостът. ip -4 addr show eth0 трябва да покаже очаквания адрес и префикс. Втори адрес на същия интерфейс обикновено значи, че DHCP още работи редом със статичната ви конфигурация.

След това препращането. Потвърдете, че дестинацията все още е равна на адреса, който току-що проверихте, и че нещо слуша с ss -lntp. Препращане към затворен порт отвън изглежда точно като счупено препращане.

Завършете отвън, на телефон с изключен Wi-Fi. Този един тест отделя „локалният адрес е грешен“ от „публичната достъпност е счупена“, двете проблеми, които тази настройка непрекъснато смесва.

Запишете трите адреса — LAN, публичен и тунелен пул — и отбележете коя система притежава всеки. Когато следващия месец връзка се развали, ще знаете кой да прегледате, вместо да сменяте и трите наведнъж.

Подобни статии