Нужен ли динамический DNS для домашнего VPN-сервера?

Динамический DNS исправляет имя, а не путь внутрь. Три проверки решают, достаточно ли имени хоста для домашнего VPN-сервера или маршрут внутрь сломан.

Большинство отказов домашнего VPN, о которых меня спрашивают, — не отказы DNS, и всё же люди сначала покупают подписку на динамический DNS. Прежде чем что-то настраивать, решите, имя хоста ли это та часть, которая действительно сломана. Обновлятор перезаписывает запись, когда адрес, выданный провайдером, смещается; он не может открыть порт, пробиться через NAT оператора или заставить живую сессию WireGuard заметить, что её конечная точка изменилась. Три условия решают, является ли динамический DNS всем решением или только одной его строкой.

Условие первое: ваш адрес действительно меняется

Домашние адреса меняются по обычным причинам: модем пересинхронизируется после отключения электричества, провайдер перераспределяет пул, после долгого простоя приходит новая аренда. На некоторых линиях они меняются и редко, и я видел, как один и тот же адрес держался год; в бизнес-тарифах часто есть статический. Если за двенадцать месяцев ничего не изменилось, одна запись A, которую вы правите вручную, — это на один демон меньше, который нужно держать живым.

Измерьте, а не угадывайте. Прочитайте адрес WAN на странице состояния роутера и сравните с тем, что видит внешний мир. Запустите это с машины в LAN:

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

Если значения различаются, что-то транслирует перед вашим роутером, и никакое обновление имени хоста это не исправит. Адрес внутри 100.64.0.0/10 — это общий диапазон для NAT операторского уровня, и это обычная причина, по которой правильно обновлённое имя всё равно упирается в тайм-аут снаружи.

Условие второе: клиенты заново разрешают имя

Короткий TTL — это та часть, которую пропускают. Рекурсивные резолверы соблюдают TTL записи, но клиентские стеки кешируют отдельно, а уже поднятый туннель ничего заново не разрешает. Пока отлаживаете, поставьте запись на 60-300 секунд; это сокращает окно, в котором отдаётся устаревший ответ, и не переносит подключённую сессию.

OpenVPN при каждом переподключении заново разрешает строку remote vpn.example.net 1194 , а resolv-retry infinite заставляет его повторять попытки вместо выхода, когда поиск не удался. На сервере float позволяет установленной сессии следовать за партнёром, чей адрес источника изменился. WireGuard прямолинейнее: wg-quick up при применении конфигурации разрешает Endpoint конечную точку, а клиент разрешает её заново, когда перестраивает туннель, поэтому рукопожатие, которое всё ещё проходит по старому адресу, проходит, пока не остановится.

Эта разница формирует план. Если клиенты подключаются по требованию, смена адреса стоит одного переподключения. Если они держат сессию открытой днями, ждите, что туннель умрёт на следующем рукопожатии, и заставьте клиента повторять попытку, а не предполагать, что он остаётся.

Условие третье: входящий путь по-прежнему открыт

Динамический DNS меняет только то, куда указывает имя, и ничего больше. Проброс порта на роутере, правило брандмауэра на хосте VPN и разрешение провайдера на входящие пакеты должны существовать до того, как запись начнёт иметь значение. Смотрите, на что нацелен проброс: если он привязан к адресу WAN, а не к интерфейсу, смена адреса тихо ломает проброс, и вина ложится на запись.

Проверяйте снаружи. Телефон на мобильных данных с выключенным Wi-Fi — самый дешёвый честный тест; ноутбук в той же LAN — нет. Когда имя разрешается в ваш публичный адрес, а у роутера нет петли NAT, внутренний тест проваливается, хотя запись совершенно верна, и это отправляет большинство править запись, которая никогда не была ошибочной.

Что запускать, когда все три выполняются

ddclient — наименее удивляющий обновлятор для небольшого хоста. Минимальная конфигурация публикует адрес, который видит провайдер, и это обходит ошибку двойного 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

Запускайте его из таймера systemd раз в несколько минут, а не из цикла shell, и записывайте ответ провайдера вместо предположения об успехе. Относитесь к учётным данным как к ключу, потому что они решают, куда отправляется каждый клиент: используйте ограниченный токен обновления вместо пароля учётной записи, держите файл в режиме 0600 и отправляйте обновления по HTTPS.

Проверьте, прежде чем брать обязательство

Один запрос говорит, что видит остальной мир, и печатает TTL, который нужно переждать после изменения:

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

Сравните этот адрес с адресом WAN роутера. Если они совпадают, имя делает свою работу, а то, что всё ещё не работает, — это входящая доступность, ключ или клиент, который не переразрешил. Если различаются, обновлятор публикует не тот интерфейс, часто потому что работал на хосте VPN за роутером, а не на самом роутере.

Держите откат, который занимает минуту: запишите последний работавший адрес и предыдущий TTL, чтобы оба можно было опубликовать вручную, пока у провайдера плохой день.

Когда ответ — нет

Если условие первое или третье не выполняется, меняется решение, а не конфигурация. За NAT оператора практические варианты — попросить у провайдера публичный адрес, перенести точку входа на небольшой VPS со стабильным адресом, или использовать наложение, которое держит собственную встречу. Если адрес статический, пропустите обновлятор: одна запись A, одна запись AAAA, если вы используете IPv6, тот же проброс порта.

Если адрес меняется, пока клиенты остаются подключёнными, честное исправление живёт в клиенте: логика переподключения и интервал повтора, а не более быстрый обновлятор. Второй провайдер только скрывает интервал.

Прежде чем двигаться дальше, подтвердите четыре вещи по порядку:

  • Адрес, который публикует обновлятор, совпадает с адресом WAN роутера.
  • TTL записи достаточно короткий, чтобы изменение проявилось за минуты.
  • Проброс порта привязан к интерфейсу, а не к фиксированному адресу.
  • Один реальный клиент переподключился и пропустил трафик с последнего изменения.

Если все четыре выполняются, оставьте настройку в покое; следующий отказ — это ключ или правило брандмауэра, а не проблема именования. Если какое-то не выполняется, исправьте эту строку, прежде чем добавлять ещё одну движущуюся часть. RFC 2136 описывает сам механизм обновления, если вы хотите увидеть, что демон кладёт на провод.

Похожие статьи