Що змінює маршрутизація за політиками в трафіку VPN, а що ні

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

Правила вибирають таблицю, потім таблиця вибирає маршрут

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

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

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

Читайте набір правил як послідовність, а не як список

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

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Останні дві команди — ті, що перетворюють теорію на спостереження, бо вони запитують що ядро зробило б для цього джерела й цієї мітки. Якщо відповідь змінюється, коли змінюється мітка, діє правило на основі мітки, і будь-який тест, що пропускає мітку, перевіряє інший пакет. Зовнішнє з'єднання заслуговує на власне правило. Тунель, який маршрутизує весь трафік через себе, має виключити адресу кінцевої точки, до якої він підключається, інакше зашифровані пакети надсилаються назад у тунель, який вони щойно покинули. Більшість клієнтів вставляють це виключення автоматично, і набір правил, відредагований вручну, — це місце, де воно зникає.

Мітки та сокети: два способи, якими клієнти розділяють трафік

Одні клієнти позначають пакети в міжмережевому екрані й додають правило, що збігається з міткою. Інші використовують маршрутизацію на рівні сокета, задаючи маршрут на сокеті до того, як він підключиться. Перше видно в ip rule; друге ні, і воно не з'явиться в загальному пошуку.

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

Простежте власника, перш ніж додавати ще одне правило

Правила встановлює щось. Клієнт VPN, мережевий менеджер і написаний вручну скрипт можуть кожен додавати правила під час запуску, а логіка перепідключення може залишити попередній набір. Два застарілі правила з попереднього профілю продовжать спрямовувати трафік ще довго після видалення профілю.

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

Доведіть охоплення двома потоками, а не одним

Виправлення перевіряється лише потоком, який має бути зачеплений, і потоком, який не має. Виберіть призначення, яке політика спрямовує в тунель, і те, що має залишитися зовні, потім порівняйте пошуки й перехоплення для обох:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

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

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