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