ddclient публикует выход VPN: исправьте источник обнаружения

Ваше DNS-имя теперь разрешается в адрес провайдера VPN, и журнал обновлений выглядит совершенно здоровым. Такое сочетание нормально. Веб-зонд обнаружения спрашивает внешний сервис, какой источник тот видит, и когда запрос уходит через VPN с полным туннелем, ответом становится выход VPN, а не ваш домашний адрес WAN. Обновлятор сделал свою работу; работа была направлена на неверное наблюдение.

Подтвердите, чего должно достигать имя

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

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

Адреса интерфейсов тоже требуют истолкования. Адрес ноутбука за домашним маршрутизатором — не публичный адрес WAN, и даже адрес WAN маршрутизатора может находиться за NAT оператора, где его публикация не даёт входящей доступности.

Воспроизведите значение, прежде чем что-либо менять

Наблюдайте оба пути раздельно. При поднятом туннеле зонд сообщает выход; при опущенном туннеле или при зонде, привязанном к физическому интерфейсу, он сообщает домашний адрес: curl --interface eth0 https://ifconfig.me. Если эти два ответа различаются, вы воспроизвели неисправность, не трогая обновлятор.

Затем запустите клиент в режиме, который проверяет конфигурацию без выполнения обновления, например ddclient -verbose -noexec, и прочитайте, какой метод обнаружения он выбрал. Подробный вывод называет метод и полученное значение, и это тот факт, который нужен вам до любого редактирования.

Направьте обнаружение на выбранный путь

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

Для пути со статусом маршрутизатора новые выпуски ddclient используют семейство опций usev4 и fwv4 с необязательным шаблоном пропуска для окружающего текста страницы. Сверьтесь с README установленной версии, потому что старые выпуски пишут ту же мысль через use и fw, а имя опции, скопированное из неправильного выпуска, приводит к сбою при запуске.

Если вы оставляете веб-обнаружение, помните, что маршрутизация зонда и маршрутизация вызова API обновления — разные решения. Вызов обновления доставляет запись; зонд определяет, какое значение будет доставлено.

Держите секреты и версии в порядке

Учётные данные маршрутизатора и токены провайдера должны находиться в защищённом файле конфигурации, а не в командной строке, которая попадает в историю shell. Подробные трассировки могут содержать и то и другое, поэтому вычищайте их перед вставкой в тикет. Метод обнаружения, требующий извлечения аутентифицированной страницы маршрутизатора, также требует, чтобы эти учётные данные работали после обновлений прошивки. Храните их с той же заботой, что и токен провайдера.

Файл ddclient README документирует подходы к обнаружению и имена их опций. Не смешивайте результаты IPv4 и IPv6 в одной записи и не предполагайте, что опция из одного выпуска существует в другом.

Проверьте значение, затем доступность

Сравните предложенный адрес с намеченной конечной точкой, прежде чем разрешать живое обновление, затем после одного разрешённого обновления проверьте авторитетный DNS и учтите кеши резолверов. Низкий TTL сокращает ожидание; он не делает неверное значение верным.

Только когда запись верна, следует проверять входящий сервис из независимой сети, когда требуемые межсетевой экран и переадресация уже одобрены. Верная запись A не доказывает доступность сервиса, а статическая аренда VPN может упростить частное именование, не исправляя публичное имя хоста, указывающее на неверный WAN.