introducir
Los servicios de LAN privada virtual (VPLS) proporcionan una forma de crear comunicaciones de capa 2 sobre las redes IP existentes. VPLS se puede construir usando varios métodos. Sin embargo, al crear una solución VPLS de nivel de producción, necesita una comprensión clara de cómo abordar problemas como la seguridad, la movilidad y los problemas de L2.
En este breve artículo, demostraremos cómo construir VPLS usando el Protocolo de Identidad de Host (HIP).Dado que nuestro objetivo no es construir una implementación de nivel de producción de un conmutador HIP, solo demostraremos una solución de prueba de concepto utilizando minired – Framework para la simulación de redes L2 y L3. Vale la pena mencionar que nuestro código generado también se puede implementar en hardware real (bajo ciertas condiciones; por ejemplo, nuestra implementación de HIP no tiene un mecanismo transversal NAT, ni proporciona un mecanismo de prevención de bucle L2).
Encontramos varios desafíos al construir conmutadores HIP (conmutadores implementados en el perímetro de la red). Primero, entendemos que los conmutadores HIP deben ser compatibles con el protocolo IEEE 802.1D (o sus modificaciones; esto realmente depende de la versión del protocolo compatible con el conmutador) para evitar bucles L2 en la red.Esta pregunta estaba originalmente relacionada con borrador del IETFEn segundo lugar, hay ciertos problemas con MTU, cuando los paquetes IP se fragmentan en el espacio del usuario y se inyectan en la pila de la red mediante sockets sin procesar, el kernel de Linux no puede entregar estos paquetes. Finalmente, dedicamos algún tiempo a volver a empaquetar la implementación existente del protocolo HIP en una biblioteca para que sea independiente de las redes de bajo nivel (por ejemplo, sockets sin formato, etc.). Dado que la implementación del protocolo IEEE 802.1D para nuestros conmutadores HIP aún está en curso, demostraremos el uso de VPLS basado en HIP utilizando una topología L2 sin bucles.
Protocolo de identidad del host
El protocolo de identidad de host (HIP) se diseñó originalmente para dividir las funciones duales de las direcciones IP. En otras palabras, HIP es una solución de capa 3.5 que se ubica entre las capas IP y de transporte. HIP utiliza el hash de la clave pública como identificador. Estos identificadores, o etiquetas de identidad de host (HIT), están expuestos a la capa de transporte y nunca cambian (estrictamente hablando, pueden cambiar si un administrador del sistema decide rotar los pares de claves RSA o ECDSA, pero esto sucede en raras ocasiones). HIP, por otro lado, usa una dirección IP enrutable (que puede ser IPv4 o IPv6) como localizador y se usa para pasar paquetes HIP e IPSec entre puntos finales. En general, HIP se basa en un protocolo de enlace de 4 vías (también conocido como HIP Basic Exchange o HIP BEX para abreviar) para identificar e intercambiar claves entre sí. Durante BEX, los pares negocian un conjunto de algoritmos de encriptación para usar, se identifican entre sí (dado que los HIT son permanentes y están vinculados a claves públicas, HIP puede usar firewalls simples basados en HIT para filtrar conexiones no confiables), intercambian claves secretas (HIP puede usar Diffie- Hellman y los algoritmos Diffie-Hellman de curva elíptica), e incluso computacionalmente difíciles para prevenir ataques de denegación de servicio (estos se basan en funciones hash criptográficas y la capacidad de los pares para encontrar colisiones en funciones hash; la complejidad de la solución se rige por los respondedores en HIP BEX). HIP también es compatible con la movilidad y utiliza un proceso de reconocimiento independiente en el que los pares notifican a sus pares sobre los cambios de localizador (leyendo las direcciones IP con fines de enrutamiento).
Después de BEX, se deriva un conjunto de claves de cifrado que los pares pueden usar para proteger el tráfico del plano de datos (por ejemplo, se puede usar una clave y un algoritmo de negociación para establecer una asociación de seguridad denominada IPSec).
Implemente VPLS basado en HIP en Mininet
Demostraremos la simulación de las siguientes topologías:
Dado que hemos probado la implementación con Ubuntu 20.04, a continuación asumimos que esta versión del sistema operativo Linux se utiliza para ejecutar los comandos proporcionados. Primero, debe ver el código fuente de HIP-VPLS:
$ cd ~ $ git clone https://github.com/strangebit-io/hip-vpls.git
Luego vaya al directorio que contiene HIP VPLS y ejecute el siguiente comando:
$ cd hip-vpls $ sudo bash deploy.sh
Ahora estamos listos para probar la configuración. Simplemente ejecute el siguiente comando en Mininet (el script de implementación iniciará automáticamente el emulador):
mininet> h1 ping h2
Dele a HIP BEX unos segundos antes de que termine y construya la malla completa. La salida debería verse así:
mininet> h1 ping h2 PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data. From 192.168.1.100 icmp_seq=1 Destination Host Unreachable From 192.168.1.100 icmp_seq=2 Destination Host Unreachable From 192.168.1.100 icmp_seq=3 Destination Host Unreachable From 192.168.1.100 icmp_seq=4 Destination Host Unreachable From 192.168.1.100 icmp_seq=5 Destination Host Unreachable From 192.168.1.100 icmp_seq=6 Destination Host Unreachable From 192.168.1.100 icmp_seq=7 Destination Host Unreachable 64 bytes from 192.168.1.101: icmp_seq=8 ttl=64 time=1085 ms 64 bytes from 192.168.1.101: icmp_seq=9 ttl=64 time=79.7 ms
Si necesita verificar los registros, puede ejecutar el siguiente comando:
$ cd ~/hip-vpls $ tail -f router1/hipls.log
Hay cuatro carpetas, una para cada conmutador HIP.
Luego, si necesita iniciar el emulador sin ejecutar el script de implementación, puede ejecutar el siguiente comando en la terminal:
$ cd ~/hip-vpls $ sudo python3 hipls-mn.py
Evite bucles L2 utilizando el protocolo de árbol de expansión
Todo está bien, pero la topología que simulamos arriba no tiene bucles L2 (al menos eso es lo que piensan los autores). Considere una topología ligeramente modificada:
Aquí, cuando llega una trama de transmisión de S1 a HS1 y HS2, la trama se reenviará a HS2 (por HS1) y HS1 (por HS2) en consecuencia, ya que tenemos una malla completa entre los conmutadores HIP. Según la implementación, el conmutador vuelve a inyectar la trama en el segmento L2 (S1). Pero en este caso, el conmutador reenviará la misma trama a todos los puertos excepto al puerto por el que llegó la trama. Por lo tanto, los marcos se repetirán infinitamente en la red. Para evitar esto, actualmente estamos implementando el protocolo IEEE 802.1D para conmutadores HIP. Por lo que entendemos, esto pondrá algunos enlaces en modo de bloqueo, evitando así los bucles L2.
¿Dividir o limitar la MTU?
Inicialmente, la MTU en todos los hosts (h1, h2, h3, h4) se establece en 1500 bytes. Esto significa que cuando la trama L2 llega al conmutador HIP, debe encapsularse en IPSec y luego en un paquete IPv4. Por lo tanto, cuando una trama L2 llega al conmutador HIP, ya tiene un tamaño de 1514 bytes. Ahora, si se envuelve con un encabezado adicional, el tamaño del paquete será de alrededor de 1576 bytes (suponemos un algoritmo de cifrado simétrico con un tamaño de bloque de 128 bits y un HMAC basado en SHA-256). Obviamente, dicho paquete no se puede enviar a través de una interfaz con una MTU de solo 1500 bytes, por lo que debemos fragmentar el paquete IP. Desafortunadamente, el kernel de Linux no permite fragmentar paquetes IP en el espacio del usuario y enviarlos a través de sockets sin formato (verdadero si se usa la opción de socket IP_HDRINCL). La solución es bajar la MTU de la interfaz a 1400 bytes en todos los hosts que pertenecen a VPLS. Este es un paso de configuración manual adicional.
Configuración estática de conmutadores HIP
No conocemos ninguna solución que permita la configuración dinámica de los conmutadores HIP (aunque creemos que existen protocolos propietarios para lograrlo). Sin embargo, creemos que todavía hay muchos casos de uso que solo consideran implementaciones estáticas (lo que significa que la cantidad y la ubicación de los conmutadores HIP no cambian después de la implementación).
Para configurar un conmutador HIP, se deben seguir ciertos pasos. Primero, genere un par de claves para cada conmutador HIP:
$ cd ~/hip-vpls/hiplib $ bash tools/genkey.sh gen RSA 2048
Después de generar el par de claves para cada conmutador HIP, obtenga el HIT de la clave pública:
$ cd ~/hip-vpls/ $ python3 hiplib/tools/genhit.py
Copie el HIP resultante y anote la dirección IP pública (dirección IP enrutable de Internet) de cada conmutador HIP.
Genere reglas de firewall HIP para cada par. Como estamos hablando de una malla completa con N*(N-1)/2 enlaces virtuales, necesitamos tener N*(N-1) reglas y colocarlas en el archivo hiplib/config/rules. El siguiente es un ejemplo del contenido de un archivo de reglas:
$ cat hiplib/config/rules 2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f allow 2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 allow 2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:9000:97c6:1b55:b70f:da3d:3890 allow 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f 2001:2001:c191:4f98:b087:8715:3083:5b08 allow 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 allow 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f 2001:2001:9000:97c6:1b55:b70f:da3d:3890 allow 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 2001:2001:c191:4f98:b087:8715:3083:5b08 allow 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f allow 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 2001:2001:9000:97c6:1b55:b70f:da3d:3890 allow 2001:2001:9000:97c6:1b55:b70f:da3d:3890 2001:2001:c191:4f98:b087:8715:3083:5b08 allow 2001:2001:9000:97c6:1b55:b70f:da3d:3890 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f allow 2001:2001:9000:97c6:1b55:b70f:da3d:3890 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 allow
El siguiente paso es completar el archivo que utiliza el sistema de resolución de HIP para asignar HIT a direcciones IP (nuevamente, esto debe hacerse para cada conmutador de HIP)
$ cat hiplib/config/hosts 2001:2001:c191:4f98:b087:8715:3083:5b08 192.168.3.1 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f 192.168.3.2 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 192.168.3.3 2001:2001:9000:97c6:1b55:b70f:da3d:3890 192.168.3.4
Tenga en cuenta que puede eliminar las reglas del cortafuegos si desea utilizar certificados de clave pública en la configuración de su red.
Finalmente, necesitamos completar el archivo de malla hiplib/config/mesh para cada conmutador HIP. El archivo contendrá registros N-1. Para una configuración de conmutador HIP particular, primero debe HIT su propio HIT, y el segundo HIT debe ser el HIT del conmutador HIP al que tendrá un enlace virtual. Aquí está la salida de hiplib/config/mesh para uno de los conmutadores HIP:
2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:c65e:9fc7:dd33:7ed9:da10:f85f 2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:0b8e:9c09:a674:65cc:b108:93e6 2001:2001:c191:4f98:b087:8715:3083:5b08 2001:2001:9000:97c6:1b55:b70f:da3d:3890
Con todo, el desarrollo está en progreso, pero si desea probar el prototipo, puede encontrar el código fuente aquí: https://github.com/strangebit-io/hip-vpls
Para contactar al autor, envíe un correo electrónico a [email protected]
