IPv6-beleidsroetering wanneer twee uplinks fe80::1 deel

Jy het twee uplinks, en ip -6 route show druk dieselfde volgende sprong op albei: default via fe80::1 dev uplink0 en default via fe80::1 dev uplink1. Dit is nie ’n konflik van dubbele adresse nie, en om die kaal volgende sprong fe80::1 in ’n beleidstabel te kopieer, sê nie vir die kern watter skakel jy bedoel nie. Die werklike vraag is smaller as wat die simptoom suggereer: het die tweede tabel een skakel of albei nodig, en wat hou daardie roetes ná ’n herbegin aan die lewe. Drie voorwaardes, in volgorde nagegaan, beslis die meeste daarvan.

Dieselfde fe80::1 is twee verskillende bure

Skakelplaaslike adresse is tot een skakel beperk, so fe80::1 is nie een adres wat twee keer gedruk word nie; dit is twee bure wat toevallig ’n agtervoegsel deel. Die sone-indeks is hoe ’n gasheer sê watter een hy bedoel, so fe80::1%uplink0 en fe80::1%uplink1 is verskillende bestemmings vir die kern, en daardie agtervoegsel reis nooit na ’n afgeleë roeteerder toe nie. RFC 4007 beskryf die sone-model hieragter, en dit is waarom ’n beleidstabel by elke skakelplaaslike volgende sprong ’n toestel moet dra.

’n VPN-konfigurasiegenerator wat ’n numeriese sone-ID van een gasheer na ’n sjabloon kopieer, behandel plaaslike konteks asof dit deel van die adres is, en die lêer wat hy skryf, is verkeerd op elke masjien wie se koppelvlakname of -indekse verskil. ’n Beleidstabel voeg ook nie twee skakels tot een saam nie: ’n geroteerde VPN laat pakkies tussen netwerke beweeg, maar dit dra nie die skakelplaaslike identiteit van ’n afgeleë Ethernet-buur oor die tonnel nie, so skakelplaaslike verkeer bly op sy eie skakel.

Verwyder die toestel en die roete word onskryfbaar. ip -6 route add default via fe80::1 table 200 kan nie die poort oplos nie, en iproute2 verwerp dit met Error: Nexthop has invalid gateway. Voeg dev uplink0 by en die opdrag slaag, want die toestel is wat die volgende sprong aan een van daardie twee bure vasspyker. Wat die toestel jou nie kan sê nie, is of uplink0 die regte skakel vir hierdie tabel is, en ’n roete wat van ’n ander gasheer gekopieer is, bring daardie gasheer se koppelvlakname saam, en dit is waar die regte foute vandaan kom.

Voorwaarde een: een skakel of twee in die tabel

Begin by waarvoor die tweede uplink is. As albei skakels dieselfde verkeer dra en een is ’n bystand, moet die alternatiewe tabel albei poorte met verskillende maatstawwe hou: dieselfde bestemmings, een voorkeurpad, een duidelike tweede keuse. As die uplinks bestaan omdat verskillende verkeer deur verskillende verskaffers moet vertrek, of omdat dit ’n gesplete tonnel is waar sommige verkeer die VPN omseil terwyl die res binne bly, hoort die twee skakels glad nie in een tabel nie. Hulle hoort in twee tabelle, gekies deur ’n reël, en die reël kies die tabel, nie die tonnel nie: verkeer wat omseil word, word gemerk voordat dit geroteer word, en die merk is wat dit na die tweede tabel stuur.

In daardie tweede geval besluit die reël wanneer ’n tabel geraadpleeg word, en die roete besluit waarheen die pakkie gaan sodra dit gebeur:

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

Nie een voorwerp vervang die ander nie, en ’n tabel met net ’n verstekroete kan steeds versuim om sy poort op te los. As ’n byvoeging verwerp word, of die roete teenwoordig maar onbruikbaar is, sit die gekoppelde voorvoegsel vir daardie koppelvlak in dieselfde tabel, of merk die sprong onlink wanneer daardie voorvoegsel elders geroteer word. In die blok hierbo staan 2001:db8:100::/48 in vir daardie gekoppelde voorvoegsel op uplink1, nie vir ’n willekeurige bestemming nie. Die fwmark-reël verbruik net ’n merk wat iets anders moet stel, uit ’n nftables- of iptables-reël op die aanstuurpad of uit SO_MARK op die sok, so ’n blok wat sonder ’n merk-bron gekopieer is, pas niks.

Voorwaarde twee: maatstawwe bespeur nie ’n dooie verskaffer nie

’n Maatstaf is ’n voorkeur tussen roetes wat bestaan, nie ’n gesondheidstoets nie. Wanneer die draer wegval, verwyder die kern die roetes op daardie toestel en die tweede verstekroete neem oor. Wanneer die kabel bly staan en die verskaffer daar agter sterf, verander niks in die tabel nie: die voorkeurroete is geïnstalleer, die buur is op laag 2 bereikbaar, en pakkies vertrek in ’n swart gat in. As daardie onderskeid vir jou opstelling saak maak, moet oorskakeling van iets kom wat die pad toets en die roete verwyder, of dit nou ’n roeteringsdaemon of ’n klein script is wat die inskrywing skrap en herinstalleer.

Verifieer die keuse nadat die tabel gebou is, en verifieer dit soos die kern dit sal sien. ip -6 route get 2001:db8:100::1 druk die roete wat gebruik sou word, insluitend die toestel en die gekose bronadres, en dit eerbiedig beleidsreëls. ’n Bronadres wat aan die verkeerde uplink behoort, is die gewone teken dat ’n reël vroeër as verwag gepas het.

Voorwaarde drie: besluit wie besit die volharding

’n Roete wat met ip -6 route add bygevoeg is, oorleef tot herbegin of tot iets dit uitvee. ’n Verstekroete wat uit roeteerderaankondigings geleer is, dra ’n leeftyd en kan deur die roeteerder teruggetrek word, terwyl ’n handmatig bygevoegde verstekroete nooit vanself verval nie. Om die twee in een tabel te meng, is hoe ’n verouderde permanente roete ’n vars aangekondigde een uiteindelik oortref, lank nadat die uplink wat hy beskryf het, opgehou bestaan het.

Kies een eienaar per tabel. As ’n netwerkbestuurder of roeteringsdaemon die koppelvlak al bestuur, beskryf die beleidsroete daar en los die kern alleen. As jy dit per script doen, maak die script idempotent en skryf die afbreek tegelyk, want jy sal dit nodig hê tydens die eerste slegte verandering:

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

Op ’n roeteerder wat vir ander gashere aanstuur, kyk eers na net.ipv6.conf.all.forwarding voordat jy die tabel blameer. Met aanstuur af word pakkies wat aan ’n ander netwerk gerig is, laat val, maak nie saak hoe korrek tabel 201 is nie.

Teken die ontwerp aan sodat die volgende persoon dit kan ouditeer

’n Inventaris wat net fe80::1 stoor, gooi die velde weg wat saak maak. Teken die bestemming, die volgende sprong, die toestel, die tabel en die maatstaf saam aan, plus waar elke roete vandaan kom, of dit aangekondig, deur ’n bestuurder gegenereer of staties is. Wanneer iemand later vra of die tweede uplink werklik verkeer dra, beantwoord daardie rekord die vraag sonder giswerk.

Voordat jy die tabel as klaar beskou, bevestig die buur met ip -6 neigh show dev uplink0, lees ip -6 rule show weer vir ordeningsongelukke, en toets met verkeer wat by die reël pas eerder as met ’n ping wat die verstekroete neem. Neem dan een uplink doelbewus af en kyk na watter roete die kern terugval; die antwoord moet by die een pas wat jy neergeskryf het.