Метрика маршруту OpenVPN: чому обраний маршрут усе одно програє

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

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

Читайте рядок маршруту в порядку полів

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

Для приватного призначення рядок може виглядати так:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

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

route-metric — це типове значення, а не ранг

route-metric задає запасне значення для маршрутів, які не мають власного числа. Вона не піднімає маршрут над іншими і не перевпорядковує маршрути, встановлені з явними метриками.

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

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

Подивіться, що встановив клієнт

Після завершення перепідключення питайте ядро, а не профіль.

ip route show перелічує маршрути, додані клієнтом, а ip route get 172.20.5.10 відповідає на корисніше питання: який маршрут це призначення реально використає і з якої вихідної адреси. Якщо призначення немає в таблиці, отже клієнт його не встановив.

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

Чому менша метрика все одно програє

Метрики порівнюють маршрути до одного призначення. Вони не роблять широкий префікс конкретнішим. Коли задіяно redirect-gateway def1, клієнт встановлює 0.0.0.0/1 і 128.0.0.0/1, і ці два префікси покривають увесь простір IPv4 конкретніше, ніж 0.0.0.0/0. Метрика 1 на типовому маршруті їх не перевершує.

Та сама логіка стосується будь-якої пари, що перекривається. /24 перемагає /16 для адреси всередині нього незалежно від прикріплених чисел, бо пошук спершу вибирає найконкретніший збіг і лише потім порівнює метрики між рівними.

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

Правила політик виконуються раніше за таблицю

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

Використайте ip rule show, а потім запитайте конкретну таблицю, наприклад ip route show table 100, щоб побачити, що повернуло б це правило. Якщо правило додав VPN-клієнт або середовище виконання контейнерів, відповідь може бути там, а не в таблиці, яку ви читали. Вихідна адреса також важлива, бо правило може збігатися за джерелом і розв'язувати те саме призначення по-різному для тунельного трафіку й трафіку LAN.

Перевіряйте призначення, а не рейтинг

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

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