Рекурсивна маршрутизація: коли тунель перехоплює власні пакети

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

Спершу перевірте зовнішній шлях

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Чому сеанс тримається мить

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

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

Знайдіть власника винятку для кінцевої точки

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

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

Перевірте ще раз після зміни мережі

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

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

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