Los que tengan servidores dedicados con ESXi posiblemente sabrán del asunto. Debido a la configuración que OVH tiene desplegada en su red, es imposible que un servidor que no tenga direcciones IPv4 asignadas pueda conseguir una IPv6. Esto, aunque puede ser ilógico, tiene su explicación en que lo utilizan como mecanismo de seguridad aunque bien podrían hacerlo ligando la IP a un puerto y sería mucho más sencillo para todos. OVH guarda un misterioso silencio alrededor de este tema, y me  parece cuanto menos curioso cuando no debería ser difícil añadir esta funcionalidad. 

Ya de por sí, delegar un rango /64 a unas pocas máquinas es un autentico desperdicio. Serían unas 18.446.744.073.709.551.616 (2^64) ip's para mi solo. Y parece que es la tendencia entre los proveedores.

Por suerte, podemos utilizar las características del NDP, neighbor discovery protocol, de IPv6 para conseguir que un equipo con una IPv6 e IPv4 pueda hacer de proxy y al mismo tiempo hacer de gateway. De esta manera conseguiremos conectividad IPv6 en esta máquina.

En primer lugar, en nuestra máquina que ya tiene una IPv6, vamos añadir los siguientes parámetros al fichero /etc/sysctl.conf:

net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

Una vez hecho, vamos a activarlos con sysctl -p. Ya tenemos activado el proxy ndp, ahora tenemos que autorizar los hosts, pero antes vamos a configurar la dirección ip en la máquina sin acceso:

ifconfig eth0 inet6 add 2001:41d0:X:XXXX::X/64

ó, con el comando ip:

ip -6 addr add 2001:41d0:X:XXXX::X/64 dev eth0

También vamos a indicarle que nuestra puerta de enlace es el otro host:

route -6 add default gateway 2001:41d0:X:XXXX::X

con el comando ip:

ip -6 route add via 2001:41d0:X:XXXX::X dev eth0

Si ejecutamos el comando ip, veremos que nos muestra la IP en estado tentative.

Ahora vamos a autorizar a este host para que acceda a la red. Volvemos al primer host y ejecutamos lo siguiente:

ip -6 neigh add proxy 2001:41d0:X:XXXX::X dev eth0

Listo, si ahora volvemos a la otra máquina y hacemos ping a los dns de google, deberíamos tener respuesta:

ping6 2001:4860:4860::8888 -c 2
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=55 time=9.62 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=55 time=9.95 ms

--- 2001:4860:4860::8888 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.626/9.789/9.952/0.163 ms

Esta configuración tiene el problema de que cada vez que se reinicie la máquina, hay que borrar y volver a activar la asignación de la IPv6 a traves del proxy ndp. De lo contrario, la ip se quedará en estado dadfailed.

No es mucho, pero al menos permite jugar un poco y permitir tener máquinas virtuales funcionando con IPv6.

4 comentarios:

  1. Respuestas
    1. Explica un poco que es lo que te falla y a lo mejor puedo ayudarte!

      Eliminar
  2. Ya me funciona!!! El problema era el csf. Pero ahora lo que me sucede que si lo activo deja de funcionar. Sabes que hay que hacer para que funcione? Sabes si el proxy ndp utiliza algún puerto??

    Gracias

    ResponderEliminar
  3. Ya he encontrado la solución. Si está activado ip6tables no funciona.

    Hay que modificar lo siguiente:

    centos: nano /etc/sysconfig/ip6tables
    debian: nano /etc/ip6tables.rules

    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    # Allow SSH connections for management
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    # ICMP is nice sometimes
    -A INPUT -p ipv6-icmp -j ACCEPT
    -A INPUT -j DROP
    COMMIT

    centos:ip6tables-restore < /etc/sysconfig/ip6tables
    debian:ip6tables-restore < /etc/ip6tables.rules

    Reiniciamos la red y ya funcionará!!!!

    ResponderEliminar

Nube de Bits, 2011. Con la tecnología de Blogger.