OpenVPN-rutemetrikk: kvifor den valde ruta framleis tapar

Du la til ein metrikk på ei rute i profilen, kopla til på nytt, og trafikken går framleis ut gjennom feil grensesnitt. Talet er sjeldan problemet. Ein metrikk ordnar berre kandidatar som operativsystemet alt samanliknar, og eit meir spesifikt prefiks eller ein tidlegare polisetabell avgjer før nokon metrikk blir lesen.

Gå gjennom profilen først, deretter den installerte tabellen, og til slutt utvalsreglane. Den rekkjefølgja følgjer måten klienten byggjer ruta på og hindrar deg i å justere ein verdi som aldri kjem inn i samanlikninga.

Les ruttelinja i feltrekkjefølgje

Ein Community OpenVPN 2.6-klient godtek fire felt på ei IPv4 route-linje: nettverk, nettmaske, gateway og ein valfri metrikk. Gateway-posisjonen er der det spesielle nøkkelordet vpn_gateway står. Det tyder neste hopp på VPN-sida for denne tilkoplinga, ikkje eit rutingtabellnummer og ikkje den fysiske rutaren din. Går det tapt, blir resten av linja lesen med ei feil oppfatning av kva ho gjer. network-options-referansen dokumenterer alle fire felta.

For ein privat destinasjon kan linja sjå slik ut:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Den eksplisitte 30 gjeld for den ruta, og 50 blir verande standarden for alle andre ruter i profilen som utelèt eit tal. Å lese linja frå venstre til høgre er nok til å seie kva verdi som gjeld kvar.

route-metric er ein standard, ikkje ein rang

route-metric set fallbacken for ruter som ikkje har sitt eige tal. Det skyvar ikkje ei rute over noko anna, og det omorganiserer ikkje ruter som vart installerte med eksplisitte metrikkar.

Den forskjellen betyr noko når ein profil blandar begge formene. Ei enkel route-metric-linje nær toppen ser autoritativ ut og er lett å skylde på, medan ruta som faktisk ber trafikk kan bere sin eigen metrikk tre linjer lenger nede.

Vil du at éi rute skal føretrekke ein veg, set talet på den ruta. Vil du ha ein konsistent standard gjennom ein generert profil, bruk route-metric og lat dei enkelte linjene vere. Å blande dei to utan grunn er korleis ein profil endar opp med ei rute ingen kan forklare.

Undersøk kva klienten installerte

Når gjentilkoplinga er ferdig, spør kjernen og ikkje profilen.

ip route show listar rutene klienten la til, og ip route get 172.20.5.10 svarar på det meir nyttige spørsmålet: kva rute denne destinasjonen faktisk ville bruke, og med kva kjeldeadresse. Manglar destinasjonen i tabellen, installerte ikkje klienten henne.

Eit lokalt direktiv, ein server-push eller ein annan nettverkshandsamar kan leggje til eller fjerne det same prefikset, og den som skriv sist vinn. Hald endepunkt-ruta i syne medan du arbeider, fordi tilkoplinga treng ein veg til fjernserveren som ikkje går gjennom tunnelen ho byggjer.

Kvifor ein mindre metrikk framleis tapar

Metrikkar samanliknar ruter til same destinasjon. Dei gjer ikkje eit breitt prefiks meir spesifikt. Når redirect-gateway def1 er i spel, installerer klienten 0.0.0.0/1 og 128.0.0.0/1, og dei to prefiksa dekkjer heile IPv4-rommet meir spesifikt enn 0.0.0.0/0. Ein metrikk på 1 på standardruta slår dei ikkje.

Den same logikken gjeld for eitkvart overlappande par. Ei /24 slår ei /16 for ei adresse innanfor, same kva tal som er festa, fordi oppslaget vel det mest spesifikke treffet først og berre deretter samanliknar metrikkar mellom like.

Dette er delen som ser ut som ein metrikkfeil og ikkje er det. Sjekk prefikslengda på begge kandidatane før du endrar noko tal.

Politikkreglar køyrer før tabellen

På Linux avgjer ip rule kva rutingtabell som blir konsultert. Reglar blir vurderte i prioritetsrekkjefølgje, så ein tidlegare tabell kan returnere ei rute før hovudtabellen i det heile blir lesen. Ein metrikk i main kan ikkje slå eit treff i ein tabell som vart konsultert først.

Bruk ip rule show og spør deretter den spesifikke tabellen, til dømes ip route show table 100, for å sjå kva den regelen ville returnere. Viss ein VPN-klient eller ein container-runtime la til ein regel, kan svaret vere der i staden for i tabellen du har lese. Kjeldeadressa betyr òg noko, sidan ein regel kan matche på kjelda og løyse same destinasjon ulikt for tunneltrafikk og LAN-trafikk.

Stadfest destinasjonen, ikkje rangeringa

Testen som avsluttar diskusjonen er eit enkelt oppslag mot ein vert i det tiltenkte subnettet, pluss ein sjekk av kjeldeadressa kjernen valde. Viss det paret passar med designet, gjer metrikken jobben sin sjølv når lista ikkje ser ut som ein ryddig rangering.

Hald IPv6 og DNS utanfor denne sjekken. Dei blir konfigurerte av andre direktiv og løyste av andre mekanismar, og ei fungerande IPv4-rute seier ingenting om nokon av dei. Endre eitt lag om gongen og køyr oppslaget på nytt.