Таблиця маршрутизації проти реального пошуку: куди йде трафік VPN

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

Таблиця — це набір кандидатів, а не рішення

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

Тож перший крок — запитати ядро, а не читати список. Команда пошуку відповідає для призначення, а з аргументом джерела — для тієї точної пари, яку використало б переспрямоване або прив'язане з'єднання:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

Пошук проходить спочатку правила, потім таблиці

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

У IPv6 свої правила й таблиці. Проєкту, який обслуговує обидві родини, потрібні обидва пошуки, а робоча відповідь IPv4 нічого не каже про шлях v6, якому клієнт із двома стеками може віддати перевагу.

Що встановлює клієнт VPN

Клієнти зазвичай не замінюють маршрут за замовчуванням, бо це зламало б власний зовнішній шлях тунелю. Вони встановлюють щось конкретніше, що виграє за довжиною префікса: пара половинних маршрутів за замовчуванням, які покривають 0.0.0.0/1 і 128.0.0.0/1, — класичний трюк, оскільки обидва є довшими префіксами, ніж 0.0.0.0/0, і разом покривають увесь простір. Інші встановлюють конкретні приватні префікси плюс правило політики, а деякі додають мітку, щоб захоплювався лише вибраний трафік.

Тому "VPN не змінив мій маршрут за замовчуванням" не є доказом збою. Перевірте, що він усе ж додав, і чи потрапляє відповідне призначення в ці префікси:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

Зовнішній маршрут теж має вижити

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

Чого не може сказати вивід маршрутизації

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

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

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