Enrutamento de políticas IPv6 cando dous enlaces comparten fe80::1

Tes dous enlaces e ip -6 route show mostra o mesmo seguinte salto en ambos: default via fe80::1 dev uplink0 e default via fe80::1 dev uplink1. Non é un conflito de enderezos duplicados, e copiar o seguinte salto espido fe80::1 a unha táboa de políticas non lle di ao kernel que enlace querías. A pregunta real é máis estreita do que suxire o síntoma: precisa a segunda táboa un enlace ou ambos, e que mantén esas rutas vivas tras un reinicio. Tres condicións, comprobadas en orde, resolven a maior parte.

O mesmo fe80::1 son dous veciños distintos

Os enderezos link-local están limitados a un único enlace, así que fe80::1 non é un enderezo impreso dúas veces; son dous veciños que casualmente comparten un sufixo. O índice de zona é como un host di cal deles quere, así que fe80::1%uplink0 e fe80::1%uplink1 son destinos distintos para o kernel, e ese sufixo nunca viaxa a un router remoto. RFC 4007 describe o modelo de zonas que hai detrás, e por iso unha táboa de políticas ten que levar un dispositivo con cada seguinte salto link-local.

Un xerador de configuración VPN que copia un ID de zona numérico dun host a un modelo trata o contexto local coma se formase parte do enderezo, e o ficheiro que escribe está mal en todas as máquinas cuxos nomes ou índices de interface difiren. Unha táboa de políticas tampouco fusiona dous enlaces nun: unha VPN encamiñada pasa paquetes entre redes, pero non leva a identidade link-local dun veciño Ethernet remoto polo túnel, así que o tráfico link-local queda no seu propio enlace.

Quita o dispositivo e a ruta vólvese non escribible. ip -6 route add default via fe80::1 table 200 non pode resolver a pasarela, e iproute2 rexeita con Error: Nexthop has invalid gateway. Engade dev uplink0 e o comando ten éxito, porque é o dispositivo o que fixa o seguinte salto a un deses dous veciños. O que o dispositivo non che pode dicir é se uplink0 é o enlace correcto para esta táboa, e unha ruta copiada doutro host trae os nomes de interface dese host, e de aí veñen os erros reais.

Condición un: un enlace ou dous na táboa

Comeza por para que serve o segundo enlace. Se ambos os enlaces levan o mesmo tráfico e un está en espera, a táboa alternativa debería conter ambas as pasarelas con métricas distintas: mesmos destinos, unha ruta preferente, unha segunda opción obvia. Se os enlaces existen porque tráfico distinto debe saír por provedores distintos, ou porque isto é un túnel dividido onde parte do tráfico evita a VPN mentres o resto queda dentro, os dous enlaces non pertencen a unha soa táboa en absoluto. Pertencen a dúas táboas, escollidas por unha regra, e a regra escolle a táboa, non o túnel: o tráfico que evita márcase antes de encamiñarse, e a marca é o que o envía á segunda táboa.

Nese segundo caso a regra decide cando se consulta unha táboa, e a ruta decide a onde vai o paquete unha vez que se consulta:

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

Ningún dos dous obxectos substitúe o outro, e unha táboa que só contén unha ruta por defecto pode seguir sen resolver a súa pasarela. Se se rexeita un add, ou a ruta existe pero é inutilizable, pon o prefixo conectado desa interface na mesma táboa, ou marca o salto onlink cando ese prefixo se encamiña noutro sitio. No bloque de arriba, 2001:db8:100::/48 representa ese prefixo conectado en uplink1, non un destino arbitrario. A regra fwmark só consome unha marca que algo máis ten que pór, desde unha regra nftables ou iptables na ruta de reenvío ou desde SO_MARK no socket, así que un bloque copiado sen fonte de marca non coincide con nada.

Condición dous: as métricas non detectan un provedor morto

Unha métrica é unha preferencia entre rutas que existen, non unha comprobación de saúde. Cando cae o operador, o kernel elimina as rutas dese dispositivo e a segunda ruta por defecto toma o relevo. Cando o cable segue arriba e o provedor detrás morre, nada cambia na táboa: a ruta preferente está instalada, o veciño é alcanzable na capa 2, e os paquetes van a un burato negro. Se esa distinción importa para a túa instalación, o failover ten que vir de algo que sondee a ruta e elimine a entrada, sexa un daemon de encamiñamento ou un pequeno script que borre e reinstale a entrada.

Verifica a escollida despois de construír a táboa, e verifícaa como a verá o kernel. ip -6 route get 2001:db8:100::1 mostra a ruta que se usaría, incluído o dispositivo e o enderezo de orixe seleccionado, e respecta as regras de política. Un enderezo de orixe que pertence ao enlace equivocado é o sinal habitual de que unha regra coincidiu antes do que esperabas.

Condición tres: decide quen é o dono da persistencia

Unha ruta engadida con ip -6 route add sobrevive até un reinicio ou até que algo a baleire. Unha ruta por defecto aprendida de anuncios de router ten unha vida e pode ser retirada polo router, mentres que unha ruta por defecto engadida a man nunca expira por si soa. Mesturar as dúas nunha táboa é como unha ruta permanente vella acaba por diante dunha recente anunciada, moito despois de que o enlace que describía deixase de existir.

Escolle un único dono por táboa. Se un xestor de rede ou un daemon de encamiñamento xa xestiona a interface, describe alí a ruta de política e deixa o kernel en paz. Se o scriptas, fai o script idempotente e escribe o desmontaxe ao mesmo tempo, porque o necesitarás na primeira mudanza mala:

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

Nun router que reenvía por outros hosts, comproba net.ipv6.conf.all.forwarding antes de culpar a táboa. Co reenvío desactivado, os paquetes dirixidos a outra rede descártanse por moi correcta que sexa a táboa 201.

Rexistra o deseño para que a seguinte persoa poida auditalo

Un inventario que só almacena fe80::1 tira os campos que importan. Rexistra o destino, o seguinte salto, o dispositivo, a táboa e a métrica xuntos, ademais de onde veu cada ruta, se é anunciada, xerada polo xestor ou estática. Cando alguén pregunte despois se o segundo enlace leva tráfico de verdade, ese rexistro responde sen adiviñar.

Antes de dar a táboa por rematada, confirma o veciño con ip -6 neigh show dev uplink0, volve ler ip -6 rule show por accidentes de orde, e proba con tráfico que coincida coa regra en vez dun ping que colla a ruta por defecto. Despois baixa un enlace a propósito e observa a que ruta recorre o kernel; a resposta debería coincidir coa que escribiches.