Mi pregunta está relacionada conestepregunta pero con poca diferencia:
Tengo un vps de Ubuntu con un único IPv4 en la interfaz principal. Me gustaría tener dos túneles IPv6 separados en esta máquina que sean de dos proveedores diferentes con direcciones de punto finales diferentes. Cuando pruebo uno de ellos solo. Todo esta bien. Pero cuando agrego el segundo túnel, el primero todavía funciona pero no se puede hacer ping al segundo desde afuera. Sin embargo, puede hacer ping a sí mismo y a la puerta de enlace.
Agrego estas líneas a mi /etc/network/interfaces:
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:xxx:xxx:xxxx::2
netmask 64
endpoint xx.xx.xx.xx
local yy.yy.yyy.yy
ttl 255
gateway 2001:xxx:xxx:xxxx::1
auto sbtb-ipv6
iface sbtb-ipv6 inet6 v4tunnel
address 2a09:xxx:xxx:xxxx::2
netmask 64
endpoint zz.zz.zz.zz
local yy.yy.yyy.yy
ttl 255
gateway 2a09:xxx:xxx:xxxx::1
¿Alguien sabe dónde está el problema o cómo puedo solucionarlo?
Respuesta1
Algunas observaciones
Para otras herramientas de configuración de red ifupdown, v4tunneles realmente una capa 3SENTARSEtúnel que se puede crear dependiendo de las herramientas que utilizan el equivalente de ip tunnel add FOO mode sit ...o de ip link add name FOO type sit ....
Las interfaces de capa 3 no tienen una dirección de capa 2 (sin dirección MAC de Ethernet) y, por lo tanto, no tienen que resolver la dirección de la capa 2 subyacente: ARP (IPv4) y NDP (IPv6) no ocurren con una interfaz de capa 3. . Por la misma razón, no hay una puerta de enlace que resolver: no se necesita una puerta de enlace para su propiedad de puerta de enlace, pero la sintaxis aún puede permitir adivinar la interfaz a usar al crear una entrada en la tabla de enrutamiento sin especificar la interfaz y eso es lo que generalmente se hace, incluido elEjemplos de configuración propios del broker de túneles.. Al final, no se necesita usar la máscara de red /64 y una puerta de enlace en ningún lugar para la configuración del OP. Pero esta respuesta aún se atendrá a estas configuraciones, por lo que será más fácil para el lector adaptarla a un túnel de interfaz de capa 2 donde todas estas configuraciones se vuelven obligatorias. Del mismo modo, normalmente sólo se necesitan configuraciones sobre la interfaz no predeterminada (aquí sbtb-ipv6), pero de todos modos estoy proporcionando una configuración para las dos interfaces. La única diferencia que queda es qué interfaz obtiene la ruta predeterminada en la tabla de enrutamiento principal.
Multihoming y enrutamiento de políticas
Éste es ahora un caso desistema multihoming que utiliza múltiples direccionescada uno con su propio camino para llegar a Internet (IPv6). Los enrutadores ascendentes ciertamente implementanReenvío de ruta inversa estricto(SRPF) para anti-spoofing: cada dirección de origen debe transitar por su ruta dedicada. Con la ruta simple solo se utiliza una ruta predeterminada (la primera que se muestra). Es posible agregar una segunda ruta predeterminada con una métrica más larga, pero nunca se elegirá hasta que desaparezca la ruta con una métrica más corta.
Para superar esto, se puede utilizarenrutamiento de políticas. Esto permite que el sistema elija otras tablas de enrutamiento (con diferentes rutas) y reglas de enrutamiento que elegirán estas tablas de enrutamiento con selectores adicionales en lugar de simplemente usar el destino para encontrar la ruta. Aquí lo que es útil es la dirección de origen (y en algunos casos también la interfaz saliente cuando esta interfaz se fuerza conSO_BINDTODEVICE).
Entonces, el objetivo es crear múltiples tablas de enrutamiento alternativas con una vista parcial de las rutas, basadas en las entradas de la tabla de enrutamiento principal: cada tabla de enrutamiento considerará que solo existe una ruta a Internet y tendrá su propia ruta predeterminada. Luego, una regla de enrutamiento basada en la dirección de origen seleccionará la tabla de enrutamiento adecuada para los paquetes salientes. En el caso de OP, no se necesita nada especial para los paquetes entrantes, porque la tabla de enrutamiento local ya maneja este caso.
Implementación
Primero, la interfacesconfiguración debe ajustarse agregando un diferentemétricoen cada uno, o la sbtb-ipv6configuración probablemente fallará porque no puede haber dos rutas predeterminadas con la misma métrica.
Luego, aquí se explica manualmente cómo hacer que esto funcione. Agregue dos tablas de enrutamiento con valores (arbitrarios) 2000 para HE y 2001 para SBTB y copie solo rutas relacionadas a cada una. La métrica no importa aquí ya que no hay conflicto posible.
ip -6 route add 2001:xxx:xxx:xxxx::/64 dev he-ipv6 table 2000
ip -6 route add default via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000
ip -6 route add 2a09:xxx:xxx:xxxx::/64 dev sbtb-ipv6 table 2001
ip -6 route add default via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001
Y seleccione la ruta adecuada según la dirección de origen con reglas de enrutamiento (y para ser explícito, indique una prioridad fija y indique que es un paquete iniciado localmente con iif lo):
ip -6 rule add pref 20000 from 2001:xxx:xxx:xxxx::2 iif lo lookup 2000
ip -6 rule add pref 20010 from 2a09:xxx:xxx:xxxx::2 iif lo lookup 2001
Para el caso en el que uno se vincula a la interfaz (por ejemplo ping -I sbtb-ipv6 ...), en lugar de "simplemente" a la dirección de la interfaz ( ping -I 2a09:xxx:xxx:xxxx::2), también use esto para obtener resultados adecuados (realmente útil para casos de capa 2 donde no existe una segunda ruta predeterminada en la tabla de enrutamiento principal, en realidad no necesario en el caso de OP con interfaces de capa 3):
ip -6 rule add pref 20001 oif he-ipv6 lookup 2000
ip -6 rule add pref 20011 oif sbtb-ipv6 lookup 2001
La dirección opuesta (tráfico entrante también conocido como ingreso) ya se maneja correctamente en la localtabla de enrutamiento cuando se agregan direcciones, por lo que no hay nada especial que hacer para el ingreso.
Configuración final
Lo anterior debe intentarse manualmente primero, con un acceso de respaldo a la consola remota (aunque IPv4 no se ve afectado, el acceso IPv4 debería ser suficiente). Luego se puede integrar en el interfacesarchivo de configuración, usando los comandos up/ downdonde ifupdownno sea compatible con la función (es decir, todo el enrutamiento de políticas). Asegúrese de eliminar las pruebas manuales anteriores, o algunos comandos en la configuración de la interfaz entrarán en conflicto con errores como RTNETLINK answers: File existsy la configuración de la interfaz fallará.
ACTUALIZACIÓN: esto también incluye la emisión de tres pings al extremo remoto del túnel SBTB, ya que según los comentarios parece que este túnel debe ver el tráfico del servidor antes de poder aceptar tráfico al servidor. Si la dirección del mismo nivel SBTB (túnel) no es suficiente para activar la aceptación de tráfico al servidor, reemplácela con alguna dirección IPv6 "conocida". Se podría agregar lo mismo en la interfaz HE, pero no parece necesario.
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:xxx:xxx:xxxx::2
netmask 64
endpoint xx.xx.xx.xx
local yy.yy.yyy.yy
ttl 255
gateway 2001:xxx:xxx:xxxx::1
metric 1000
up ip -6 route add 2001:xxx:xxx:xxxx::/64 dev he-ipv6 table 2000
up ip -6 route add default via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000
up ip -6 rule add pref 20000 from 2001:xxx:xxx:xxxx::2 iif lo lookup 2000
up ip -6 rule add pref 20001 oif he-ipv6 lookup 2000
down ip -6 rule del pref 20001
down ip -6 rule del pref 20000
auto sbtb-ipv6
iface sbtb-ipv6 inet6 v4tunnel
address 2a09:xxx:xxx:xxxx::2
netmask 64
endpoint zz.zz.zz.zz
local yy.yy.yyy.yy
ttl 255
gateway 2a09:xxx:xxx:xxxx::1
metric 1001
up ip -6 route add 2a09:xxx:xxx:xxxx::/64 dev sbtb-ipv6 table 2001
up ip -6 route add default via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001
up ip -6 rule add pref 20010 from 2a09:xxx:xxx:xxxx::2 iif lo lookup 2001
up ip -6 rule add pref 20011 oif sbtb-ipv6 lookup 2001
up ping -q -c3 -I sbtb-ipv6 2a09:xxx:xxx:xxxx::1
down ip -6 rule del pref 20011
down ip -6 rule del pref 20010
¿Cómo utilizar?
Ahora uno puede abrir una o ambas interfaces, siempre funcionará correctamente, dando prioridad he-ipv6cuando ambas estén activas. Para usar la sbtb-ipv6interfaz cuando ambas están activas, uno debe vincularse a su dirección o vincularse a la interfaz misma. A continuación se muestran ejemplos para mostrar la ruta que se espera que utilice el kernel:
# ip route get to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2001:xxx:xxx:xxxx::1 dev he-ipv6 src 2001:xxx:xxx:xxxx::2 metric 1000 pref medium
# ip route get from 2001:xxx:xxx:xxxx::2 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from 2001:xxx:xxx:xxxx::2 via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000 src 2001:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get oif he-ipv6 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2001:xxx:xxx:xxxx::1 dev he-ipv6 table 2000 src 2001:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get from 2a09:xxx:xxx:xxxx::2 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from 2a09:xxx:xxx:xxxx::2 via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001 src 2a09:xxx:xxx:xxxx::2 metric 1024 pref medium
# ip route get oif sbtb-ipv6 to 2001:db8:f00:ba7::1
2001:db8:f00:ba7::1 from :: via 2a09:xxx:xxx:xxxx::1 dev sbtb-ipv6 table 2001 src 2a09:xxx:xxx:xxxx::2 metric 1024 pref medium
Varios comandos, demonios o herramientas requieren varias opciones para vincularse a otra dirección o dispositivo de origen. Por ejemplo: ping -I, traceroute -i, curl --interface, ssh -b/ ssh -B, etc.
Se puede comprobar comparando el resultado de uno de estos comandos:
curl -6 https://ifconfig.co
curl -6 --interface 2001:xxx:xxx:xxxx::2 https://ifconfig.co
curl -6 --interface he-ipv6 https://ifconfig.co
versus el resultado de uno de estos:
curl -6 --interface 2a09:xxx:xxx:xxxx::2 https://ifconfig.co
curl -6 --interface sbtb-ipv6 https://ifconfig.co