Чи потрібен вам динамічний 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 описує сам механізм оновлення, якщо ви хочете побачити, що демон кладе на дріт.

Схожі статті