Два клієнти VPN, одна таблиця маршрутизації: хто отримує маршрут за замовчуванням

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

Конфлікт живе в таблиці маршрутизації

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

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

Прочитайте, який тунель володіє поточним шляхом

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

ip route get 10.20.0.5
route print -4

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

Зупиніть другий клієнт від претензій на все

Один клієнт має володіти маршрутом за замовчуванням, а другий — нести лише власні префікси. OpenVPN клієнти можуть відмовитися від того, що нав'язує сервер.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ігнорує кожен нав'язаний маршрут, а pull-filter ignore "redirect-gateway" відкидає лише директиву маршруту за замовчуванням і зберігає нав'язаний DNS та інші параметри. Виберіть між ними за тим, скільки конфігурації сервера вам ще потрібно, потім додайте конкретні префікси, потрібні другій мережі. Пам'ятайте про DNS, бо резолвер, нав'язаний тунелем, який не несе запити, нічого не повертає. Перевірте один відомий хост у кожній мережі та підтвердьте адресу джерела, яку бачить віддалена сторона.

Перекривні підмережі не можна обійти

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

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