OpenVPN-roetemetriek: waarom die gekose roete steeds verloor

Jy het ’n metriek by ’n roete in die profiel gevoeg, weer gekoppel, en die verkeer verlaat steeds deur die verkeerde koppelvlak. Die nommer is selde die probleem. ’n Metriek orden net kandidate wat die bedryfstelsel reeds vergelyk, en ’n meer spesifieke voorvoegsel of ’n vroeër beleidstabel besluit voordat enige metriek gelees word.

Werk eers deur die profiel, dan die geïnstalleerde tabel, dan die seleksiereëls. Daardie volgorde stem ooreen met hoe die kliënt die roete bou en keer dat jy ’n waarde fynstel wat nooit by die vergelyking uitkom nie.

Lees die roetereël in veldorde

’n OpenVPN 2.6-gemeenskapkliënt aanvaar vier velde op ’n IPv4 route-reël: netwerk, netmasker, gateway en ’n opsionele metriek. Die gatewayposisie is waar die spesiale vpn_gateway-sleutelwoord gaan. Dit beteken die volgende sprong aan die VPN-kant vir hierdie verbinding, nie ’n roetetabelnommer nie en nie jou fisiese router nie. Mis dit en die res van die reël word gelees met die verkeerde idee van wat dit doen. Die netwerkopsies-verwysing dokumenteer al vier velde.

Vir ’n privaat bestemming kan die reël so lees:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Die eksplisiete 30 geld vir daardie roete, en die 50 bly die verstek vir elke ander roete in die profiel wat ’n nommer weglaat. Om die reël van links na regs te lees, is genoeg om te sien watter waarde waar geld.

route-metric is ’n verstek, nie ’n rang nie

route-metric stel die terugval vir roetes wat nie hul eie nommer dra nie. Dit skuif nie ’n roete bo iets anders nie, en dit herorden nie roetes wat met eksplisiete metrieke geïnstalleer is nie.

Daardie onderskeid maak saak wanneer ’n profiel albei vorms meng. ’n Enkele route-metric-reël naby die bokant lyk gesaghebbend en is maklik om te blameer, terwyl die roete wat werklik verkeer dra dalk sy eie metriek drie reëls verder het.

As jy wil hê een roete moet ’n pad verkies, sit die nommer op daardie roete. As jy ’n konsekwente verstek oor ’n gegenereerde profiel wil hê, gebruik route-metric en los die individuele reëls alleen. Om die twee sonder ’n rede te meng, is hoe ’n profiel eindig met ’n roete wat niemand kan verduidelik nie.

Ondersoek wat die kliënt geïnstalleer het

Nadat die herkoppeling voltooi is, vra die kern eerder as die profiel.

ip route show lys die roetes wat die kliënt bygevoeg het, en ip route get 172.20.5.10 beantwoord die nuttiger vraag: watter roete hierdie bestemming werklik sou gebruik, met watter bronadres. As die bestemming in die tabel ontbreek, het die kliënt dit nie geïnstalleer nie.

’n Plaaslike direktief, ’n bediener-push of ’n ander netwerkbestuurder kan dieselfde voorvoegsel byvoeg of verwyder, en die laaste skrywer wen. Hou die eindpuntroete in sig terwyl jy werk, want die verbinding het ’n pad na die afgeleë bediener nodig wat nie deur die tonnel loop wat dit bou nie.

Waarom ’n kleiner metriek steeds verloor

Metrieke vergelyk roetes na dieselfde bestemming. Hulle maak nie ’n breë voorvoegsel meer spesifiek nie. Wanneer redirect-gateway def1 in werking is, installeer die kliënt 0.0.0.0/1 en 128.0.0.0/1, en daardie twee voorvoegsels dek die hele IPv4-ruimte meer spesifiek as 0.0.0.0/0. ’n Metriek van 1 op die verstekroete oortref hulle nie.

Dieselfde logika geld vir enige oorvleuelende paar. ’n /24 klop ’n /16 vir ’n adres daarbinne, ongeag die nommers wat aangeheg is, want die opsoek kies eerste die mees spesifieke passing en vergelyk eers daarna metrieke tussen gelykes.

Dit is die deel wat soos ’n metriekfout lyk en nie een is nie. Kyk na die voorvoegsellengte op albei kandidate voordat jy enige nommer verander.

Beleidsreëls loop voor die tabel

Op Linux besluit ip rule watter roetetabel geraadpleeg word. Reëls word in prioriteitsorde geëvalueer, so ’n vroeër tabel kan ’n roete terugstuur voordat die hooftabel ooit gelees word. ’n Metriek in main kan nie ’n passing in ’n tabel wat eerste geraadpleeg is oortref nie.

Gebruik ip rule show en vra dan die spesifieke tabel, byvoorbeeld ip route show table 100, om te sien wat daardie reël sou terugstuur. As ’n VPN-kliënt of ’n houerlooptyd ’n reël bygevoeg het, is die antwoord dalk daar eerder as in die tabel wat jy gelees het. Bronadres maak ook saak, want ’n reël kan op die bron pas en dieselfde bestemming anders oplos vir tonnelverkeer en LAN-verkeer.

Verifieer die bestemming, nie die rangorde nie

Die toets wat die argument beëindig, is ’n enkele navraag na ’n gasheer binne die beoogde subnet, plus ’n kontrole van die bronadres wat die kern gekies het. As daardie paar by die ontwerp pas, doen die metriek sy werk selfs wanneer die lys nie soos ’n skoon rangorde lyk nie.

Los IPv6 en DNS uit hierdie kontrole. Hulle word deur ander direktiewe gekonfigureer en deur ander meganismes opgelos, en ’n werkende IPv4-roete sê niks oor enige van hulle nie. Verander een laag op ’n slag en herhaal die navraag.