En un artículo anterior, demostramos un prototipo funcional de servicios privados virtuales basados en identidad de host (HIP-VPLS). En ese momento usábamos el framework Mininet. Aquí demostramos cómo implementar el sistema en hardware real. Usaremos NanoPi R2S como plataforma para HIP-VPLS. simplemente un recordatorio. El servicio de LAN privada virtual (VPLS) proporciona un medio para 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, es necesario comprender claramente cómo abordar los problemas de seguridad, movilidad y L2.
Host Identity Protocol (HIP) se diseñó originalmente para separar las funciones duales de las direcciones IP. En otras palabras, HIP es una solución de capa 3.5 que se ubica entre la capa IP y la capa de transporte. HIP utiliza un hash de una 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 de sistemas decide rotar un par de claves RSA o ECDSA, pero eso sucederá muy pronto). HIP, por otro lado, usa direcciones IP enrutables (ya sea IPv4 o IPv6) como localizadores y se usan 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 Base Exchange o HIP BEX para abreviar) para identificarse e intercambiar claves. 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 un firewall simple basado en HIT para filtrar conexiones no confiables), intercambian claves criptográficas (HIP puede usar Diffie -Hellman y algoritmos Diffie-Hellman de curva elíptica), e incluso acertijos computacionales 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 las funciones hash; la complejidad de la solución está gobernada por respondedores en HIP BEX). HIP también es compatible con la movilidad y utiliza un proceso de negociación independiente en el que los pares informan a sus homólogos sobre los cambios en los localizadores (leyendo las direcciones IP con fines de enrutamiento).
hardware
En nuestra implementación, usamos la siguiente configuración. Para el conmutador HIP, utilizamos la plataforma informática NanoPI R2S. Usamos un conmutador SNR de 8 puertos para conectar 3 NanoPI R2S para imitar una superposición de IP en nuestra configuración. NanoPI R2S tiene dos interfaces: una para red LAN y otra para red WAN. NanoPI R2S tiene las siguientes características: 1 GB de memoria, CPU de cuatro núcleos, tarjeta SD de 32 GB. Para conectar los enrutadores, usamos conmutadores SNR (cada conmutador tiene 8 puertos de 1 GB/s y dos ranuras de factor de forma pequeño (SFP). La configuración del banco de pruebas se muestra en la siguiente figura:
sistema de despliegue
Para implementar el sistema, preparamos la imagen de Linux FriendlyWRT y la guardamos en la tarjeta SD.
Luego conectamos la tarjeta al NanoPI R2S y ejecutamos los siguientes comandos:
$ git clone
A continuación, ejecutamos los siguientes comandos en cada enrutador:
#!/bin/bash cd hip-vpls-hw echo "Updating the system" opkg update echo "Installing libraries" opkg install nano opkg install rsync opkg install python3 opkg install python3-pip opkg install python3-netifaces pip3 install pycryptodome opkg install python3-netifaces echo "Preparing directories" mkdir /opt/hip-vpls/ cd .. echo "Copying the files" rsync -rv hiplib switchd.py switchfabric.py /opt/hip-vpls/ echo "Copying the service file" cd startup cp hip-vpls /etc/init.d/ chmod +x /etc/init.d/hip-vpls /etc/init.d/hip-vpls enable /etc/init.d/hip-vpls start
Una opción de configuración interesante que debemos establecer tiene que ver con el modo promiscuo de la tarjeta Ethernet (de lo contrario, los sockets sin procesar no captarán tramas de unidifusión). Por lo tanto, modificamos la configuración de la interfaz de la siguiente manera:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd00:ab:cd::/48'
config device
option name 'eth0'
option macaddr '3e:25:61:94:f3:36'
config interface 'wan'
option device 'eth0'
option proto 'static'
option ipaddr '1.1.1.4'
option netmask '255.255.255.248'
config device
option name 'eth1'
option macaddr '3e:25:61:94:f3:37'
option promisc '1'
config interface 'lan'
option device 'eth1'
También reconfiguramos nuestras reglas de firewall para permitir todo el tráfico de red a través del enrutador.
Luego generamos HIT para cada conmutador HIP, configuramos el archivo de hosts y las reglas del firewall (la configuración se describió anteriormente aquí)
Evaluación experimental
En general, el sistema implementado se ve así:
Usando la herramienta IPERF, medimos el rendimiento entre PC3 y Server0. Los resultados no fueron tan sorprendentes: obtuvimos un rendimiento de 1,5 Mb/s en el enlace de 1 GB/s. Continuaremos mejorando el rendimiento de HIP-VPLS; actualmente estamos tratando de compilar el código fuente a código C.
