Правило домену VPN ламається, коли CDN змінює свої адреси

Ви копіюєте адресу з одного запиту у своє правило маршрутизації, сайт працює, а за тиждень уже ні. У правилі нічого не змінилося. Сервіс переїхав на іншу граничну адресу, клієнт розв'язав інше ім'я хоста, або сеанс перейшов на IPv6. Рішення перед вами — чи є правило за іменем або явний діапазон правильним інструментом для цього сервісу, і три умови це вирішують. Далі ім'я відокремлюється від адреси, бо стабільне лише одне з них.

Чому один запит — не інвентар

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

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

Третя прогалина — родина адрес. Правило лише для v4 нічого не каже про запис AAAA, якому клієнт може віддати перевагу.

Три умови, що вирішують правило домену або діапазони

По-перше, чи публікує сервіс стабільний набір префіксів, якими ви можете володіти й які можете документувати? Якщо так, явні діапазони чесні та дешеві. Якщо ні, правило домену — єдиний механізм, здатний слідувати за сервісом.

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

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

Перевіряйте сеанс, а не сторінку

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

Перелічіть, з чим сеанс насправді зв'язується, а не те, що показує сторінка:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

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

Що насправді покриває кожен механізм

Два механізми виглядають взаємозамінними на сторінці налаштувань і поводяться по-різному всередині.

Маршрут адреси в ядрі зіставляє префікси. Він не має уявлення, що таке ім'я хоста, тому не може слідувати за сервісом, який змінює адреси. Правило домену розв'язує імена й маршрутизує результат; воно слідує за сервісом, але залежить від резолвера, поведінки оновлення та обробки піддоменів клієнтом, тому правило, що слідує за іменами, треба перевіряти з тим резолвером, який клієнт справді використовує.

Жодне не є надмножиною іншого, тому їх змішування без нотатки згодом створює плутанину.

Перепроверте після зміни сервісу

Після оновлення клієнта або зміни сервісу запустіть той самий тест сеансу ще раз. Список адрес, який раніше працював, — це свідчення про той період, а не постійний інвентар інфраструктури сервісу.

Запишіть, який механізм покриває яке ім'я хоста, і дату останньої перевірки.

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