Metric ng ruta ng OpenVPN: bakit natatalo pa rin ang piniling ruta

Nagdagdag ka ng metric sa isang ruta sa profile, nagkonekta muli, at sa maling interface pa rin lumalabas ang trapiko. Bihirang ang numero ang problema. Ang metric ay nag-aayos lang ng mga kandidatong inihahambing na ng operating system, at ang mas tiyak na prefix o mas naunang talahanayan ng patakaran ang nagpapasya bago pa mabasa ang anumang metric.

Unahin ang profile, pagkatapos ang naka-install na talahanayan, pagkatapos ang mga tuntunin sa pagpili. Tumutugma ang ayos na iyon sa paraan ng pagbuo ng ruta ng kliyente at pumipigil sa iyong i-tune ang isang halaga na hindi kailanman pumapasok sa paghahambing.

Basahin ang linya ng ruta sa ayos ng mga field

Tumatanggap ang isang kliyenteng Community OpenVPN 2.6 ng apat na field sa isang linyang route para sa IPv4: network, netmask, gateway at opsyonal na metric. Ang posisyon ng gateway ang lugar kung saan inilalagay ang espesyal na keyword na vpn_gateway. Ito ang susunod na hop sa panig ng VPN para sa koneksyong ito, hindi numero ng routing table at hindi ang iyong pisikal na router. Kapag napalampas iyon, ang natitirang bahagi ng linya ay binabasa nang may maling pag-unawa sa ginagawa nito. Dinodokumento ng reference ng mga opsyon sa network ang lahat ng apat na field.

Para sa isang pribadong destinasyon, maaaring ganito ang linya:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Ang tahasang 30 ay nalalapat sa rutang iyon, at ang 50 ay nananatiling default para sa bawat ibang ruta sa profile na hindi naglalagay ng numero. Sapat nang basahin ang linya mula kaliwa pakanan upang malaman kung aling halaga ang nalalapat saan.

route-metric ay default, hindi ranggo

route-metric ang nagtatakda ng fallback para sa mga rutang walang sariling numero. Hindi nito itinataas ang isang ruta sa ibabaw ng anuman at hindi nito muling inaayos ang mga rutang naka-install na may tahasang metric.

Mahalaga ang pagkakaibang iyon kapag pinaghahalo ng profile ang dalawang anyo. Ang nag-iisang linyang route-metric malapit sa itaas ay mukhang may awtoridad at madaling sisihin, samantalang ang rutang talagang nagdadala ng trapiko ay maaaring may sariling metric tatlong linya pababa.

Kung gusto mong mas piliin ng isang ruta ang isang daan, ilagay ang numero sa rutang iyon. Kung gusto mo ng pare-parehong default sa isang nabuong profile, gamitin ang route-metric at hayaan ang mga indibidwal na linya. Ang paghahalo ng dalawa nang walang dahilan ang paraan para matapos ang isang profile na may rutang walang makapagpapaliwanag.

Tingnan ang inilagay ng kliyente

Kapag natapos ang muling pagkonekta, tanungin ang kernel, hindi ang profile.

ip route show ay naglilista ng mga rutang idinagdag ng kliyente, at sinasagot ng ip route get 172.20.5.10 ang mas kapaki-pakinabang na tanong: aling ruta ang talagang gagamitin ng destinasyong ito, at sa aling source address. Kung wala ang destinasyon sa talahanayan, hindi ito inilagay ng kliyente.

Isang lokal na direktiba, isang push mula sa server o ibang tagapamahala ng network ang makakapagdagdag o makakapag-alis ng parehong prefix, at ang huling nagsulat ang nananalo. Panatilihing nasa paningin ang ruta patungo sa endpoint habang nagtatrabaho, dahil kailangan ng koneksyon ang daan patungo sa malayong server na hindi dumadaan sa tunnel na itinatayo nito.

Bakit natatalo pa rin ang mas maliit na metric

Inihahambing ng mga metric ang mga ruta patungo sa parehong destinasyon. Hindi nila ginagawang mas tiyak ang malawak na prefix. Kapag nasa laro ang redirect-gateway def1, naglalagay ang kliyente ng 0.0.0.0/1 at 128.0.0.0/1, at ang dalawang prefix na iyon ay sumasaklaw sa buong espasyong IPv4 nang mas tiyak kaysa 0.0.0.0/0. Ang metric na 1 sa default na ruta ay hindi lumalampas sa kanila.

Nalalapat ang parehong lohika sa anumang pares na nagsasapawan. Natalo ng /24 ang /16 para sa isang address sa loob nito anuman ang mga numerong nakakabit, dahil pinipili muna ng paghahanap ang pinakatiyak na tugma at pagkatapos lang inihahambing ang mga metric sa pagitan ng magkapantay.

Ito ang bahaging mukhang bug sa metric at hindi naman. Suriin ang haba ng prefix sa parehong kandidato bago baguhin ang anumang numero.

Umuuna ang mga tuntunin ng patakaran bago ang talahanayan

Sa Linux, ang ip rule ang nagpapasya kung aling routing table ang kokonsultahin. Sinusuri ang mga tuntunin sa ayos ng priyoridad, kaya makakabalik ang isang naunang talahanayan ng ruta bago pa mabasa ang pangunahing talahanayan. Hindi kayang lampasan ng isang metric sa loob ng main ang tugma sa isang talahanayang unang kinonsulta.

Gamitin ang ip rule show at pagkatapos ay tanungin ang partikular na talahanayan, halimbawa ang ip route show table 100, upang makita kung ano ang ibabalik ng tuntuning iyon. Kung nagdagdag ng tuntunin ang isang VPN client o container runtime, maaaring naroon ang sagot sa halip na sa talahanayang binabasa mo. Mahalaga rin ang source address, dahil ang isang tuntunin ay maaaring tumugma sa source at lutasin ang parehong destinasyon nang iba para sa trapikong pang-tunnel at trapikong LAN.

I-verify ang destinasyon, hindi ang ranggo

Ang pagsubok na nagtatapos sa debate ay isang query lang sa isang host sa loob ng sinadyang subnet, kasama ang pagsuri sa source address na pinili ng kernel. Kung tumutugma ang pares na iyon sa disenyo, ginagawa ng metric ang trabaho nito kahit hindi mukhang malinis na ranggo ang listahan.

Iwanan ang IPv6 at DNS sa labas ng tsekt na ito. Naka-configure ang mga ito ng ibang direktiba at nireresolba ng ibang mekanismo, at walang sinasabi ang gumaganang rutang IPv4 tungkol sa alinman sa kanila. Baguhin ang isang layer sa isang pagkakataon at patakbuhin muli ang query.