Метрика на маршрута в OpenVPN: защо избраният маршрут все още губи

Добавихте метрика към маршрут в профила, свързахте се отново, а трафикът все още излиза през грешния интерфейс. Числото рядко е проблемът. Метриката подрежда само кандидатите, които операционната система вече сравнява, а по-специфичен префикс или по-ранна таблица за политики решава, преди да бъде прочетена каквато и да е метрика.

Първо прегледайте профила, после инсталираната таблица, после правилата за избор. Този ред съвпада с начина, по който клиентът изгражда маршрута, и ви спира да настройвате стойност, която никога не влиза в сравнението.

Прочетете реда на маршрута по реда на полетата

Клиентът на общността 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 отговаря на по-полезния въпрос: кой маршрут би използвала тази дестинация в действителност и с кой адрес на източника. Ако дестинацията липсва в таблицата, клиентът не я е инсталирал.

Локална директива, изтласкване от сървъра или друг мрежов мениджър могат да добавят или премахнат същия префикс и печели този, който пише последен. Дръжте маршрута до крайната точка пред очи, докато работите, защото връзката се нуждае от път до отдалечения сървър, който не минава през тунела, който изгражда.

Защо по-малка метрика все още губи

Метриките сравняват маршрути до една и съща дестинация. Те не правят широк префикс по-специфичен. Когато действа 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 не казва нищо за никое от двете. Променяйте един слой наведнъж и повтаряйте заявката.