Metrika trasy v OpenVPN: proč zvolená trasa stále prohrává

Přidali jste metrku k trase v profilu, znovu se připojili a provoz stále odchází přes špatné rozhraní. Číslo je zřídka tím problémem. Metrika pouze řadí kandidáty, které operační systém už porovnává, a konkrétnější prefix nebo dřívější tabulka zásad rozhodne dřív, než se jakákoli metrika přečte.

Nejprve projděte profil, potom nainstalovanou tabulku a nakonec pravidla výběru. Toto pořadí odpovídá tomu, jak klient trasu sestavuje, a brání vám ladit hodnotu, která se do porovnání nikdy nedostane.

Přečtěte řádek trasy v pořadí polí

Klient komunity OpenVPN 2.6 přijímá na řádku route pro IPv4 čtyři pole: síť, masku sítě, bránu a volitelnou metriku. Pozice brány je místo, kam patří speciální klíčové slovo vpn_gateway. Znamená další skok na straně VPN pro toto připojení, nikoli číslo směrovací tabulky a nikoli váš fyzický router. Když to vynecháte, čte se zbytek řádku s chybnou představou o tom, co dělá. reference síťových možností dokumentuje všechna čtyři pole.

Pro soukromé cíle může řádek vypadat takto:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Explicitní 30 platí pro tuto trasu a 50 zůstává výchozí hodnotou pro každou další trasu v profilu, která číslo vynechá. Přečíst řádek zleva doprava stačí k tomu, abychom poznali, která hodnota kde platí.

route-metric je výchozí hodnota, ne pořadí

route-metric nastavuje záložní hodnotu pro trasy, které nenesou vlastní číslo. Nepovyšuje trasu nad nic jiného a nepřeřazuje trasy nainstalované s explicitními metrikami.

Tento rozdíl je důležitý, když profil míchá obě formy. Jediný řádek route-metric nahoře vypadá směrodatně a snadno se obviňuje, zatímco trasa, která provoz skutečně nese, může nést vlastní metriku o tři řádky níž.

Pokud chcete, aby jedna trasa preferovala cestu, dejte číslo na tuto trasu. Pokud chcete konzistentní výchozí hodnotu napříč generovaným profilem, použijte route-metric a jednotlivé řádky nechte být. Míchat obojí bez důvodu je způsob, jak profil skončí s trasou, kterou nikdo nedokáže vysvětlit.

Zkontrolujte, co klient nainstaloval

Po dokončení opětovného připojení se ptejte jádra, ne profilu.

ip route show vypisuje trasy, které klient přidal, a ip route get 172.20.5.10 odpovídá na užitečnější otázku: kterou trasu by toto cílové umístění skutečně použilo a s jakou zdrojovou adresou. Pokud v tabulce cíl chybí, klient ho nenainstaloval.

Místní direktiva, push ze serveru nebo jiný správce sítě mohou stejný prefix přidat nebo odebrat a vyhrává ten, kdo zapisuje poslední. Mějte trasu ke koncovému bodu na očích, protože připojení potřebuje cestu ke vzdálenému serveru, která nevede tunelem, který se právě staví.

Proč menší metrika stále prohrává

Metriky porovnávají trasy ke stejnému cíli. Nedělají široký prefix konkrétnějším. Když je ve hře redirect-gateway def1, klient nainstaluje 0.0.0.0/1 a 128.0.0.0/1 a tyto dva prefixy pokrývají celý prostor IPv4 konkrétněji než 0.0.0.0/0. Metrika 1 na výchozí trase je nepřekoná.

Stejná logika platí pro každou překrývající se dvojici. /24 porazí /16 pro adresu uvnitř něj bez ohledu na připojená čísla, protože vyhledávání nejprve zvolí nejkonkrétnější shodu a teprve potom porovná metriky mezi rovnými.

Tohle je ta část, která vypadá jako chyba metriky, ale není. Zkontrolujte délku prefixu u obou kandidátů, než změníte jakékoli číslo.

Pravidla zásad běží před tabulkou

V Linuxu ip rule rozhoduje, která směrovací tabulka se použije. Pravidla se vyhodnocují v pořadí priority, takže dřívější tabulka může vrátit trasu dřív, než se hlavní tabulka vůbec přečte. Metrika uvnitř main nemůže přebít shodu v tabulce, která byla použita první.

Použijte ip rule show a potom se zeptejte konkrétní tabulky, například ip route show table 100, abyste viděli, co by toto pravidlo vrátilo. Pokud pravidlo přidal klient VPN nebo běhové prostředí kontejneru, odpověď může být tam, ne v tabulce, kterou jste četli. Záleží i na zdrojové adrese, protože pravidlo může odpovídat zdroji a vyřešit stejný cíl jinak pro provoz tunelem a pro provoz v LAN.

Ověřte cíl, ne pořadí

Testem, který ukončí debatu, je jeden dotaz na hostitele v zamýšlené podsíti a kontrola zdrojové adresy, kterou jádro zvolilo. Pokud tato dvojice odpovídá návrhu, metrika dělá svou práci, i když výpis nevypadá jako čisté pořadí.

Nechte IPv6 a DNS mimo tuto kontrolu. Konfigurují se jinými direktivami a řeší jinými mechanismy a funkční trasa IPv4 o žádném z nich nic neříká. Měňte jednu vrstvu po druhé a dotaz zopakujte.