Metrica de rută OpenVPN: de ce ruta aleasă tot pierde

Ai adăugat o metrică unei rute din profil, te-ai reconectat, iar traficul tot pleacă prin interfața greșită. Numărul e rareori problema. O metrică doar ordonează candidații pe care sistemul de operare îi compară deja, iar un prefix mai specific sau un tabel de politici evaluat mai devreme decide înainte ca vreo metrică să fie citită.

Parcurge mai întâi profilul, apoi tabela instalată, apoi regulile de selecție. Această ordine corespunde modului în care clientul construiește ruta și te oprește să reglezi o valoare care nu intră niciodată în comparație.

Citește linia de rută în ordinea câmpurilor

Un client Community OpenVPN 2.6 acceptă patru câmpuri pe o linie route IPv4: rețea, mască, gateway și o metrică opțională. Poziția gateway-ului este locul unde se pune cuvântul-cheie special vpn_gateway. El înseamnă următorul salt din partea VPN pentru această conexiune, nu un număr de tabelă de rutare și nu routerul tău fizic. Dacă ratezi asta, restul liniei este citit cu ideea greșită despre ce face. Referința pentru opțiunile de rețea documentează toate cele patru câmpuri.

Pentru o destinație privată, linia poate arăta așa:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Valoarea explicită 30 se aplică acelei rute, iar 50 rămâne implicită pentru orice altă rută din profil care omite un număr. Citirea liniei de la stânga la dreapta este suficientă ca să afli ce valoare se aplică unde.

route-metric este o valoare implicită, nu un rang

route-metric stabilește valoarea de rezervă pentru rutele care nu au propriul număr. Nu împinge o rută deasupra alteia și nu reordonează rutele instalate cu metrici explicite.

Distincția contează când un profil amestecă ambele forme. O singură linie route-metric aproape de început pare autoritară și e ușor de învinuit, în timp ce ruta care chiar duce traficul poate avea propria metrică trei linii mai jos.

Dacă vrei ca o rută să prefere o cale, pune numărul pe acea rută. Dacă vrei o valoare implicită consecventă într-un profil generat, folosește route-metric și lasă liniile individuale în pace. Amestecarea celor două fără motiv este felul în care un profil ajunge cu o rută pe care nimeni nu o poate explica.

Inspectează ce a instalat clientul

După ce reconectarea se încheie, întreabă kernelul, nu profilul.

ip route show listează rutele adăugate de client, iar ip route get 172.20.5.10 răspunde la întrebarea mai utilă: ce rută ar folosi de fapt această destinație și cu ce adresă sursă. Dacă destinația lipsește din tabelă, clientul nu a instalat-o.

O directivă locală, un push de la server sau un alt manager de rețea poate adăuga sau elimina același prefix, iar ultimul care scrie câștigă. Ține ruta endpointului în vedere cât lucrezi, pentru că conexiunea are nevoie de o cale către serverul remote care să nu treacă prin tunelul pe care îl construiește.

De ce o metrică mai mică tot pierde

Metricile compară rute către aceeași destinație. Ele nu fac un prefix larg mai specific. Când redirect-gateway def1 este în joc, clientul instalează 0.0.0.0/1 și 128.0.0.0/1, iar aceste două prefixe acoperă tot spațiul IPv4 mai specific decât 0.0.0.0/0. O metrică de 1 pe ruta implicită nu le depășește.

Aceeași logică se aplică oricărei perechi care se suprapune. Un /24 bate un /16 pentru o adresă din interiorul lui, indiferent de numerele atașate, pentru că căutarea alege mai întâi potrivirea cea mai specifică și abia apoi compară metricile între egali.

Aceasta este partea care pare un bug de metrică și nu este. Verifică lungimea prefixului la ambii candidați înainte de a schimba vreun număr.

Regulile de politică rulează înaintea tabelei

Pe Linux, ip rule decide ce tabelă de rutare este consultată. Regulile sunt evaluate în ordinea priorității, așa că un tabel anterior poate returna o rută înainte ca tabelul principal să fie citit. O metrică din main nu poate depăși o potrivire dintr-un tabel consultat primul.

Folosește ip rule show și apoi interoghează tabelul specific, de exemplu ip route show table 100, ca să vezi ce ar returna regula respectivă. Dacă un client VPN sau un runtime de containere a adăugat o regulă, răspunsul poate fi acolo, nu în tabelul pe care îl citeai. Adresa sursă contează și ea, fiindcă o regulă poate potrivi sursa și poate rezolva aceeași destinație diferit pentru traficul tunelului și pentru cel din LAN.

Verifică destinația, nu clasamentul

Testul care încheie discuția este o singură interogare către un host din subrețeaua dorită, plus verificarea adresei sursă pe care a ales-o kernelul. Dacă perechea aceea corespunde proiectului, metrica își face treaba chiar și atunci când listarea nu arată ca un clasament curat.

Lasă IPv6 și DNS în afara acestei verificări. Ele sunt configurate prin directive diferite și rezolvate prin mecanisme diferite, iar o rută IPv4 funcțională nu spune nimic despre niciunul. Schimbă un singur strat odată și rulează din nou interogarea.