Коли маршрути розділеного тунелю перекриваються: який префікс перемагає

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

1. Запишіть призначення та джерело

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

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

2. Запитайте в ядра, який маршрут воно обрало

Не читайте таблицю маршрутів і не робіть висновок із неї. Поставте те саме питання, яке ставить стек, з тією самою адресою джерела: ip route get 10.20.4.10 from 10.8.0.2 у Linux або Find-NetRoute -RemoteIPAddress 10.20.4.10 у PowerShell. Вивід називає маршрут, який справді буде використано, і це часто не той, якого ви очікували, читаючи таблицю.

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

3. Перевірте, чи не перенаправило пошук правило політики

Перш ніж таблиця маршрутів буде переглянута, ядро проходить свої правила політики. Правило може надіслати трафік від заданого джерела, користувача або позначки міжмережевого екрана до зовсім іншої таблиці, тому переможний префікс у головній таблиці може ніколи не переглядатися для цього потоку. ip rule show перелічує їх у порядку оцінювання, а ip route show table 100 показує, що насправді містить вибрана таблиця.

Тут чатують дві пастки. Правило, яке вказує на порожню таблицю, створює пошук, що провалюється до наступного правила, тому правило ніби нічого не робить. Друга — сам номер пріоритету: правила читаються за зростанням, а вбудовані значення — 0 local, 32766 main і 32767 default. Правило з номером менше 32767 переглядається перед правилом за замовчуванням, яке перехоплює все. Правило з номером більше 32767 стоїть за ним і досягається лише тоді, коли жодна попередня таблиця не відповідає, чому перешкоджає звичайний маршрут за замовчуванням у main, тому на практиці воно ніколи не досягається і мовчки нічого не робить, виглядаючи встановленим. Якщо клієнт записав правило й маршрут, перевірте обидва і перевірте їх знову після повторного підключення, бо переписаний профіль може додати друге правило з іншим пріоритетом.

4. Відокремте рівність маршрутів від дубльованого плану адрес

Іноді префікс зовсім не проблема. Два майданчики, які обидва використовують 192.168.1.0/24, означають, що одна й та сама адреса позначає два різні хости, і жоден маршрут не може їх розрізнити. Маршрут до хоста на одну з двох відповідей працює лише доти, доки другий майданчик не відповість на те саме ім'я, і тоді виняток мовчки стає самою помилкою.

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

5. Підтвердьте, що розв'язувач згоден із маршрутом

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

Зверніться до розв'язувача напряму й запишіть сервер, який відповів. Кешована відповідь із коротким TTL також може пояснити, чому перший запит після повторного підключення поводиться інакше, ніж п'ятий.

6. Повторно підключіться, огляньте застосований стан, а потім перевірте обидва потоки

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

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