Máte dva uplinky a ip -6 route show vypisuje stejný další skok na obou: default via fe80::1 dev uplink0 a default via fe80::1 dev uplink1. To není konflikt duplicitních adres a zkopírování holého dalšího skoku fe80::1 do tabulky zásad kernelu neřekne, kterou linku jste mysleli. Skutečná otázka je užší, než symptom naznačuje: potřebuje druhá tabulka jednu linku, nebo obě, a co tyto trasy udrží živé po restartu. Tři podmínky, ověřené v pořadí, vyřeší většinu.

Stejné fe80::1 jsou dva různí sousedé

Link-local adresy jsou omezené na jednu linku, takže fe80::1 není jedna adresa vytištěná dvakrát; jsou to dva sousedé, kteří náhodou sdílejí sufix. Index zóny je způsob, jakým host řekne, kterou myslí, takže fe80::1%uplink0 a fe80::1%uplink1 jsou pro kernel různá cíle a tento sufix nikdy necestuje k vzdálenému routeru. RFC 4007 popisuje model zón, který za tím stojí, a proto musí tabulka zásad nést zařízení u každého link-local dalšího skoku.

Generátor konfigurace VPN, který kopíruje číselné ID zóny z jednoho hostu do šablony, zachází s lokálním kontextem, jako by byl součástí adresy, a soubor, který zapíše, je špatný na každém stroji, jehož názvy nebo indexy rozhraní se liší. Tabulka zásad také neslévá dvě linky do jedné: směrovaná VPN přenáší pakety mezi sítěmi, ale nepřenáší link-local identitu vzdáleného Ethernet souseda tunelem, takže link-local provoz zůstává na své lince.

Odeberte zařízení a trasa se stane nezapisovatelnou. ip -6 route add default via fe80::1 table 200 nedokáže přeložit bránu a iproute2 ji odmítne s Error: Nexthop has invalid gateway. Přidejte dev uplink0 a příkaz uspěje, protože zařízení je to, co připne další skok k jednomu z těch dvou sousedů. Co vám zařízení nemůže říct, je, zda je uplink0 správná linka pro tuto tabulku, a trasa zkopírovaná z jiného hostu s sebou přináší názvy rozhraní onoho hostu, a odtud pramení skutečné chyby.

Podmínka jedna: jedna linka, nebo dvě v tabulce

Začněte tím, k čemu druhý uplink je. Pokud obě linky nesou stejný provoz a jedna je záložní, alternativní tabulka má držet obě brány s odlišnými metrikami: stejné cíle, jedna preferovaná cesta, jedna zřejmá druhá volba. Pokud uplinky existují proto, že různý provoz musí odcházet přes různé poskytovatele, nebo protože jde o rozdělený tunel, kde část provozu obchází VPN a zbytek zůstává uvnitř, dvě linky do jedné tabulky vůbec nepatří. Patří do dvou tabulek volených pravidlem a pravidlo volí tabulku, ne tunel: obcházející provoz se značí před směrováním a značka je to, co ho pošle do druhé tabulky.

V druhém případě pravidlo rozhoduje, kdy se tabulka konzultuje, a trasa rozhoduje, kam paket po té jde:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Ani jeden objekt nenahrazuje druhý a tabulka s pouhou výchozí trasou může stále selhat při překladu své brány. Pokud je přidání odmítnuto nebo je trasa přítomná, ale nepoužitelná, vložte připojený prefix onoho rozhraní do stejné tabulky, nebo označte skok onlink, když je tento prefix směrován jinam. V bloku výše 2001:db8:100::/48 zastupuje právě tento připojený prefix na uplink1, ne libovolné cíle. Pravidlo fwmark spotřebovává jen značku, kterou musí nastavit něco jiného, z pravidla nftables nebo iptables na předávací cestě nebo z SO_MARK na socketu, takže blok zkopírovaný bez zdroje značky neodpovídá ničemu.

Podmínka druhá: metriky neodhalí mrtvého poskytovatele

Metrika je preference mezi trasami, které existují, ne zdravotní kontrola. Když nosič vypadne, kernel odstraní trasy na onom zařízení a druhá výchozí trasa převezme. Když kabel zůstane zapojený a poskytovatel za ním umře, v tabulce se nic nemění: preferovaná trasa je nainstalovaná, soused je dostupný na vrstvě 2 a pakety odcházejí do černé díry. Pokud na tomto rozdílu záleží, failover musí přijít od něčeho, co sonduje cestu a trasu odstraní, ať už je to směrovací démon nebo malý skript, který záznam smaže a znovu nainstaluje.

Ověřte volbu poté, co je tabulka postavena, a ověřte ji tak, jak ji uvidí kernel. ip -6 route get 2001:db8:100::1 vypíše trasu, která by se použila, včetně zařízení a zvolené zdrojové adresy, a respektuje pravidla zásad. Zdrojová adresa patřící špatnému uplinku je obvyklým znamením, že pravidlo odpovídalo dřív, než jste čekali.

Podmínka třetí: rozhodněte, kdo vlastní trvalost

Trasa přidaná pomocí ip -6 route add přežije do restartu nebo dokud ji něco nesmaže. Výchozí trasa naučená z reklam routeru nese životnost a router ji může stáhnout, zatímco ručně přidaná výchozí trasa sama nikdy nevyprší. Míchání obojího v jedné tabulce je způsob, jak zastaralá trvalá trasa začne převažovat nad čerstvě inzerovanou, dlouho poté, co linka, kterou popisovala, přestala existovat.

Zvolte jednoho vlastníka na tabulku. Pokud síťový manažer nebo směrovací démon už rozhraní spravuje, popište trasu zásad tam a kernel nechte na pokoji. Pokud to skriptujete, udělejte skript idempotentní a napište demontáž zároveň, protože ji budete potřebovat při první špatné změně:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Na routeru, který předává za jiné hosty, zkontrolujte net.ipv6.conf.all.forwarding, než obviníte tabulku. S vypnutým předáváním se pakety adresované jiné síti zahazují, ať je tabulka 201 jakkoli správná.

Zaznamenejte návrh, aby ho příští člověk mohl auditovat

Inventář, který ukládá jen fe80::1, vyhazuje pole, na kterých záleží. Zaznamenejte cíl, další skok, zařízení, tabulku a metriku společně, plus odkud každá trasa přišla — inzerovaná, generovaná správcem nebo statická. Když se někdo později zeptá, zda druhý uplink skutečně nese provoz, tento záznam odpoví bez hádání.

Než tabulku prohlásíte za hotovou, potvrďte souseda pomocí ip -6 neigh show dev uplink0, znovu si přečtěte ip -6 rule show kvůli nehodám v pořadí a testujte provozem, který odpovídá pravidlu, místo pingem, který jde výchozí trasou. Pak jeden uplink schválně shodte a sledujte, na kterou trasu se kernel vrátí; odpověď má odpovídat té, kterou jste zapsali.

Související články