VPN-маршрутизація за доменами проти IP-маршрутів: що підходить?
Ім'я хоста в полі розділеного тунелю — не маршрут. Порівняйте доменні правила та явні префікси щодо оновлення, охоплення піддоменів і того, що відбувається, коли змінюється DNS.
IP-маршрут відповідає префіксу адреси, і ядро застосовує його, не ставлячи додаткових питань. Правило VPN на основі домену відповідає імені, а це означає, що щось у стеку має вирішити, які адреси це ім'я означає зараз, і підтримувати це рішення актуальним. Це різні механізми з різними режимами відмови, і постачальники використовують те саме слово для обох. Порівнювати їх у списках функцій — оминати суть; порівнюйте їх за тим, що відбувається, коли відповідь змінюється.
Корисний поділ — між правилом, яке розв'язує, і правилом, яке не розв'язує.
З чим насправді збігається кожне правило
Правило префікса збігається з адресами призначення в таблиці маршрутизації. Нічого не розв'язується, нічого не спливає, і збіг точний для кожного пакета. Правило домену збігається із запитом застосунку на ім'я, яке RFC 1034 визначає як дерево міток, а не як адресу. Деякі продукти розв'язують ім'я один раз і встановлюють отримані адреси як маршрути, що робить правило IP-правилом із прикріпленим таймером оновлення.
Перш ніж налагоджувати, з'ясуйте, яке з двох у вас, бо відмова виглядає зовсім по-різному в кожному випадку.
Де правило домену живе в стеку
Якщо продукт реалізує доменні правила через локальний проксі, трафік має дістатися до цього проксі, а застосунки, що ігнорують системний проксі, повністю обходять правило. Якщо він реалізує їх розв'язанням імен і додаванням маршрутів, адреси свіжі лише до останнього оновлення. Якщо він чіпляється до розв'язувача, поведінка DNS стає частиною політики маршрутизації, і резервний розв'язувач може тихо це скасувати.
Читайте модель постачальника, а не ярлик налаштування. Два клієнти з полем під назвою Split Tunnel можуть робити три різні речі.
Порівняйте, що ламається
Три речі ламаються по-різному. Зміна адрес: ім'я хоста CDN може розв'язатися в інший набір адрес за кілька хвилин, тож скопійований список швидко старіє. Охоплення піддоменів: правило для example.com може покривати api.example.com, а може й ні, і документація зазвичай прямо каже, який випадок. Збій розв'язання: коли розв'язувач відмовляє, клієнт, що розв'язує, може перейти до тунелювання трафіку або до його прямої відправки.
Лише друге — питання конфігурації. Решта два — питання проєктування про те, скільки продукт готовий вгадувати.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
Коли префікс — краща відповідь
Для стабільної приватної підмережі явний префікс зрозуміліший, швидший і легший для аудиту. Він також переживає збій розв'язувача, бо нічого не потрібно розв'язувати. Вдавайтеся до правила домену, коли сервіс розміщено на хостингу, коли адреси обертаються або коли ви справді не можете перелічити набір призначень. Не вдавайтеся до нього лише тому, що ім'я хоста — це те, що ви випадково знаєте.
Угаданий статичний список — найгірше з обох: він виглядає доглянутим і тихо пропускає трафік того дня, коли провайдер додає хост.
Перевірте свіжим запитом
Протестуйте холодним запитом після звичайного перепідключення, бо сторінка з кешу може ніколи не торкнутися правила. Розв'яжіть ім'я, потім перевірте, куди насправді пішло з'єднання. dig +short app.example.com дає поточний набір адрес, а список з'єднань клієнта каже, який інтерфейс ніс потік.
Повторіть після інтервалу оновлення, який документує продукт. Якщо набір адрес зсувається, а правило за ним не йде, ви знайшли справжню поведінку.
Тримайте політику розв'язувача окремо. Правилу домену потрібні коректні дані про імена, але саме по собі воно не вирішує, який розв'язувач відповідає на запит.