OpenVPN-rûtemetryk: wêrom’t de keazen rûte noch altyd ferliest

Jo hawwe in metryk taheakke oan in rûte yn it profyl, opnij ferbûn, en it ferkear giet noch altyd út troch it ferkearde ynterface. It nûmer is selden it probleem. In metryk oardereet allinnich kandidaten dy’t it bestjoeringssysteem al fergeliket, en in spesifyker prefiks of in eardere beliedstabel beslút foardat der ea in metryk lêzen wurdt.

Rin earst it profyl troch, dan de ynstallearre tabel, dan de seleksjeregels. Dy folchoarder komt oerien mei de manier wêrop’t de klient de rûte bout en hâldt jo tsjin om in wearde ôf te stellen dy’t nea yn ’e fergeliking komt.

Lês de rûterigel yn fjildfolchoarder

In OpenVPN 2.6-mienskiplikliïnt akseptearret fjouwer fjilden op in IPv4 route-rigel: netwurk, netmasker, gateway en in opsjonele metryk. De gatewayposysje is wêr’t it spesjale kaaiwurd vpn_gateway hinne giet. It betsjut de folgjende sprong oan ’e VPN-kant foar dizze ferbining, net in rûtetabelnûmer en net jo fysike router. Mis dat en de rest fan ’e rigel wurdt lêzen mei in ferkeard idee fan wat it docht. netwurkopsjes-referinsje dokumentearret alle fjouwer fjilden.

Foar in privee bestimming kin de rigel sa lêze:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

De eksplisite 30 jildt foar dy rûte, en de 50 bliuwt de standert foar elke oare rûte yn it profyl dy’t in nûmer weilitten hat. It lêzen fan ’e rigel fan links nei rjochts is genôch om te sjen hokker wearde wêr jildt.

route-metric is in standert, gjin rang

route-metric set de fallback foar rûtes dy’t har eigen nûmer net drage. It tilt gjin rûte boppe eat oars en it oardereet gjin rûtes dy’t mei eksplisite metryken ynstallearre binne.

Dat ûnderskie is fan belang as in profyl beide foarmen mingt. Ien inkele route-metric-rigel tichtby de boppekant liket gesachhawwend en is maklik om te beskôgjen, wylst de rûte dy’t it ferkear eins draacht miskien syn eigen metryk trije rigels fierder hat.

As jo wolle dat ien rûte in paad foarkar jout, set it nûmer op dy rûte. As jo in konsekwinte standert oer in generearre profyl wolle, brûk route-metric en lit de yndividuele rigels gewurde. It mingen fan de twa sûnder reden is hoe’t in profyl einiget mei in rûte dy’t nimmen ferklearje kin.

Besjoch wat de klient ynstallearre hat

Neidat it opnij ferbinen foltôge is, freegje it kernel ynstee fan it profyl.

ip route show listet de rûtes op dy’t de klient taheakke hat, en ip route get 172.20.5.10 beantwurdet de nuttiger fraach: hokker rûte dizze bestimming eins brûke soe, en mei hokker boarneadres. As de bestimming yn ’e tabel ûntbrekt, hat de klient it net ynstallearre.

In lokale direktyf, in server-push of in oare netwurkbehearder kinne itselde prefiks taheakje of fuorthelje, en de lêste skriuwer wint. Hâld de einpunt-rûte yn ’t sicht wylst jo wurkje, want de ferbining hat in paad nedich nei de fiere server dat net troch de tunnel rint dy’t it bout.

Wêrom’t in lytsere metryk noch altyd ferliest

Metryken fergelikje rûtes nei deselde bestimming. Se meitsje in breed prefiks net spesifyker. As redirect-gateway def1 yn it spul is, ynstallearret de klient 0.0.0.0/1 en 128.0.0.0/1, en dy beide prefiksen beslaan de hiele IPv4-romte spesifyker as 0.0.0.0/0. In metryk fan 1 op ’e standertrûte oertreft se net.

Deselde logika jildt foar elk oerlappend pear. In /24 ferslacht in /16 foar in adres deryn, los fan ’e taheakke nûmers, want de syktocht kiest earst de meast spesifike oerienkomst en fergeliket pas dêrnei metryken tusken gelikense.

Dit is it part dat op in metrykflater liket en it net is. Kontrolearje de prefikslengte op beide kandidaten foardat jo hokker nûmer dan ek feroarje.

Beliedsregels rinne foar de tabel

Op Linux beslút ip rule hokker rûtetabel rieplachte wurdt. Regels wurde yn prioriteitsfolchoarder beoardiele, dus in eardere tabel kin in rûte weromjaan foardat de haadtabel ea lêzen wurdt. In metryk binnen main kin in oerienkomst yn in tabel dy’t earst rieplachte waard net oertreffe.

Brûk ip rule show en freegje dan de spesifike tabel op, bygelyks ip route show table 100, om te sjen wat dy regel weromjaan soe. As in VPN-klient of in container-runtime in regel taheakke hat, kin it antwurd dêr wêze ynstee fan yn ’e tabel dy’t jo lêzen hawwe. It boarneadres is ek fan belang, want in regel kin op ’e boarne oerienkomme en deselde bestimming oars oplosse foar tunnelferkear en LAN-ferkear.

Ferifiearje de bestimming, net de ranglist

De test dy’t de diskusje einiget is ien fraach oan in host binnen it bedoelde subnet, plus in kontrôle fan it boarneadres dat it kernel keas. As dat pear by it ûntwerp past, docht de metryk syn wurk, ek as de list der net as in skjinne ranglist útsjocht.

Lit IPv6 en DNS bûten dizze kontrôle. Se wurde ynsteld troch oare direktyven en oplost troch oare meganismen, en in wurkjende IPv4-rûte seit neat oer ien fan beide. Feroarje ien laach tagelyk en rin de fraach opnij.