Два VPN-клієнти на одному комп'ютері: що конфліктує і що працює

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

Крок 1: з'ясуйте, який клієнт володіє виходом

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

ip route get 1.1.1.1
ip route show default
route print

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

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

Крок 2: перевірте резолвер і перекривані префікси

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

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

Зупиніться тут, якщо префікси перекриваються. Усе подальше в цьому списку припускає, що вони не перекриваються.

Крок 3: виберіть схему розділення, яка тримається

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

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

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

Крок 4: перевірте обидві мережі з однієї сесії

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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