cómo configurar radvd para el enrutador ipv6 de Linux hacia la puerta de enlace dsl ascendente

cómo configurar radvd para el enrutador ipv6 de Linux hacia la puerta de enlace dsl ascendente

Estoy intentando que el enrutador Linux de mi hogar también admita ipv6 en la red doméstica.

Tengo un enrutador DSL NVG599 que actúa como GW para la Internet pública y luego mi enrutador Linux con dos interfaces: eth0 hacia la red doméstica y eth1 hacia el enrutador DSL.

Red DOMÉSTICA <----eth0-----> LinuxRouter <------eth1------>DSLrouter -->>>>>

El enrutador DSL está configurado con un prefijo de red /64 de mi ISP (supongamos que es 2001:0:0:1234::/64) y el enrutador DSL tiene una dirección global ipv6 de 2001:0:0:1234::1 . He configurado el enrutador Linux con radvd para anunciar este mismo prefijo de red /64 en eth0 hacia la LAN doméstica y, de hecho, veo que los hosts de la LAN pueden configurar automáticamente sus direcciones IP. El anuncio también enumera el enrutador Linux como el enrutador predeterminado para ::/0, y el reenvío está configurado para que envíe los paquetes al enrutador DSL.

El problema que tengo es que el enrutador DSL envía paquetes de solicitudes de vecinos en eth1 cuando recibe paquetes entrantes de Internet, y esas solicitudes de vecinos no se pasan desde eth1 -> eth0 en el enrutador Linux. Estoy pensando que esto ocurre porque el enrutador DSL cree que está conectado directamente a la red doméstica (que es como sería normalmente en el 99% de las redes domésticas sin un enrutador Linux en el medio).

Después de pasar 2 días tratando de resolverlo, hasta ahora la respuesta se me ha escapado. Espero que haya alguna forma de enviar un anuncio de enrutador usando radvd al enrutador DSL para indicarle que enrute todos los paquetes para el prefijo /64 a través del enrutador Linux. Actualmente, el anuncio del enrutador enviado por el enrutador Linux está configurado con el prefijo /64 que se envía hacia el enrutador DSL con:

interface eth1
{
    AdvSendAdvert on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    route 2001:0:0:1234::/64 {
    };

};

Creo que esto debería ser suficiente para que el enrutador DSL reenvíe todos los paquetes a la red, pero sigo viendo las solicitudes de los vecinos.

Veo que el enrutador DSL tiene configuraciones de paso de IP con la capacidad de configurar un "servidor predeterminado", pero parece que se aplican solo a IPv4. Suponiendo que el enrutador DSL no respeta mi RA, supongo que podría configurar el reenvío de multidifusión ipv6 usando 'xorb' en mi enrutador Linux, pero me pregunto si hay otras opciones.

Respuesta1

El problema que tengo es que el enrutador DSL envía paquetes de solicitudes de vecinos en eth1 cuando recibe paquetes entrantes de Internet, y esas solicitudes de vecinos no se pasan desde eth1 -> eth0 en el enrutador Linux.

Eso es normal. Las solicitudes de vecinos funcionan igual que las consultas ARP: traducen una dirección IP a una dirección MAC y, por lo tanto, solo tienen sentido dentro del mismo dominio de transmisión. Hacesin sentidopara que un enrutador los reenvíe.

(Aunque en algunas situaciones un enrutador puedeapoderadoellos, como se describe al final, pero... déjelo para el plan C.)

Estoy pensando que esto ocurre porque el enrutador DSL cree que está conectado directamente a la red doméstica (que es como sería normalmente en el 99% de las redes domésticas sin un enrutador Linux en el medio).

Si y tu nuncadijode otra manera.

Entonces su situación actual es que elmismoLa subred IP está siendo utilizada por dos redes diferentes y espera que el enrutador Linux funcione como un puente... Lo cual es casi exactamente lo opuesto a un enrutador.

(Si la parte confusa es IPv6, piense en toda la configuración en términos de IPv4, ya que el enrutamiento es más o menos el mismo en ambos, y ND es mayoritariamente equivalente a ARP. Entonces, si no usara la misma subred 192.168.1.0 en v4...)


Su mejor curso de acción esobtener unsegundo/64,y useesopara la red eth1 de su enrutador Linux. (Si el enrutador DSL obtiene su prefijo a través de DHCPv6-PD, es posible engañarlo para que solicite un segundo). Sin embargo, la diferencia es que el segundo /64 no se usaría directamente en una interfaz, sino queenrutadohacia la dirección del enrutador Linux.

Por ejemplo:

  • El enrutador DSL tiene 2001:db8:0:0:a:b:c:d en la interfaz WAN.
  • El enrutador DSL obtiene 2001:db8:10:0::/64 del ISP, autoasigna 2001:db8:10:0::1/64 en la interfaz LAN y envía anuncios de enrutador.
  • El enrutador Linux se configura automáticamente 2001:db8:10:0:x:y:z:t en eth1 según los RA.
  • El enrutador Linux obtiene 2001:db8:10:1::/64 del ISP (de alguna manera), autoasigna 2001:db8:10:1::1/64 en la interfaz eth0 y radvd envía anuncios de enrutador para eso:nopara la primera subred.
  • El enrutador DSL necesita una ruta como "2001:db8:10:1::/64 vía 2001:db8:10:0:x:y:z:t" para que todo el tráfico de la segunda subred se reenvíe hacia el enrutador Linux. .

(Disculpas por el ejemplo no muy claro).

A veces, el ISP le delega un /60 o incluso un /56 completo y lo enruta todo hacia el enrutador DSL. En ese caso, podrías configurar la segunda subred sin ningún tipo de magia DHCPV6-PD. Realmente, aunque no puedo dar una buena respuesta "genérica" ​​aquí, ya que depende tanto del ISP como del CPE.


Si es imposible obtener un segundo prefijo /64, otras opciones posibles son:

  • Convierta el sistema Linux en un puente puro, sin ninguna funcionalidad de enrutamiento.

  • Utilice otras fuentes para obtener /64 adicionales, como un proveedor de túneles (o 6to4). Los servicios de túnel existentes funcionarán de manera mucho más confiable (excepto por alguna latencia adicional) que los trucos que se describen a continuación.

  • Haga que el enrutador DSL solo obtenga /64 pero no lo configure para LAN. (Depende de qué tan flexible sea el enrutador). En su lugar, configure nuevamente una ruta para ese /64 a través de la dirección de enlace local eth0 de su sistema Linux, y de la misma manera configure una ruta en el sistema Linux para ::/0 a través de la dirección del enrutador DSL. Dirección local de enlace LAN. Como resultado, /64 solo se usará en la segunda subred y la primera no tendrá ningún prefijo público.

  • Continúe con su configuración actual, pero instale 'ndppd' para realizar el proxy de Neighbor Discovery. (No, el reenvío de multidifusión no funcionará ya que los paquetes ND a menudo tienen direcciones de origen de enlace local). Tenga cuidado con esto, puede hacer que las cosas sean realmente confusas.

  • Utilice direcciones privadas (ULA) para la segunda LAN y habilite NAT (enmascaramiento) de 1 a muchos en el enrutador Linux... perdiendo la mayor parte de la utilidad de IPv6 en el proceso. (Sí, oficialmente NAT no existe en IPv6, pero eso no impidió que Linux netfilter/iptables cediera e implementara).

información relacionada