Чому резервування 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, публічну й пул тунелю — і позначте, яка система володіє кожною. Коли наступного місяця з’єднання обірветься, ви знатимете, що перевіряти, замість того щоб міняти всі три одразу.

Схожі статті