Encaminament de polítiques IPv6 quan dos enllaços ascendents comparteixen fe80::1

Teniu dos enllaços ascendents, i ip -6 route show mostra el mateix següent salt en tots dos: default via fe80::1 dev uplink0 i default via fe80::1 dev uplink1. No és un conflicte d'adreces duplicades, i copiar el següent salt nu fe80::1 en una taula de polítiques no diu al nucli quin enllaç volíeu. La pregunta real és més estreta del que suggereix el símptoma: la segona taula necessita un enllaç o tots dos, i què manté vives aquestes rutes després d'un reinici. Tres condicions, comprovades per ordre, resolen la major part.

El mateix fe80::1 són dos veïns diferents

Les adreces link-local estan limitades a un sol enllaç, així que fe80::1 no és una adreça impresa dues vegades; són dos veïns que casualment comparteixen un sufix. L'índex de zona és com un host diu quin vol dir, així que fe80::1%uplink0 i fe80::1%uplink1 són destinacions diferents per al nucli, i aquest sufix mai viatja fins a un encaminador remot. RFC 4007 descriu el model de zones que hi ha darrere, i per això una taula de polítiques ha de portar un dispositiu amb cada següent salt link-local.

Un generador de configuració VPN que copia un ID de zona numèric d'un host a una plantilla tracta el context local com si fos part de l'adreça, i el fitxer que escriu és incorrecte a cada màquina els noms o índexs d'interfície de la qual difereixen. Una taula de polítiques tampoc fusiona dos enllaços en un: una VPN encaminada passa paquets entre xarxes, però no transporta la identitat link-local d'un veí Ethernet remot a través del túnel, així que el trànsit link-local es queda al seu enllaç.

Traieu el dispositiu i la ruta es torna no escribible. ip -6 route add default via fe80::1 table 200 no pot resoldre la passarel·la, i iproute2 la rebutja amb Error: Nexthop has invalid gateway. Afegiu dev uplink0 i l'ordre s'executa, perquè el dispositiu és el que fixa el següent salt a un d'aquests dos veïns. El que el dispositiu no us pot dir és si uplink0 és l'enllaç correcte per a aquesta taula, i una ruta copiada d'un altre host porta els noms d'interfície d'aquell host, i d'aquí vénen els errors reals.

Condició u: un enllaç o dos a la taula

Comenceu per a què serveix el segon enllaç ascendent. Si tots dos enllaços porten el mateix trànsit i un és d'espera, la taula alternativa ha de contenir les dues passarel·les amb mètriques diferents: mateixos destinacions, un camí preferit, una segona opció òbvia. Si els enllaços existeixen perquè trànsit diferent ha de sortir per proveïdors diferents, o perquè és un túnel dividit on part del trànsit evita la VPN mentre la resta es queda a dins, els dos enllaços no pertanyen gens a una sola taula. Pertanyen a dues taules, triades per una regla, i la regla tria la taula, no el túnel: el trànsit que evita es marca abans d'encaminar-se, i la marca és el que l'envia a la segona taula.

En aquest segon cas la regla decideix quan es consulta una taula, i la ruta decideix on va el paquet un cop ho fa:

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

Cap dels dos objectes substitueix l'altre, i una taula que només conté una ruta per defecte encara pot fallar a resoldre la seva passarel·la. Si es rebutja una addició, o la ruta hi és però és inutilitzable, poseu el prefix connectat d'aquesta interfície a la mateixa taula, o marqueu el salt onlink quan aquest prefix s'encamina en un altre lloc. Al bloc de dalt 2001:db8:100::/48 representa aquest prefix connectat a uplink1, no una destinació arbitrària. La regla fwmark només consumeix una marca que una altra cosa ha de posar, des d'una regla nftables o iptables al camí de reenviament o des de SO_MARK al sòcol, així que un bloc copiat sense font de marca no coincideix amb res.

Condició dos: les mètriques no detecten un proveïdor mort

Una mètrica és una preferència entre rutes que existeixen, no una comprovació de salut. Quan el portador cau, el nucli elimina les rutes d'aquell dispositiu i la segona ruta per defecte pren el relleu. Quan el cable continua connectat i el proveïdor de darrere mor, res canvia a la taula: la ruta preferida està instal·lada, el veí és abastable a la capa 2, i els paquets surten cap a un forat negre. Si aquesta distinció importa per a la vostra configuració, el failover ha de venir d'alguna cosa que sondegi el camí i elimini la ruta, sigui un dimoni d'encaminament o un petit script que esborri i reinstal·li l'entrada.

Verifiqueu l'elecció un cop construïda la taula, i feu-ho tal com el nucli la veurà. ip -6 route get 2001:db8:100::1 imprimeix la ruta que s'utilitzaria, incloent-hi el dispositiu i l'adreça d'origen seleccionada, i respecta les regles de política. Una adreça d'origen que pertany a l'enllaç ascendent equivocat és el senyal habitual que una regla ha coincidit abans del que esperàveu.

Condició tres: decidiu qui és el propietari de la persistència

Una ruta afegida amb ip -6 route add sobreviu fins a un reinici o fins que alguna cosa la purgui. Una ruta per defecte apresa d'anuncis d'encaminador porta una durada i pot ser retirada per l'encaminador, mentre que una ruta per defecte afegida manualment no caduca mai sola. Barrejar les dues en una taula és com una ruta permanent obsoleta acaba superant una de recent anunciada, molt després que l'enllaç ascendent que descrivia deixés d'existir.

Trieu un propietari per taula. Si un gestor de xarxa o un dimoni d'encaminament ja gestiona la interfície, descriviu-hi la ruta de política i deixeu el nucli tranquil. Si ho feu amb un script, feu l'script idempotent i escriviu l'enderrocament alhora, perquè el necessitareu durant el primer canvi dolent:

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

En un encaminador que reenvia per a altres hosts, comproveu net.ipv6.conf.all.forwarding abans de culpar la taula. Amb el reenviament desactivat, els paquets adreçats a una altra xarxa es descarten, per correcta que sigui la taula 201.

Registreu el disseny perquè la propera persona pugui auditar-lo

Un inventari que només desa fe80::1 llença els camps que importen. Registreu la destinació, el següent salt, el dispositiu, la taula i la mètrica junts, més d'on ve cada ruta—anunciada, generada pel gestor o estàtica. Quan algú pregunti més endavant si el segon enllaç ascendent porta realment trànsit, aquest registre respon la pregunta sense conjectures.

Abans de donar la taula per acabada, confirmeu el veí amb ip -6 neigh show dev uplink0, torneu a llegir ip -6 rule show per accidents d'ordre, i proveu amb trànsit que coincideixi amb la regla en lloc d'un ping que pren la ruta per defecte. Després baixeu un enllaç ascendent a propòsit i observeu a quina ruta recorre el nucli; la resposta hauria de coincidir amb la que vau escriure.