IPv6-policyrouting wanneer twee uplinks fe80::1 delen

Je hebt twee uplinks, en ip -6 route show toont dezelfde next hop op beide: default via fe80::1 dev uplink0 en default via fe80::1 dev uplink1. Dat is geen conflict met dubbele adressen, en het kale next hop-adres fe80::1 in een policy-tabel kopiëren vertelt de kernel niet welke link je bedoelde. De echte vraag is smaller dan het symptoom suggereert: heeft de tweede tabel één link of beide nodig, en wat houdt die routes in leven na een herstart. Drie voorwaarden, in volgorde gecontroleerd, beslechten het meeste.

Dezelfde fe80::1 zijn twee verschillende buren

Link-local adressen zijn beperkt tot één link, dus fe80::1 is niet één adres dat twee keer wordt getoond; het zijn twee buren die toevallig een suffix delen. De zone-index is hoe een host zegt welke hij bedoelt, dus fe80::1%uplink0 en fe80::1%uplink1 zijn verschillende bestemmingen voor de kernel, en dat suffix reist nooit naar een externe router. RFC 4007 beschrijft het zonemodel hierachter, en daarom moet een policy-tabel bij elke link-local next hop een apparaat meedragen.

Een VPN-configuratiegenerator die een numerieke zone-ID van de ene host in een sjabloon kopieert, behandelt lokale context alsof die deel van het adres is, en het bestand dat hij schrijft is fout op elke machine waarvan de interfacenamen of -indexen verschillen. Een policy-tabel voegt ook geen twee links samen tot één: een gerouteerde VPN geeft pakketten door tussen netwerken, maar draagt de link-local identiteit van een externe Ethernet-buur niet door de tunnel, dus link-local verkeer blijft op zijn eigen link.

Verwijder het apparaat en de route wordt onschrijfbaar. ip -6 route add default via fe80::1 table 200 kan de gateway niet vinden, en iproute2 weigert het met Error: Nexthop has invalid gateway. Voeg dev uplink0 toe en het commando slaagt, omdat het apparaat de next hop aan een van die twee buren vastzet. Wat het apparaat je niet kan vertellen, is of uplink0 de juiste link voor deze tabel is, en een route die van een andere host is gekopieerd neemt de interfacenamen van die host mee, en daar komen de echte fouten vandaan.

Voorwaarde één: één link of twee in de tabel

Begin met waarvoor de tweede uplink dient. Als beide links hetzelfde verkeer dragen en één is een standby, moet de alternatieve tabel beide gateways met verschillende metrische waarden bevatten: dezelfde bestemmingen, één voorkeurspad, één duidelijke tweede keuze. Als de uplinks bestaan omdat verschillend verkeer via verschillende providers naar buiten moet, of omdat dit een split tunnel is waarbij een deel van het verkeer de VPN omzeilt terwijl de rest binnen blijft, horen de twee links helemaal niet in één tabel. Ze horen in twee tabellen, gekozen door een regel, en de regel kiest de tabel, niet de tunnel: verkeer dat omzeilt wordt gemarkeerd voordat het wordt gerouteerd, en de markering is wat het naar de tweede tabel stuurt.

In het tweede geval bepaalt de regel wanneer een tabel wordt geraadpleegd, en de route bepaalt waar het pakket heen gaat zodra dat gebeurt:

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

Geen van beide objecten vervangt het andere, en een tabel met alleen een default kan nog steeds de gateway niet vinden. Als een add wordt geweigerd, of de route bestaat maar is onbruikbaar, zet dan het connected prefix voor die interface in dezelfde tabel, of markeer de hop onlink wanneer dat prefix elders wordt gerouteerd. In het blok hierboven staat 2001:db8:100::/48 voor dat connected prefix op uplink1, niet voor een willekeurige bestemming. De fwmark-regel verbruikt alleen een markering die iets anders moet zetten, vanuit een nftables- of iptables-regel op het doorstuurpad of vanuit SO_MARK op de socket, dus een blok dat zonder markeringsbron is gekopieerd, matcht niets.

Voorwaarde twee: metrische waarden detecteren geen dode provider

Een metrische waarde is een voorkeur tussen routes die bestaan, geen gezondheidscheck. Als de carrier wegvalt, verwijdert de kernel de routes op dat apparaat en neemt de tweede default het over. Als de kabel blijft liggen en de provider erachter sterft, verandert er niets in de tabel: de voorkeursroute is geïnstalleerd, de buur is op laag 2 bereikbaar, en de pakketten verdwijnen in een zwart gat. Als dat onderscheid voor jouw opstelling uitmaakt, moet failover komen van iets dat het pad peilt en de route verwijdert, of dat nu een routing-daemon is of een klein script dat de entry verwijdert en opnieuw installeert.

Verifieer de keuze nadat de tabel is gebouwd, en verifieer die zoals de kernel hem zal zien. ip -6 route get 2001:db8:100::1 toont de route die zou worden gebruikt, inclusief het apparaat en het geselecteerde bronadres, en respecteert policy-regels. Een bronadres dat bij de verkeerde uplink hoort, is het gebruikelijke teken dat een regel eerder matchte dan je verwachtte.

Voorwaarde drie: bepaal wie de persistentie bezit

Een route die met ip -6 route add is toegevoegd, overleeft tot een herstart of tot iets hem wist. Een default die uit router-advertenties is geleerd, heeft een levensduur en kan door de router worden ingetrokken, terwijl een handmatig toegevoegde default nooit vanzelf verloopt. De twee in één tabel mengen is hoe een verouderde permanente route een verse geadverteerde gaat overstemmen, lang nadat de uplink die hij beschreef ophield te bestaan.

Kies één eigenaar per tabel. Als een netwerkbeheerder of routing-daemon de interface al beheert, beschrijf de policy-route daar en laat de kernel met rust. Als je het script, maak het script idempotent en schrijf de teardown tegelijk, want je hebt hem nodig bij de eerste slechte wijziging:

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

Controleer op een router die voor andere hosts doorstuurt net.ipv6.conf.all.forwarding voordat je de tabel de schuld geeft. Met doorsturen uit worden pakketten die aan een ander netwerk zijn geadresseerd, gedropt, hoe correct tabel 201 ook is.

Leg het ontwerp vast zodat de volgende persoon het kan auditen

Een inventaris die alleen fe80::1 opslaat, gooit de velden weg die ertoe doen. Leg de bestemming, de next hop, het apparaat, de tabel en de metrische waarde samen vast, plus waar elke route vandaan kwam, of die geadverteerd, door de beheerder gegenereerd of statisch is. Als iemand later vraagt of de tweede uplink echt verkeer draagt, beantwoordt dat record de vraag zonder giswerk.

Voordat je de tabel af noemt, bevestig de buur met ip -6 neigh show dev uplink0, lees ip -6 rule show opnieuw voor volgordefouten, en test met verkeer dat bij de regel past in plaats van een ping die de defaultroute neemt. Haal dan met opzet één uplink neer en kijk naar welke route de kernel terugvalt; het antwoord zou moeten kloppen met wat je hebt opgeschreven.