Документації split-tunnel потрібне правило DNS поруч із кожним маршрутом
Маршрут вирішує за адресою, резолвер вирішує за іменем. Задокументуйте обидва селектори для кожного потоку, кожен з одним тестом, інакше нотатка не витримає зміни DNS.
Нотатка про split-tunnel, яка каже «офісний трафік іде через VPN», задокументувала одне рішення й має на увазі ще три. На рівні пакетів таблиця маршрутизації вибирає інтерфейс за адресою призначення; на рівні імен резолвер вибирає сервер за запитом, і ці два вибори робляться незалежно. Тому правильно задокументований префікс усе ще може дати машину, яка розв'язує внутрішнє ім'я в публічну адресу, або не розв'язує нічого, поки маршрут виглядає бездоганно.
Два селектори, одна спроба з'єднання
Коли застосунок підключається до files.corp.example, до появи пакета відбуваються два пошуки. Резолвер вирішує, який сервер отримає запит, використовуючи домени пошуку, домени маршрутизації для кожного з'єднання або явне правило профілю. Потім таблиця маршрутизації вирішує, куди піде отримана адреса, використовуючи найдовший збіг префікса з призначенням.
Ніщо не пов'язує ці два рішення. Приватна зона може відповісти 10.20.4.11, поки таблиця маршрутизації надсилає 10.20.0.0/16 у тунель, і з'єднання працює. Переверніть будь-яке з них, і воно зламається так, що виглядатиме як інше: правильна політика DNS плюс відсутній маршрут дають розв'язане ім'я й тайм-аут, а правильний маршрут плюс публічний резолвер дають адресу, яка чисто маршрутизується не туди.
DNS із розділеним горизонтом робить це різкішим. Те саме ім'я може повернути приватну адресу від внутрішнього резолвера й публічну адресу від зверненого в інтернет, тому нотатка, що фіксує лише префікс, не може передбачити, яку адресу клієнт реально використає. Запишіть шлях резолвера, інакше адреса — здогад.
Що пропускає нотатка лише про маршрут
Запис лише про маршрут непридатний для найчастішої несправності split-tunnel: імен. Користувач повідомляє, що внутрішня мережа не завантажується, тунель піднятий і префікс присутній. Той, хто візьме заявку, не має запису, який резолвер мав відповісти, не має способу відрізнити неправильний суфікс пошуку від заблокованого сервера й не має базової лінії для порівняння.
Другий пропуск — список винятків. Дизайн split-tunnel визначається рівною мірою тим, що залишається поза тунелем, і тим, що до нього входить, а виключені діапазони зазвичай ламаються першими, бо конкретніший локальний маршрут або фільтр на боці клієнта може перекрити задум, не торкаючись профілю.
Третій — далекий бік тунелю. Клієнтський маршрут лише кладе пакет на дріт; шлюз усе ще має його пересилати й мати шлях назад. Посібник strongSwan щодо пересилання нагадує, що правила пересилання й брандмауера на шлюзі — частина функції, а не сантехніка, яку можна припускати.
Поля, які роблять нотатку виконуваною
Один рядок на потік, а потік — це призначення плюс ім'я плюс власник. Ось поля, які витримують зіткнення з реальним інцидентом:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Рядок «де це живе» — той, який люди пропускають. Префікс, який просуває сервер, маршрут, доданий профілем клієнта, і маршрут, набраний у оболонці, різняться тим, хто може їх змінити й чи переживуть вони перепідключення. Без цього поля наступний інженер не скаже, на який із трьох він дивиться.
Один тест на правило, а не один на тунель
Кожному рядку потрібні дві нешкідливі перевірки: одна вправляє маршрут, інша — ім'я. Для маршруту запросіть те, що має пройти крізь тунель, і підтвердьте шлях, а не доступність, наприклад tracert -d 10.20.4.11 у Windows або ip route get 10.20.4.11 у Linux. Для імені запитайте приватне ім'я й запишіть, який сервер відповів, використовуючи resolvectl query files.corp.example або dig files.corp.example проти резолвера, який називає нотатка.
Додайте й негативне очікування: що має статися, коли тунель опущений. Виключений застосунок на пристрої Android або iOS з увімкненим блокуванням без VPN може взагалі не мати зв'язку, а настільний клієнт може залишити той самий застосунок працювати, поки тунель перепідключається. Запис передбачуваної відповіді перетворює «VPN зламав мій застосунок» на перевірюване твердження.
Тримайте запис разом із конфігурацією
Зберігайте нотатку поруч із профілем, який вона описує, і версіонуйте її з цим профілем. Документ у вікі, який ніхто не оновлює, — це чутка; таблицю в тому самому репозиторії, що й просунуті маршрути та політика резолвера, можна переглянути в тій самій зміні.
Коли щось ламається, порівняйте застосований маршрут і чинний резолвер із записом, перш ніж додавати ще один виняток. Дві з трьох частих причин — старе правило простору імен і допоміжний процес поза політикою застосунку — виглядають точно як збій VPN і невидимі, якщо нотатка перелічує лише префікси.
Перш ніж назвати нотатку готовою, підтвердьте, що вона письмово відповідає на це: який префікс, для якої родини адрес; який приватний простір імен, яким резолвером обслуговується; які імена навмисно залишаються публічними; де налаштовано кожне правило й хто ним володіє; і одна команда, що доводить маршрут, та та, що доводить ім'я. Якщо чогось бракує, наступний інцидент діагностуватимуть з нуля.