Чому одна підмережа досі обходить типовий маршрут VPN

Ви перемикаєте VPN на повний тунель, більшість трафіку слухається, а потім одна адреса відповідає напряму — принтер, NAS, проміжний хост у 10.x. Очевидне прочитання — тунель протікає, тож ви знижуєте метрику типового маршруту, і нічого не змінюється. Ця невдала спроба і є підказкою: типовий маршрут — це запасний варіант, а не вирок. Пошук маршруту бере найдовший відповідний префікс ще до того, як порівняти метрики, тому /24 продовжує перемагати /0, яке б число ви не прив'язали до будь-якого з них. Щойно цей порядок стає зрозумілим, витік зазвичай виявляється маршрутом, який хтось навмисно встановив, або префіксом, який клієнт ніколи не мав наміру охоплювати.

Що типовий маршрут насправді обіцяє

0.0.0.0/0 збігається з будь-яким призначенням IPv4 із нульовою специфічністю бітів. Він існує, щоб хост міг дістатися всього, чого його таблиця не описує краще. Маршрут до 192.168.1.0/24 несе 24 відповідні біти, тож для 192.168.1.40 він перемагає раніше, ніж хтось порівняє метрики, адміністративну відстань або те, що клієнт називає полем пріоритету. Те саме правило діє у FIB Linux, таблиці маршрутизації Windows і стеку BSD за macOS.

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

Напівтипові маршрути, або чому типовий запис може виглядати недоторканим

Найчистіший приклад — redirect-gateway def1 в OpenVPN. Замість видалення й заміни типового маршруту він додає 0.0.0.0/1 і 128.0.0.0/1. Разом пара охоплює весь IPv4, кожен префікс довший за /0, і обидва перемагають типовий маршрут маршрутизатора, залишаючи його на місці. Запустіть після цього список маршрутів, і початковий типовий маршрут усе ще там, усе ще вказує на ваш шлюз; просто він ніколи не вибирається для інтернет-призначень.

wg-quick із WireGuard досягає того самого результату через маршрутизацію на основі політики. Коли AllowedIPs охоплює 0.0.0.0/0, він створює власну таблицю, надсилає туди позначені пакети й додає правило, що ігнорує префікс нульової довжини основної таблиці. Основна таблиця зберігає свій типовий запис, а правила вирішують, що для трафіку, яким володіє інтерфейс, спершу питають таблицю тунелю.

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

Метрики вирішують нічию, префікси вирішують переможців

Метрики порівнюються лише серед кандидатів, що однаково добре відповідають призначенню. У Linux ip route get 10.20.5.9 виводить переможця разом із його таблицею, а ip route show table all перелічує кандидатів, включно з будь-якими напівтиповими маршрутами та будь-якою таблицею, на яку вказує правило. У Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 повертає вибраний маршрут і адресу джерела, а Get-NetRoute показує сиру таблицю — але ефективна вартість — це метрика маршруту плюс метрика інтерфейсу, тож повільний адаптер може програти нічию, яку начебто виграє.

Три випадки охоплюють більшість того, що ви побачите:

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

Третій випадок — це місце, де закінчується більшість таких звітів. Правило ip rule у Linux або фільтр VPN-трафіку Windows може надіслати трафік до таблиці, яка ніколи не містила типового маршруту тунелю, а основна таблиця весь час виглядає бездоганно.

Кому зазвичай належить обхід

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

Потім шукайте залишки. Маршрут, що вказує на інтерфейс, якого більше немає, або на адресу з попередньої мережі, з'являється після підключення й відключення док-станцій, USB-адаптерів і мостів контейнерів. Видалити його один раз — не кінець: профілі підключень NetworkManager, файли netplan і постійні маршрути Windows встановлюють його знову при наступному підключенні або завантаженні, тож знайдіть файл або профіль, якому він належить, перш ніж щось змінювати.

Потім перевірте IPv6 окремо. ip -6 route і Get-NetRoute -AddressFamily IPv6 зберігають окремий стан, окремі типові маршрути й окрему поведінку клієнта. Аудит лише IPv4 нічого не каже про хост із подвійним стеком, який тихо віддає перевагу рідному шляху IPv6, і саме це може змусити клієнт виглядати як split-tunnel.

Підтвердьте власним потоком застосунку

Запишіть призначення, яке застосунок справді використовує, а потім запитайте систему про шлях, який він обрав би з адреси джерела, до якої цей застосунок прив'язується. ip route get 10.20.5.9 from 192.168.1.40 відповідає на це в Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 плюс локальна адреса робить це в Windows. Порівняйте результат із тим, що стверджує профіль. Сторінка публічної IP у браузері перевіряє одне призначення за одним протоколом і нічого не каже про приватну адресу, з якої почалася скарга.

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

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

• Назвіть призначення й адресу джерела, які застосунок справді використовує.
• Виведіть переможний маршрут за допомогою ip route get або Find-NetRoute.
• Перевірте, чи інтернет-шляхом володіє пара /1 чи таблиця політики.
• Перелічіть кожен префікс, довший за /0, що відповідає призначенню.
• Повторіть перевірку IPv6 окремо.
• Простежте маршрут, що залишився, назад до файлу, профілю або фільтра, який його встановлює.
• Перепідключіться й виконайте запит ще раз, перш ніж називати це виправленим.

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