Метрыка маршруту 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 нічога не кажа ні пра адно з іх. Змяняйце адзін узровень за раз і паўтарайце запыт.