Ім’я кінцевої точки VPN проти імені приватного сервісу: двоє власників

Два імені можуть описувати ту саму філію й відповідати на цілком різні питання. vpn.branch.example повідомляє віддаленому партнеру, де знайти кінцеву точку VPN, і має резолвитися до появи будь-якого тунелю. inventory.branch.example повідомляє авторизованому користувачеві, де живе приватний застосунок, і має значення лише після підняття тунелю. Обслуговування одного не робить нічого для іншого.

Назвіть обидва записи, перш ніж налагоджувати будь-який із них

Запишіть обидва разом з їхніми власниками. Для кінцевої точки запишіть, хто оновлює публічну адресу і як VPN-клієнт оновлює свою відповідь. Для сервісу запишіть, кому належить приватна адреса, яка зона тримає запис і які резолвери мають за нього відповідати.

Цей короткий список запобігає найпоширенішому хибному діагнозу в цій галузі: перезапуску робочого тунелю філії, щоб виправити запис, який живе цілком усередині нього. Тунель — це транспорт для імені сервісу, а не його джерело істини.

Коли пропонується зміна, запитайте, якого з двох записів вона стосується. Якщо ніхто не може відповісти, зміна не готова до планування.

Кінцева точка має резолвитися до появи будь-якого тунелю

Припустімо, інтернет-з’єднання філії отримує нову публічну адресу. Оновлювач кінцевої точки публікує нову адресу, і віддалена реалізація VPN має вміти прочитати змінену відповідь. Який би резолвер не надавав цю відповідь, він має бути доступним без тунелю, інакше клієнт ганяється за іменем, яке може резолвити лише після підключення до того, чого не знаходить.

Цю залежність від початкового завантаження варто назвати прямо, бо її легко створити випадково, коли всі внутрішні резолвери стоять за VPN. Тримайте шлях до тунелю для пошуку кінцевої точки й підтверджуйте поведінку клієнта при перепідключенні, а не припускайте, що нова відповідь підхоплюється негайно.

Динамічний DNS теж має межі, які оновлення запису не може перетнути. Оновлення запису не відкриває порт брандмауера, не створює зіставлення NAT і не доводить особу партнера. Опублікована адреса із закритим портом дає клієнта, який коректно резолвить і все одно не може ні до чого підключитися.

Нарешті, робочий клієнт може продовжувати використовувати кешовану кінцеву точку до перепідключення. Розділіть у своїх нотатках публікацію, кеш і політику перепідключення, щоб застарілого партнера не вважали зламаним оновлювачем.

Ім’я сервісу описує, де живе застосунок

Тепер припустімо, що тунель залишається здоровим, але сервер інвентаризації переїжджає з 172.26.14.20 на 172.26.14.35. Публічний запис кінцевої точки не зачіпається, тоді як приватний запис сервісу має змінитися. Використання адреси, зарезервованої для цього сервісу, або статичного призначення робить це рідшим; авторизований шлях оновлення обробляє випадки, коли це навмисно.

Тут змішуються два механізми оновлення. RFC 2136 визначає протокол додавання й видалення записів DNS у зоні, тоді як комерційний постачальник динамічного DNS може надавати цілком інший HTTP API для іншої мети. Використання одного не означає, що інший існує у вашому середовищі. Перевірте, який механізм ваша зона насправді приймає, перш ніж писати під нього оновлювач.

Правильна приватна відповідь — це лише перша умова. Щоб віддалений виклик міг нею скористатися, клієнту потрібен резолвер, що несе приватну зону, політика, яка дозволяє запити до цього резолвера, і пересилання для адреси, що повертається. Ім’я, що резолвиться в адресу, недосяжну для клієнта, створює тайм-аут, який виглядає як збій сервера.

Перевірте обидва шляхи окремо

Перевірте кінцеву точку ззовні тунелю, а сервіс зсередини, і зберігайте результати як два незалежні факти:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Якщо перший запит не вдався, проблема в публічній публікації або в шляху резолвінгу до тунелю, і жодна внутрішня зміна не допоможе. Якщо другий повернув адресу, а третій не показав маршруту через тунель, шар DNS гаразд, а політика пересилання — ні.

Запускайте пару після кожної зміни адреси й зазначайте, який запис зсунувся. Передача, яка каже лише «DNS оновлено», залишає наступному інженеру здогадки, який із двох життєвих циклів справді відбувся.