Вау, целый год прошёл с тех пор, как я здесь был в последний раз, а проблема всё та же. На этот раз UDM, но очень разочаровывает, что приходится идти на такие ухищрения из-за этой функции. Это ведь не такая уж и большая работа добавить её, ребята из Ubiquity… пожалуйста.

+1

Думаю, это лучшее место, чтобы добавить эту информацию, ведь именно сюда попадут те, кто ищет решение, и этот пост уже был поднят заново.

Это обходной путь для ситуации, когда в GUI нет поддержки «своих» DDNS-провайдеров.

Не могу говорить за все DDNS-сервисы, доступные через GUI, но я выбрал «dyndns», так как он вроде как де-факто «стандарт» (или, по крайней мере, самый распространённый по результатам моих поисков). Это реализовано через perl-скрипт под названием ddclient, который находится в /usr/sbin/. Подробнее о ddclient можно узнать на https://ddclient.net. Конфигурационный файл для интерфейса eth0 лежит в /etc/ddclient/ddclient_eth0.conf, а кэш, который создаётся при обновлении DDNS, — в /var/cache/ddclient/ddclient_eth0.cache. На USG этот скрипт проверяет публичный IP eth0 и сравнивает его с тем, что в кэше. Если IP изменился, он пытается подключиться к DDNS-серверу и обновить запись.

Мне пришлось методом проб и ошибок настроить работу с DDNS-провайдером, которого нет в выпадающем списке GUI. Помимо вышеуказанных путей к файлам, вот несколько полезных команд CLI, которые мне пригодились:

show dns dynamic status  
sudo ddclient -file /etc/ddclient/ddclient_eth0.conf -daemon=0 -debug -verbose -noquiet -force

Без параметра -force ddclient не будет пытаться обновить запись в течение как минимум 5 минут после неудачной попытки, поэтому тестировать настройки порой сложно — правильное сочетание может не сработать лишь потому, что вы попробовали слишком рано, а не потому, что указали что-то неверно.

Меня раздражает «мёртвая петля» у большинства бесплатных DDNS-сервисов, когда нужно каждые 30 дней отвечать на их письма, чтобы твоя запись не удалялась. Поэтому я долго искал сервис без такого требования и нашёл www.nsupdate.info. Это open-source проект для DDNS, совместимого с dyndns, и они поддерживают собственный сервер.

Вот «фишка» для nsupdate.info с ddclient (например, на USG): nsupdate.info просит отправлять GET-запросы на https://ipv4.nsupdate.info/nic/update. Казалось бы, это надо вписать в поле «Server» в GUI USG. Но нет. «/nic/update» — это путь по умолчанию для скрипта на dyndns-сервере, который обновляет вашу запись, и ddclient автоматически добавляет его к GET-запросу. Значит, уберите «/nic/update» и «https://», и пишите в поле «Server» только «ipv4.nsupdate.info». Выглядеть это будет примерно так:  


Имя пользователя и пароль здесь нужны только для аутентификации автоматических обновлений ddns — не для входа на nsupdate.info. Имя пользователя может совпадать, но пароль — точно нет. nsupdate.info называет этот пароль «секретом», а не паролем.

Примечание: у меня нет никакой связи с обсуждаемыми провайдерами, и использование любых DDNS-сервисов связано с определёнными рисками кибербезопасности. Я не рекламирую этот сервис, просто использую его для неважных целей.

Ещё один момент: версия ddclient, которая идёт с USG на момент написания этого текста, даёт вводящее в заблуждение сообщение DEBUG, показывая http:// вместо https:// (если запустить с -debug в CLI). Не волнуйтесь — на самом деле используется https. На странице аккаунта nsupdate.info в разделе «Result Messages» вашего личного кабинета будет показано «basic auth» (что может вас напугать), а в следующем сообщении будет «tls: True» — вот это уже успокоит вас.

Да, пожалуйста, добавьте возможность использовать свои DDNS-провайдеры. Было бы просто супер.

Да, пожалуйста. Это было бы оооочень здорово!

Пользовательский DDNS — это было бы просто здорово. У меня и у многих моих клиентов уже есть веб-сервер, на котором они тоже могут запускать DDNS. Часто именно поэтому я не выбираю USG.

+1

+1

Да, пожалуйста! Конкретно здесь требуется нативная поддержка RFC 2136. У меня есть сервер bind, который выполняет DDNS для моей динамической зоны, но для USG мне приходится платить провайдеру, поддерживающему DDNS, чтобы сделать то же самое.