OpenVPN-itinera metriko: kial la elektita itinero ankoraŭ malvenkas

Vi aldonis metrikon al itinero en la profilo, rekonektis, kaj la trafiko ankoraŭ eliras tra la malĝusta interfaco. La nombro malofte estas la problemo. Metriko nur ordigas la kandidatojn, kiujn la operaciumo jam komparas, kaj pli specifa prefikso aŭ pli frua politika tabelo decidas antaŭ ol ajna metriko estas legata.

Unue trairu la profilon, poste la instalitan tabelon, poste la elekto-regulojn. Tiu ordo kongruas kun la maniero, kiel la kliento konstruas la itineron, kaj malhelpas vin agordi valoron, kiu neniam eniras la komparon.

Legu la itineran linion laŭ la ordo de kampoj

Kliento de la komunumo OpenVPN 2.6 akceptas kvar kampojn en IPv4 route-linio: reto, retmasko, pordego kaj laŭvola metriko. La pordega pozicio estas kie iras la speciala ŝlosilvorto vpn_gateway. Ĝi signifas la sekvan salteton ĉe la VPN-flanko por ĉi tiu konekto, ne numeron de enkursiga tabelo kaj ne vian fizikan enkursigilon. Se vi maltrafas tion, la resto de la linio estas legata kun malĝusta ideo pri tio, kion ĝi faras. referenco pri retaj agordoj dokumentas ĉiujn kvar kampojn.

Por privata celo la linio povas legiĝi:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

La eksplicita 30 validas por tiu itinero, kaj la 50 restas la defaŭlto por ĉiu alia itinero en la profilo, kiu preterlasas nombron. Legi la linion de maldekstre dekstren sufiĉas por vidi, kiu valoro validas kie.

route-metric estas defaŭlto, ne rango

route-metric starigas la rezervan valoron por itineroj, kiuj ne portas sian propran nombron. Ĝi ne levigas itineron super io ajn, kaj ĝi ne reordigas itinerojn instalitajn kun eksplicitaj metrikoj.

Tiu distingo gravas, kiam profilo miksas ambaŭ formojn. Unu sola route-metric-linio proksime al la supro aspektas aŭtoritata kaj estas facile kulpigebla, dum la itinero, kiu fakte portas trafikon, povas porti sian propran metrikon tri liniojn pli malsupre.

Se vi volas, ke unu itinero preferu vojon, metu la nombron sur tiun itineron. Se vi volas konsekvencan defaŭlton tra generita profilo, uzu route-metric kaj lasu la unuopajn liniojn trankvilaj. Miksi la du sen kialo estas la maniero, kiel profilo finiĝas kun itinero, kiun neniu povas klarigi.

Kontrolu, kion la kliento instalas

Post kiam la rekonekto finiĝas, demandu la kernon, ne la profilon.

ip route show listigas la itinerojn, kiujn la kliento aldonis, kaj ip route get 172.20.5.10 respondas la pli utilan demandon: kiun itineron ĉi tiu celo fakte uzus, kun kiu fonta adreso. Se la celo mankas en la tabelo, la kliento ne instalas ĝin.

Loka direktivo, puŝo de servilo aŭ alia retadministrilo povas aldoni aŭ forigi la saman prefikson, kaj la lasta skribanto venkas. Tenu la finpunkton-itineron en la vido dum vi laboras, ĉar la konekto bezonas vojon al la fora servilo, kiu ne iras tra la tunelo, kiun ĝi konstruas.

Kial pli malgranda metriko ankoraŭ malvenkas

Metrikoj komparas itinerojn al la sama celo. Ili ne faras larĝan prefikson pli specifa. Kiam redirect-gateway def1 estas en ludo, la kliento instalas 0.0.0.0/1 kaj 128.0.0.0/1, kaj tiuj du prefiksoj kovras la tutan IPv4-spacon pli specife ol 0.0.0.0/0. Metriko de 1 sur la defaŭlta itinero ne superas ilin.

La sama logiko validas por ajna interkovriĝanta paro. /24 venkas /16 por adreso interne, sendepende de la alkroĉitaj nombroj, ĉar la serĉo unue elektas la plej specifan kongruon kaj nur poste komparas metrikojn inter egaluloj.

Ĉi tio estas la parto, kiu aspektas kiel metrika fuŝo kaj ne estas. Kontrolu la prefikso-longon ĉe ambaŭ kandidatoj antaŭ ol ŝanĝi ajnan nombron.

Politikaj reguloj ruliĝas antaŭ la tabelo

En Linux, ip rule decidas, kiun enkursigan tabelon konsulti. Reguloj estas taksataj laŭ prioritata ordo, do pli frua tabelo povas redoni itineron antaŭ ol la ĉefa tabelo eĉ estas legata. Metriko ene de main ne povas superi kongruon en tabelo, kiu estis konsultita unue.

Uzu ip rule show kaj poste demandu la konkretan tabelon, ekzemple ip route show table 100, por vidi, kion tiu regulo redonus. Se VPN-kliento aŭ ujuja rulmedio aldonis regulon, la respondo povas esti tie anstataŭ en la tabelo, kiun vi legis. Ankaŭ la fonta adreso gravas, ĉar regulo povas kongrui kun la fonto kaj solvi la saman celon malsame por tunela trafiko kaj LAN-trafiko.

Kontrolu la celon, ne la rangigadon

La testo, kiu finas la disputon, estas unu sola demando al gastiganto ene de la celata subreto, plus kontrolo de la fonta adreso, kiun la kerno elektis. Se tiu paro kongruas kun la dezajno, la metriko faras sian taskon, eĉ kiam la listo ne aspektas kiel pura rangigado.

Lasu IPv6 kaj DNS ekster ĉi tiu kontrolo. Ili estas agordataj per malsamaj direktivoj kaj solvataj per malsamaj mekanismoj, kaj funkcianta IPv4-itinero diras nenion pri iu ajn el ili. Ŝanĝu unu tavolon samtempe kaj reruŝu la demandon.