IPv6-policy-routing når to uplinks deler fe80::1

Du har to uplinks, og ip -6 route show viser samme næste hop på begge: default via fe80::1 dev uplink0 og default via fe80::1 dev uplink1. Det er ikke en konflikt med dublerede adresser, og at kopiere det nøgne næste hop fe80::1 ind i en policytabel fortæller ikke kernen, hvilket link du mener. Det egentlige spørgsmål er snævrere, end symptomet antyder: har den anden tabel brug for ét link eller begge, og hvad holder de ruter i live efter en genstart. Tre betingelser, kontrolleret i rækkefølge, afgør det meste.

Det samme fe80::1 er to forskellige naboer

Link-local-adresser er begrænset til ét link, så fe80::1 er ikke én adresse trykt to gange; det er to naboer, der tilfældigvis deler et suffix. Zoneindekset er, hvordan en vært siger, hvilken den mener, så fe80::1%uplink0 og fe80::1%uplink1 er forskellige destinationer for kernen, og det suffix rejser aldrig til en fjern router. RFC 4007 beskriver zonemodellen bag dette, og derfor skal en policytabel bære en enhed med hvert link-local næste hop.

En VPN-konfigurationsgenerator, der kopierer et numerisk zone-ID fra én vært ind i en skabelon, behandler lokal kontekst, som om den var en del af adressen, og den fil, den skriver, er forkert på enhver maskine, hvis grænsefladenavne eller -indekser er forskellige. En policytabel smelter heller ikke to links til ét: en routet VPN sender pakker mellem netværk, men den bærer ikke en fjern Ethernet-nabos link-local-identitet gennem tunnelen, så link-local-trafik bliver på sit eget link.

Fjern enheden, og ruten bliver ubeskrivelig. ip -6 route add default via fe80::1 table 200 kan ikke opløse gatewayen, og iproute2 afviser den med Error: Nexthop has invalid gateway. Tilføj dev uplink0 og kommandoen lykkes, fordi enheden er det, der fastgør næste hop til en af de to naboer. Det, enheden ikke kan fortælle dig, er, om uplink0 er det rigtige link til denne tabel, og en rute kopieret fra en anden vært bringer den værtes grænsefladenavne med sig, og det er der, de rigtige fejl kommer fra.

Betingelse et: ét link eller to i tabellen

Begynd med, hvad det andet uplink er til. Hvis begge links bærer samme trafik, og det ene er standby, bør den alternative tabel holde begge gateways med forskellige metrikker: samme destinationer, én foretrukken vej, ét oplagt andetvalg. Hvis uplinkene findes, fordi forskellig trafik skal ud gennem forskellige udbydere, eller fordi det er en splittet tunnel, hvor noget trafik går uden om VPN, mens resten bliver inde, hører de to links slet ikke i én tabel. De hører i to tabeller, valgt af en regel, og reglen vælger tabellen, ikke tunnelen: trafik, der går uden om, markeres, før den routes, og markeringen er det, der sender den til den anden tabel.

I det andet tilfælde afgør reglen, hvornår en tabel bliver spurgt, og ruten afgør, hvor pakken går hen bagefter:

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 af objekterne erstatter det andet, og en tabel, der kun holder en standardrute, kan stadig fejle med at opløse sin gateway. Hvis en tilføjelse afvises, eller ruten findes, men er ubrugelig, skal du sætte det forbundne præfiks for den grænseflade i samme tabel, eller markere hoppet onlink, når præfikset routes et andet sted. I blokken ovenfor står 2001:db8:100::/48 for netop det forbundne præfiks på uplink1, ikke for en vilkårlig destination. Fwmark-reglen forbruger kun et mærke, som noget andet skal sætte, fra en nftables- eller iptables-regel på videresendelsesvejen eller fra SO_MARK på socket'en, så en blok kopieret uden en mærkekilde matcher intet.

Betingelse to: metrikker opdager ikke en død udbyder

En metrik er en præference blandt ruter, der findes, ikke et sundhedstjek. Når bæreren falder, fjerner kernen ruterne på den enhed, og den anden standardrute overtager. Når kablet bliver siddende, og udbyderen bagved dør, ændrer intet sig i tabellen: den foretrukne rute er installeret, naboen kan nås på lag 2, og pakkerne forsvinder i et sort hul. Hvis den forskel betyder noget for din opsætning, skal failover komme fra noget, der tester vejen og fjerner ruten, hvad enten det er en routingdaemon eller et lille script, der sletter og geninstallerer posten.

Verificér valget, efter tabellen er bygget, og verificér det, som kernen vil se det. ip -6 route get 2001:db8:100::1 udskriver den rute, der ville blive brugt, inklusive enheden og den valgte kildeadresse, og den respekterer politikregler. En kildeadresse, der tilhører det forkerte uplink, er det sædvanlige tegn på, at en regel matchede tidligere, end du forventede.

Betingelse tre: beslut, hvem der ejer vedvarende tilstand

En rute tilføjet med ip -6 route add overlever til genstart eller indtil noget skylle den ud. En standardrute lært fra routerannoncer bærer en levetid og kan trækkes tilbage af routeren, mens en manuelt tilføjet standardrute aldrig udløber af sig selv. At blande de to i én tabel er, hvordan en forældet permanent rute ender med at overgå en frisk annonceret, længe efter det uplink, den beskrev, holdt op med at eksistere.

Vælg én ejer per tabel. Hvis en netværksmanager eller routingdaemon allerede administrerer grænsefladen, beskriv politikruten der, og lad kernen være. Hvis du script'er det, gør scriptet idempotent, og skriv nedrivningen samtidig, for du får brug for den under den første dårlige ændring:

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

På en router, der videresender for andre værter, skal du tjekke net.ipv6.conf.all.forwarding, før du bebrejder tabellen. Med videresendelse slået fra bliver pakker, der er adresseret til et andet netværk, droppet, uanset hvor korrekt tabel 201 er.

Notér designet, så den næste person kan revidere det

En fortegnelse, der kun gemmer fe80::1, smider de felter væk, der betyder noget. Notér destinationen, næste hop, enheden, tabellen og metrikken sammen, plus hvor hver rute kom fra — annonceret, manager-genereret eller statisk. Når nogen senere spørger, om det andet uplink faktisk bærer trafik, besvarer den fortegnelse spørgsmålet uden gætværk.

Før du kalder tabellen færdig, bekræft naboen med ip -6 neigh show dev uplink0, genlæs ip -6 rule show for rækkefølgeuheld, og test med trafik, der matcher reglen, i stedet for en ping, der tager standardruten. Tag derefter et uplink ned med vilje, og se, hvilken rute kernen falder tilbage til; svaret bør matche det, du skrev ned.