Два VPN-клієнти одночасно: хто виграє маршрут за замовчуванням?

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

Таблиця маршрутів обирає одного переможця

Зніміть таблицю до та після запуску корпоративного клієнта і читайте стовпець інтерфейсу, а не лише пункт призначення. Звичайний маршрут за замовчуванням із зовнішнього тунелю легко витіснити, бо пара /1 конкретніша за /0. Буквальна пара 0.0.0.0/1 і 128.0.0.0/1 покриває весь простір IPv4 двома половинами і перемагає будь-який одиничний маршрут за замовчуванням. Після встановлення зовнішній тунель усе ще показується під'єднаним і нічого не переносить.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

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

ip rule show

Windows вирішує це метриками

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

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

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

Два спостерігачі, два різні погляди

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

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

DNS і IPv6 — це місця, де ланцюжок протікає

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

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

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