Subredes IPv6

  

El subnetting IPv6 es el proceso de dividir una red IPv6 en subredes más pequeñas. Esto se hace para aumentar la seguridad, el rendimiento y la escalabilidad de la red. El subnetting IPv6 se realiza utilizando una máscara de subred. La máscara de subred es un número binario de 128 bits que se utiliza para identificar los bits de red y los bits de host en una dirección IPv6. Para subnetear una dirección IPv6, primero debe convertir la dirección y la máscara de subred a decimal. Luego, puede utilizar la máscara de subred para calcular el número de bits de red y el número de bits de host. Una vez que conozca el número de bits de red y el número de bits de host, puede determinar el número de hosts que puede alojar cada subred. Al entender cómo funciona el subnetting, los administradores de redes pueden diseñar y administrar redes IPv6 seguras, eficientes y escalables. Ref 

 

En el post anterior he establecido un túnel entre el Ubuntu "Router" y Wireguard que opera sobre IPv4. Sin embargo, las IPs asignadas a la interfaz WireGuard son IPv6. Nuestro router tiene la dirección ::2  y  Route64 tiene la dirección ::1. Con esta configuración, la conectividad IPv6 es completamente funcional. Nuestro enrutador posee una dirección unicass global que lo hace accesible desde cualquier lugar de Internet. Echemos un vistazo a nuestro esquema de red.

 

 

En la siguiente captura veremos que Route64 nos ha asignado una subred /56 dedicada, lo que nos proporciona 256 redes individuales, cada una con un tamaño de /64.

 

 

Esto se puede asignar y utilizar libremente según sea necesario. El mecanismo de enrutamiento de Route64 garantiza que cualquier tráfico dirigido hacia nuestra subred 56 se reenvíe correctamente a nuestro enrutador en ::2. En pocas palabras, nuestro enrutador inicialmente solo tiene conectividad IPv4, mientras que la Route64 admite tanto IPv4 como IPv6. Route64 garantiza que el tráfico destinado a esta subred se enrute a través de nuestro Ubuntu Server, lo que permite una comunicación IPv6 perfecta.

  

Es hora de configurar la interfaz interna del Server para habilitar el acceso IPv6 dentro de la red local. Primero, revisemos nuestras interfaces de red. 

 

 

Vemos que la interfaz ens256 no está configurada. A diferencia de IPv4, IPv6 no requiere NAT. En su lugar, se nos ha asignado una subred /56, lo que nos permite dividirla en varias subredes de 64 bits. Cada subred de 64 bits puede asignarse a una interfaz o VLAN diferente dentro de la red. Para seleccionar una subred /64 de nuestro rango de 56 bits, usaré sipcalc para mostrar información detallada.

 

 

Analicemos la asignación de IPv6. Los primeros 56 bits forman el prefijo de red, que permanece fijo según lo asignado por la ruta 64. 

 

 

Los siguientes ocho bits nos permiten crear 256 subredes, que van de 00 a FF en hexadecimal. 

 

 

Los últimos 64 bits se utilizan para direcciones de host individuales dentro de cada subred de 64 bits. 

 

 

Para esta configuración, elegiré la última subred disponible, FF, y la asignaré a ens256. Para asegurarnos de que ens256 tenga asignada correctamente una dirección IPv6, creemos un archivo de configuración de red en la ruta /etc/systemd/network/ens256.network. 

 

 

En el apartado [Match] ponemos el nombre de la interfaz ens256 para coincida con la tarjeta de red. A continuación, en la sección [Network], asignemos la dirección IPv6. Dado que nuestro router será la puerta de enlace predeterminada para los hosts internos, haremos que la dirección sea predecible y fácil de recordar. Asignaré ::1 al router. Para aplicar la configuración, reiniciaré systemd-networkd. 

 

 

Ahora verifiquemos los cambios.👌. La interfaz interna ya tiene una dirección IPv6 asignada. A continuación, necesitamos asignar direcciones IP, la ruta predeterminada y el DNS a nuestros dispositivos cliente. Para IPv4, normalmente configuramos un servidor DHCP para asignar direcciones IP, la ruta predeterminada y la configuración DNS a los clientes. Sin embargo, en redes IPv6, el método más popular para asignar direcciones IPv6 a dispositivos cliente es Slaac, que significa configuración automática de direcciones sin estado. En este método, los dispositivos generan sus propias direcciones IPv6 utilizando el prefijo proporcionado por el router y su propio identificador de interfaz, a menudo basado en la dirección MAC o generado aleatoriamente. Es importante destacar que Slaac solo funciona con 64 subredes. Por eso, /64 es el tamaño estándar para las redes de usuarios finales, lo que garantiza una configuración automática sin problemas. En este método, no se necesita un servidor DHCP. El enrutador envía periódicamente mensajes de anuncio de enrutador a un grupo multicast especial al que se unen todos los nodos. Dentro de estos mensajes de anuncio de enrutador, hay una puerta de enlace predeterminada de prefijo, así como DNS. Los clientes también pueden solicitar configuración enviando un mensaje de solicitud de enrutador a un grupo multicast especial al que se unen todos los enrutadores. El enrutador responderá con un mensaje de anuncio de enrutador. 

 

Para habilitar el mensaje de anuncio de enrutador, necesitamos instalar la herramienta radvd, que es un servicio de demonio de anuncio de enrutador. Ahora, crearé un archivo de configuración para el demonio de anuncio de enrutador en la ruta /etc/radvd.conf.

 

 

Primero, definimos la interfaz ens256 que es donde opera nuestro demonio y que apunta a nuestra red interna. Luego, habilitamos "on" el mensaje de anuncio de enrutador para que los clientes puedan configurar automáticamente las direcciones IPv6 y el enrutamiento. A continuación, definimos el intervalo entre los mensajes de anuncio de enrutador que se envían. Frecuencia de los mensajes de anuncio de enrutador "600" y "200". Después, especificamos el prefijo IPv6 que debe usar el cliente "/64". Informamos a los dispositivos que esta subred es directamente accesible "on". Ahora, habilitemos la configuración automática de direcciones sin estado para que los clientes puedan asignar automáticamente sus propias direcciones IP dentro del rango /64 "on". Finalmente, configuremos un anuncio de servidor DNS recursivo. Elijamos Cloudflare "1111"como DNS. Especificamos que los clientes deben usar este DNS durante 20 minutos antes de actualizar "1200". Listo, nuestra configuración está lista. Reiniciemos el demonio de anuncios del enrutador y verifiquemos su estado. 

 

Todo se ve bien, excepto que vemos una advertencia de que el reenvío de IPv6 está deshabilitado. Para que nuestros dispositivos cliente accedan a Internet, debemos habilitar el reenvío de IP. Esto permite que nuestro enrutador Linux enrute el tráfico de red entre diferentes interfaces. Lo configuraremos a través de systemd-networkd. Accedamos a la ruta /etc/systemd/network/ del archivo de configuración de las interfaces habilitadas en el Server ens160.network - ens256.network - wg0.network. Establecemos el parámetro de reenvío de IP en verdadero. 

 

 

Reiniciemos systemd-networkd para aplicar la nueva configuración de reenvío en todo el sistema. Reiniciemos el demonio de anuncio del enrutador. Si verificamos su estado, vemos que la advertencia anterior sobre la falta de reenvío de IP ha desaparecido.

 

 

Finalmente, verifiquemos que el reenvío de IP esté correctamente habilitado mirando los parámetros del kernel.

 

 

Como podemos ver, el reenvío de IPv4 e IPv6 está activo, lo que garantiza un enrutamiento adecuado para todos los dispositivos. Con el reenvío habilitado, nuestro enrutador ahora es completamente capaz de pasar tráfico IPv6 entre dispositivos internos e Internet. Probemos la conectividad del cliente. 

 

Pasemos a un dispositivo cliente conectado a la red interna. Conectaré la interfaz y comprobaré qué sucede. El dispositivo ha configurado automáticamente su dirección IPv6 según el prefijo anunciado por el enrutador. 

Ahora veamos la tabla de enrutamiento. 

Nuestro sistema ha aprendido una ruta IPv6 mediante anuncios de enrutador y puede comunicarse dentro de la subred. También hemos recibido una puerta de enlace predeterminada mediante anuncios de enrutador. A diferencia de IPv4, donde la puerta de enlace predeterminada suele ser una IP privada o pública, los enrutadores IPv6 suelen anunciar su puerta de enlace mediante una dirección local que comienza fe80 y solo es válida dentro de un único segmento de red. No se puede enrutar más allá de ese segmento. El enrutamiento IPv6 asume un entorno dinámico y el uso de una dirección local de enlace garantiza la estabilidad incluso si la dirección IPv6 global del enrutador cambia. Probemos la accesibilidad de nuestro enrutador a través de su dirección local de enlace. Tenga en cuenta que al apuntar a una dirección local de enlace, debe especificar la interfaz. 

¡Éxito! Podemos acceder a nuestra puerta de enlace predeterminada. Ahora tenemos una dirección unicas global IPv6, una puerta de enlace predeterminada y un servidor DNS. Todo esto se configuró automáticamente mediante anuncios de enrutador. Para ver este proceso en acción, enviemos un mensaje de solicitud de enrutador a la interfaz enp0s3. 

Hemos recibido un anuncio de enrutador que configura la red IPv6 de nuestro cliente. Ahora, hagamos una prueba final haciendo ping a Google usando su dirección IPv6. 

Funciona. Para analizar más a fondo la ruta de enrutamiento, realicemos un seguimiento de ruta. Veremos que el tráfico se dirige a través de una infraestructura solo IPv6. 

Recuerde también que nuestro equipo cliente ahora tiene una dirección uniccast global. Debería ser accesible desde internet. Rastreamos la ruta a nuestro cliente desde un host IPv6 nativo fuera de nuestra red. 

 

 

¡Genial! Tenemos total accesibilidad IPv6 y los demás hosts habilitados para IPv6 también pueden comunicarse con nosotros. 

 

Ahora, intentemos llegar a la red de Amazon. 

Es inaccesible. ¿Qué sucede? Si comprobamos su resolución IP, vemos que amazon.com solo tiene una dirección IPv4. Como nuestro cliente solo admite IPv6, no puede comunicarse con destinos que solo admiten IPv4. 😉👍

Continue reading →

Protocolo IPv6

Internet tal como lo conocemos existe gracias a un sistema que asigna a cada dispositivo conectado a la red una dirección conocida como número IP. El sistema que hasta ahora maneja estas direcciones se denomina IPv4 y es capaz de ofrecer un total de 4,294,967,296 direcciones únicas, un número derivado de sus 32 bits (2³²). Pero el crecimiento constante de dispositivos conectados hace que esta cantidad sea insuficiente. Como cada número IP solo puede ser usado por un dispositivo al mismo tiempo, la solución hasta ahora pasaba por otorgar IPs dinámicas. O sea, cuando un usuario se conecta, se le asigna un número. Cuando se desconecta, ese mismo número es adjudicado a otro usuario. Si tenemos en cuenta que cada vez hay nuevos dispositivos conectados como televisores, automóviles o robots, esta cantidad de direcciones no serán suficientes. Presentamos IPv6. Este nuevo protocolo ofrece un número más acorde al futuro de internet, (2¹²⁸ o 340 sextillones de direcciones). Si representáramos el tamaño de IPv4 como una pelota de golf, IPv6 sería como el sol. IPv6 ya se está implementando, lo que garantizará que tengamos direcciones disponibles para todos los dispositivos que en un futuro lo requieran.
 

La primera conexión es la más esencial y es hacer ping entre dos máquinas de una red local. Normalmente Linux trae habilitado el protocolo IPv6 por defecto con direcciones locales. En las siguientes imágenes se ve como responde el comando ping lanzado desde Ubuntu Server a una máquina Debian. 

 

 

Si queremos que la conexión salga a internet, necesitamos pedir a nuestro ISP que nos asigne una IPv6 Global. Una vez tenemos asignada una IPv6 en el router, podemos consultar que dirección tenemos en nuestra tarjeta de red y hacer ping a cualquier servicio que este configurado con este protocolo.

 

 

Algo muy importante después de saber que tenemos conexión con el exterior es proteger la comunicación, y eso se hace a través del Router del ISP y Firewall de la máquina. Aunque ese tema daría para otro post.

  

Ahora veamos cómo configurar un Servidor Ubuntu con IPv6 usando un agente de túneles como Route64. Supongamos que alojamos un servicio web, con IPv4, necesitamos configurar el reenvío de puertos NAT, DNS dinámico y probablemente lidiar con el CG-NAT si su proveedor de internet los utiliza. Con IPv6, simplemente conectan el dispositivo, le asignan una dirección unicass global y podrán acceder a él de inmediato a través de internet de forma segura y directa. Sin reenvío de puertos ni trucos. Usando un agente de túneles como Route64, podemos crear una conexión IPv6 segura y confiable directamente sobre su internet IPv4 existente. En el servidor Ubuntu habilitaremos dos interfaces de red, una para la red pública y otra para la red privada. Comencemos por identificar nuestras interfaces de red...

 

  

Asignamos una dirección IPv4 estática a la interfaz ens160. Esa será la interfaz pública. Ubuntu almacena todos los archivos de configuración de red en la carpeta /etc/systemd/network/. Creamos un nuevo archivo de configuración para esta interfaz llamado ens160.network, es importante que termine en ".network". Aunque el nombre del archivo no importa, nombrarlo como la interfaz ayuda a mantener la claridad. 

 

 

La sección [Match] le indica a systemd-network a qué interfaz se aplica esta configuración. En nuestro caso, compararemos la interfaz por nombre. En la sección [Network], configuraremos la dirección IP estática, la puerta de enlace predeterminada y el servidor DNS "Cloudflare". Para aplicar los cambios, reiniciamos systemd-networkd, y verificamos que se hayan aplicado los cambios. 

 

 

Todo parece correcto. Finalmente, verifiquemos que la dirección IP se haya asignado a ens160. 

 

 

Vemos que se ha asignado 192.168.1.122 a ens160. Esto significa que nuestra interfaz pública ahora está configurada correctamente para el acceso a internet. Con nuestra interfaz de resolución de DNS de red pública configurada correctamente, el siguiente paso es garantizar una resolución de nombres eficiente. Una configuración de DNS bien optimizada puede reducir significativamente la latencia de las consultas y mejorar la capacidad de respuesta. Para ello, usaremos systemd-resolved. Empecemos por consultar el estado del resolvctl.

 

 

Todo parece correcto. El modo del solucionador es stub y el DNS es Cloudflare. Probaremos la resolución de DNS consultando google.com.

 

 

Obtuvimos la respuesta en 21 milisegundos. Si consultamos una vez más, obtenemos el resultado en 1.5 milisegundo. Eso se debe a que el resultado fue almacenado en caché por nuestro systemd-resolved. 

 

Ahora, abordemos la falta de conectividad IPv6. Dado que nuestra red opera únicamente en IPv4, utilizaremos un agente de túnel IPv6 para cerrar la brecha. Un agente de túnel IPv6 es un servicio que proporciona conectividad IPv6 a redes solo IPv4 creando una conexión tunelizada sobre la infraestructura IPv4 existente. Esencialmente, creamos un túnel punto a punto sobre IPv4 y el ISP enruta nuestro tráfico IPv6 a través de él. Con el servicio Route64 crearemos el túnel IPv6 y gestinaremos el BGP (protocolo de enrutamiento) para los usuarios, utilizando su propia plataforma.

 

Bien, para empezar necesitamos registrarnos en Route64. Iniciamos sesión en la cuenta recién creada. 

 

En el panel de administración de Route64 desplegamos la pestaña Tunnelbroker para configurar un nuevo túnel IPv6 haciendo clic en agregar nuevo.

 

 

Aquí hay una lista de PoPs disponibles. PoP significa punto de presencia. Es una ubicación de centro de datos donde Route64 tiene servidores implementados para brindar sus servicios. Para garantizar el mejor rendimiento, necesitamos conectarnos al PoP con la latencia más baja, generalmente la más cercana geográficamente. Elegiré París. Para medir la latencia, haremos ping al PoP usando su dirección IP 45.154.96.16, 30 milisegundos. 

 

 

Ahora seleccionemos el PoP. Para el tipo de túnel, elegiré WireGuard, ya que es el único protocolo que admite cifrado. Otros protocolos ofrecen encapsulación, pero carecen de cifrado. A continuación, debemos introducir nuestra IP pública IPv4 en el campo de punto final remoto. Finalmente, pulsaremos "Crear".

 

 

El túnel se está aprovisionando. 

 

 

Haré clic en "Mostrar configuración" para ver los detalles. Aquí tenemos una lista de parámetros esenciales para configurar nuestro lado del túnel. 

 

 

Para configurar el túnel Wireguard, usaremos systemd-networkd. Primero, necesitamos una clave privada Wireguard. Copiaré y navegaré hasta la carpeta de configuración /etc/systemd/network/ y aquí crearé un archivo llamado wg0.key y pegaremos la clave privada. A continuación, crearemos un archivo de configuración wg0.netdev. La extensión netdev se utiliza para definir dispositivos de red virtuales o de túnel. 

 

  

Llamemos a la interfaz wg0. El tipo de interfaz es wireguard. En la sección [wireguard], configuraremos la clave privada de la interfaz con el archivo de clave wg0 que creamos anteriormente. Luego, configuraremos el puerto de escucha UDP. Para el puerto remoto, necesitamos proporcionar la clave pública. Luego, configuraremos las IP permitidas, definiremos la IP y el puerto del punto final remoto. Finalmente, configuraremos la función de mantenimiento de conexión persistente a 15 segundos. Esto garantizará que el túnel esté activo incluso si no se usa. 

 

Ahora, configuremos la IP del túnel wg0. Para ello, crearé un archivo de red wg0.network. Como recordarás, este archivo de red se utiliza para configurar direcciones IP. Emparejaremos la interfaz por el nombre wg0. Esa es la interfaz Wireguard que acabamos de configurar usando el archivo "net".

 

 

En la sección [Network] definiremos la dirección de la interfaz. Con la opción "BindCarrier", vincularé la interfaz virtual wg0 a la interfaz física ens160. La interfaz virtual solo se activará si la interfaz física y su enlace están activos. Por último, configuremos la puerta de enlace predeterminada para IPv6. El destino es cualquier dirección IPv6 y la puerta de enlace es el extremo remoto de nuestro túnel Wireguard. Guardamos la configuración y reiniciamos systemd-networkd.

 

Ahora verifiquemos nuestra configuración con una prueba de conectividad IPv6. Primero, mostraré las interfaces de red y sus direcciones IP asignadas. 

 

  

Aquí está nuestra interfaz WireGuard, ahora con una dirección unicast global IPv6 asignada. Estas direcciones se pueden enrutar a través de internet, lo que garantiza la accesibilidad global. 

 

Revisamos la tabla de enrutamiento IPv6 y hacemos ping a google.com para ver si el DNS resuelve correctamente.

 

 

Ahí está nuestra puerta de enlace predeterminada apuntando al otro extremo del túnel WireGuard. La conexión funciona. Y podemos ver que el DNS ha resuelto la dirección IPv6 de Google y que nuestra conexión a través de IPv6 funciona correctamente. Nuestro router ahora está conectado a internet mediante IPv6. Como tenemos una dirección uniccast global, nuestro router es directamente accesible desde cualquier parte del mundo. Para probarlo, me trasladaré a un cliente externo, uno con conectividad IPv6 nativa. Primero, comprobaré su dirección IPv6 mediante curl -6 ifconfig.me. 

 

 

Vemos que la dirección coincide con la devuelta por el servicio ifconfig. A continuación, volvamos a nuestro router, visualicemos su configuración de interfaz, copiemos su dirección IPv6 e intentemos un ping desde el cliente externo. No, no hay reenvío de puertos. Simplemente funciona. 

 

 

Para visualizar la ruta de red, tracemos la ruta desde el cliente hasta nuestro router. El tráfico se enruta completamente a través de IPv6. 

 

 

Finalmente, intentemos una conexión SSH a nuestro router. 👍

 

 

Para tener claridad sobre este protocolo. IPv6 elimina el NAT, asignando IPs accesibles públicamente a cada dispositivo, y como he dicho al comienzo de la publicación, la configuración del firewall es fundamental tanto a nivel del router como del host para garantizar la seguridad en una red con IPv6. 

 

En el próximo post veremos como crear subredes IPv6👋😉. 

Continue reading →