IPv6-policyrutering når to oppkoplingar deler fe80::1

Du har to oppkoplingar, og ip -6 route show skriv ut same neste hopp på begge: default via fe80::1 dev uplink0 og default via fe80::1 dev uplink1. Det er ikkje ein konflikt med dupliserte adresser, og å kopiere det nakne neste hoppet fe80::1 inn i ein policy-tabell fortel ikkje kjernen kva lenkje du meinte. Det eigentlege spørsmålet er smalare enn symptomet antydar: treng den andre tabellen éi lenkje eller begge, og kva held desse rutene i live etter ein omstart. Tre vilkår, kontrollerte i rekkjefølgje, avgjer det meste.

Same fe80::1 er to ulike naboar

Link-local-adresser er avgrensa til éi einskild lenkje, så fe80::1 er ikkje éi adresse skriven ut to gonger; det er to naboar som tilfeldigvis deler eit suffiks. Soneindeksen er korleis ein vert seier kva av dei han meiner, så fe80::1%uplink0 og fe80::1%uplink1 er ulike destinasjonar for kjernen, og det suffikset reiser aldri til ein ekstern ruter. RFC 4007 skildrar sonemodellen bak dette, og det er derfor ein policy-tabell må bera ei eining med kvart link-local neste hopp.

Ein VPN-konfigurasjonsgenerator som kopierer ein numerisk sone-ID frå éin vert inn i ein mal, handsamar lokal kontekst som om han var ein del av adressa, og fila han skriv er feil på kvar maskin der grensesnittnamna eller indeksane er ulike. Ein policy-tabell slår heller ikkje saman to lenkjer til éi: ein ruta VPN sender pakkar mellom nettverk, men han ber ikkje ein ekstern Ethernetnabbos link-local-identitet gjennom tunnelen, så link-local-trafikk blir på si eiga lenkje.

Fjern eininga, og ruta blir uskriveleg. ip -6 route add default via fe80::1 table 200 kan ikkje slå opp gatewayen, og iproute2 avviser han med Error: Nexthop has invalid gateway. Legg til dev uplink0 og kommandoen lukkast, fordi det er eininga som festar neste hopp til ein av dei to naboane. Det eininga ikkje kan fortelje deg, er om uplink0 er rett lenkje for denne tabellen, og ei rute kopiert frå ein annan vert tek med seg grensesnittnamna til den verten, og det er der dei verkelege feila kjem frå.

Vilkår éin: éi lenkje eller to i tabellen

Byrja med kva den andre oppkoplinga er til. Viss begge lenkjene ber same trafikk og éi er reserve, bør den alternative tabellen halde begge gatewayane med ulike metrikkar: same destinasjonar, éin føretrekt veg, eitt openbert andreval. Viss oppkoplingane finst fordi ulik trafikk må ut gjennom ulike leverandørar, eller fordi dette er ein split tunnel der noko trafikk går utanom VPN-en medan resten blir inne, høyrer dei to lenkjene ikkje i éin tabell i det heile. Dei høyrer i to tabellar, valde av ein regel, og regelen vel tabellen, ikkje tunnelen: trafikk som skal utanom, blir merkt før han blir ruta, og merket er det som sender han til den andre tabellen.

I det andre tilfellet avgjer regelen når ein tabell blir konsultert, og ruta avgjer kvar pakken går når han er det:

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

Ingen av objekta erstattar det andre, og ein tabell som berre held ei standardrute kan framleis mislukkast i å slå opp gatewayen. Viss ein add blir avvist, eller ruta finst men er ubrukeleg, legg det tilkopla prefikset for det grensesnittet i same tabell, eller merk hoppet onlink når det prefikset blir ruta andre stader. I blokka over står 2001:db8:100::/48 for det tilkopla prefikset på uplink1, ikkje for ein vilkårleg destinasjon. fwmark-regelen brukar berre eit merke som noko anna må setje, frå ein nftables- eller iptables-regel på videresendingsvegen eller frå SO_MARK på sockelen, så ei blokk kopiert utan ei merkjekjelde matchar ingenting.

Vilkår to: metrikkar oppdagar ikkje ein daud leverandør

Ein metrikk er ei preferanse blant ruter som finst, ikkje ein helsesjekk. Når beraren fell, fjernar kjernen rutene på den eininga og den andre standardruta overtek. Når kabelen blir oppe og leverandøren bak han døyr, blir ingenting endra i tabellen: den føretrekte ruta er installert, naboen er nåbar på lag 2, og pakkane forsvinn inn i eit svart hol. Viss den skilnaden betyr noko for oppsettet ditt, må failover kome frå noko som sonderer vegen og fjernar ruta, anten det er ein ruterdemon eller eit lite skript som slettar og installerer oppføringa på nytt.

Kontroller valet etter at tabellen er bygd, og kontroller det slik kjernen vil sjå det. ip -6 route get 2001:db8:100::1 skriv ut ruta som ville bli brukt, inkludert eininga og den valde kildeadressa, og ho respekterer policy-reglar. Ei kildeadresse som høyrer til feil oppkopling er det vanlege teiknet på at ein regel matcha tidlegare enn du venta.

Vilkår tre: avgjer kven som eig persistensen

Ei rute lagd til med ip -6 route add overlever til omstart eller til noko tømmer ho. Ei standardrute lært frå ruterannonsar har ei levetid og kan trekkjast tilbake av ruteren, medan ei manuelt lagd standardrute aldri går ut av seg sjølv. Å blande dei to i éin tabell er korleis ei gammal permanent rute endar med å rangere over ei fersk annonsert ei, lenge etter at oppkoplinga ho skildra slutta å finnast.

Vel éin eigar per tabell. Viss ein nettverkshandsamar eller ruterdemon allereie styrer grensesnittet, skildre policy-ruta der og lat kjernen vere i fred. Viss du skriptar det, gjer skriptet idempotent og skriv nedrivinga samstundes, fordi du treng ho ved den første dårlege endringa:

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

På ein ruter som videresender for andre vertar, sjekk net.ipv6.conf.all.forwarding før du gir tabellen skulda. Med videresending av, blir pakkar adresserte til eit anna nettverk droppa uansett kor riktig tabell 201 er.

Dokumenter designet så neste person kan revidere det

Ei oversikt som berre lagrar fe80::1 kastar bort felta som betyr noko. Registrer destinasjonen, neste hopp, eininga, tabellen og metrikken saman, pluss kvar kvar rute kom frå, om ho er annonsert, generert av handsamaren eller statisk. Når nokon seinare spør om den andre oppkoplinga faktisk ber trafikk, svarer den oversikta utan gissing.

Før du kallar tabellen ferdig, stadfest naboen med ip -6 neigh show dev uplink0, les ip -6 rule show på nytt for rekkjefølgjeuhell, og test med trafikk som matchar regelen i staden for ein ping som tek standardruta. Ta så éi oppkopling ned med vilje og sjå kva rute kjernen fell tilbake til; svaret bør stemme med det du skreiv ned.