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.