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

Du har to oppkoblinger, og ip -6 route show skriver ut samme neste hopp på begge: default via fe80::1 dev uplink0 og default via fe80::1 dev uplink1. Det er ikke en konflikt med dupliserte adresser, og å kopiere det nakne neste hoppet fe80::1 inn i en policy-tabell forteller ikke kjernen hvilken lenke du mente. Det egentlige spørsmålet er smalere enn symptomet antyder: trenger den andre tabellen én lenke eller begge, og hva holder disse rutene i live etter en omstart. Tre forhold, kontrollert i rekkefølge, avgjør det meste.

Samme fe80::1 er to forskjellige naboer

Link-local-adresser er begrenset til én enkelt lenke, så fe80::1 er ikke én adresse skrevet ut to ganger; det er to naboer som tilfeldigvis deler et suffiks. Sonenindeksen er hvordan en vert sier hvilken av dem den mener, så fe80::1%uplink0 og fe80::1%uplink1 er forskjellige destinasjoner for kjernen, og det suffikset reiser aldri til en ekstern ruter. RFC 4007 beskriver sonemodellen bak dette, og det er derfor en policy-tabell må bære en enhet med hvert link-local neste hopp.

En VPN-konfigurasjonsgenerator som kopierer en numerisk sone-ID fra én vert inn i en mal, behandler lokal kontekst som om den var en del av adressen, og filen den skriver er feil på hver maskin der grensesnittnavnene eller indeksene er forskjellige. En policy-tabell slår heller ikke sammen to lenker til én: en rutet VPN sender pakker mellom nettverk, men den bærer ikke en ekstern Ethernetnabos link-local-identitet gjennom tunnelen, så link-local-trafikk blir på sin egen lenke.

Fjern enheten, og ruten blir uskrivbar. ip -6 route add default via fe80::1 table 200 kan ikke slå opp gatewayen, og iproute2 avviser den med Error: Nexthop has invalid gateway. Legg til dev uplink0 og kommandoen lykkes, fordi det er enheten som fester neste hopp til en av de to naboene. Det enheten ikke kan fortelle deg, er om uplink0 er riktig lenke for denne tabellen, og en rute kopiert fra en annen vert tar med seg den vertens grensesnittnavn, og det er der de virkelige feilene kommer fra.

Forhold én: én lenke eller to i tabellen

Start med hva den andre oppkoblingen er til. Hvis begge lenkene bærer samme trafikk og én er reserve, bør den alternative tabellen holde begge gatewayene med forskjellige metrikker: samme destinasjoner, én foretrukket vei, ett åpenbart andrevalg. Hvis oppkoblingene finnes fordi forskjellig trafikk må gå ut gjennom forskjellige leverandører, eller fordi dette er en split tunnel der noe trafikk går utenom VPN-en mens resten blir inne, hører de to lenkene ikke i én tabell i det hele tatt. De hører i to tabeller, valgt av en regel, og regelen velger tabellen, ikke tunnelen: trafikk som skal utenom, merkes før den rutes, og merket er det som sender den til den andre tabellen.

I det andre tilfellet avgjør regelen når en tabell konsulteres, og ruten avgjør hvor pakken går når den 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 objektene erstatter det andre, og en tabell som bare holder en standardrute kan fortsatt mislykkes i å slå opp gatewayen. Hvis en add blir avvist, eller ruten finnes men er ubrukelig, legg det tilkoblede prefikset for det grensesnittet i samme tabell, eller merk hoppet onlink når det prefikset rutes andre steder. I blokken over står 2001:db8:100::/48 for det tilkoblede prefikset på uplink1, ikke for en vilkårlig destinasjon. fwmark-regelen bruker bare et merke som noe annet må sette, fra en nftables- eller iptables-regel på videresendingsveien eller fra SO_MARK på sockelen, så en blokk kopiert uten en merkekilde matcher ingenting.

Forhold to: metrikker oppdager ikke en død leverandør

En metrikk er en preferanse blant ruter som finnes, ikke en helsesjekk. Når bæreren faller, fjerner kjernen rutene på den enheten og den andre standardruten overtar. Når kabelen blir oppe og leverandøren bak den dør, endres ingenting i tabellen: den foretrukne ruten er installert, naboen er nåbar på lag 2, og pakkene forsvinner inn i et svart hull. Hvis den forskjellen betyr noe for oppsettet ditt, må failover komme fra noe som sonderer veien og fjerner ruten, enten det er en ruterdemon eller et lite skript som sletter og installerer oppføringen på nytt.

Kontroller valget etter at tabellen er bygget, og kontroller det slik kjernen vil se det. ip -6 route get 2001:db8:100::1 skriver ut ruten som ville bli brukt, inkludert enheten og den valgte kildeadressen, og den respekterer policy-regler. En kildeadresse som hører til feil oppkobling er det vanlige tegnet på at en regel matchet tidligere enn du forventet.

Forhold tre: avgjør hvem som eier persistensen

En rute lagt til med ip -6 route add overlever til omstart eller til noe tømmer den. En standardrute lært fra ruterannonser har en levetid og kan trekkes tilbake av ruteren, mens en manuelt lagt til standardrute aldri utløper av seg selv. Å blande de to i én tabell er hvordan en gammel permanent rute ender opp med å rangere over en fersk annonsert en, lenge etter at oppkoblingen den beskrev sluttet å finnes.

Velg én eier per tabell. Hvis en nettverksbehandler eller ruterdemon allerede styrer grensesnittet, beskriv policy-ruten der og la kjernen være i fred. Hvis du skripting det, gjør skriptet idempotent og skriv nedrivingen samtidig, fordi du trenger den ved den første dårlige endringen:

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

På en ruter som videresender for andre verter, sjekk net.ipv6.conf.all.forwarding før du gir tabellen skylden. Med videresending av, blir pakker adressert til et annet nettverk droppet uansett hvor riktig tabell 201 er.

Dokumenter designet så neste person kan revidere det

En oversikt som bare lagrer fe80::1 kaster bort feltene som betyr noe. Registrer destinasjonen, neste hopp, enheten, tabellen og metrikken sammen, pluss hvor hver rute kom fra, om den er annonsert, generert av behandleren eller statisk. Når noen senere spør om den andre oppkoblingen faktisk bærer trafikk, svarer den oversikten uten gjetting.

Før du kaller tabellen ferdig, bekreft naboen med ip -6 neigh show dev uplink0, les ip -6 rule show på nytt for rekkefølgeuhell, og test med trafikk som matcher regelen i stedet for en ping som tar standardruten. Ta så en oppkobling ned med vilje og se hvilken rute kjernen faller tilbake til; svaret bør stemme med det du skrev ned.