La Importancia de las Pruebas de Comunicaciones Norte-Sur en la Infraestructura de Red
En el mundo interconectado de hoy, la eficiencia y seguridad de las comunicaciones dentro de una red son fundamentales para el éxito de cualquier organización. A la hora de diseñar una infraestructura de red en entornos cloud se hace indispensable realizar pruebas que ayuden a verificar la integridad y la seguridad en el flujo de datos. En este contexto, las pruebas de comunicaciones norte-sur, que se refieren al tráfico de datos que fluye entre los dispositivos internos de una red y los recursos externos, como internet, servicios en la nube o comunicaciones entre nuestro CPD on-premise y nuestro entorno cloud, son esenciales para garantizar que las interacciones se realicen de manera óptima y segura.
A menudo, estas pruebas son difíciles de llevar a cabo porque las comunicaciones suelen estar en entornos productivos y críticos que no permiten modificaciones. Además, en mi caso, trabajo de forma remota desde casa, y frecuentemente necesito verificar que la infraestructura de comunicaciones que he diseñado en una PoC o en una Landing Zone funcione como espero.
Sea como sea, se hace necesario disponer de un hardware de comunicaciones que nos permita realizar pruebas. Estos hardware son normalmente costosos y la inversión no compensa el beneficio y mas si estamos realizando alguna prueba de concepto, pero… ¿y si te lo construyes tu mismo?
Construye tu propio router con una Raspberri PI #
Requisitos de Hardware #
Si has llegado a este punto es porque te ha surgido la necesidad, como a mi, de disponer un dispositivo que me permita levantar túneles VPN contra Azure para probar las comunicaciones y tu presupuesto no llega para adquirir un Hardware especifico (y claro está, tu entorno no es critico).
Primero vamos a ver que necesitamos a nivel de Hardware:
- Raspberri Pi Zero 2W. Coste aproximado 25€
- Memoria SD 32Gb Clase v10. Coste aproximado 10€
- Geekpi Rasperri Pi Zero 2W (es un kit que lleva una carcasa, adaptador de corriente y varios adaptadores). Coste aproximado 20€
- Adaptador de red USB (opcional). Aunque la Raspberri Pi Zero2w tiene WiFi, puede ser interesante conectarla por cable RJ45 para mejor rendimiento). Coste aproximado 10€
- Lector de Tarjetas SD. Será necesario para instalar el sistema operativo en la tarjeta SD.
Requisitos de Software #
Los requisitos a nivel de software son:
- Raspberri PI OS: Sistema Operativo basado en Debian y optimizado para Raspberri. Para este articulo estamos usando “Raspbian GNU/Linux 12 (bookworm)”.
- StrongSwan: Software VPN basada en IPSec. Es el software que utilizaremos para levantar el túnel VPN.
- Bind: Software para resolución de nombres DNS. No es obligatorio, pero si recomendado. Es obligatorio si usaremos accesos a recursos privatizados con Private Endpoint.
Instalación de Raspberri PI OS #
La instalación del sistema operativo en la tarjeta lo realizaremos mediante el software Raspberri Pi Imager que nos podremos descargar de la web oficial de Raspberri.
El proceso de instalación es bastante sencillo:
- Introducir la tarjeta en el lector SD de nuestro portátil.
- En la aplicación Raspberri PI Imager seleccionamos nuestra Raspberri PI. En nuestro caso Pi Zero 2W
- Seleccionamos el sistema operativo
- Introducir los datos solicitados: Usuario, Contraseña WIFI, etc
Preparación del Sistema Operativo #
Lo primero que tenemos que hacer es configurar nuestras tarjetas de red con IP Fija. Para ello esta versión de Raspberri OS utiliza Network Manager TUI:
nmtui
- Editamos la conexión
- Seleccionamos la interface a cambiar
- Indicamos los valores de IP, Gateway y DNS
Por último, podemos verificar nuestra configuración con nmcli. Cambiar eth0 por el valor correspondiente. Podemos verlo con nmcli o ifconfig.
nmcli device show eth0
Importante: Para el correcto funcionamiento de la resolución de nombres, la IP del primer DNS y la IP del dispositivo tienen que ser la misma.
Añadir una segunda IP para realizar resolución externa en caso de fallo del servicio Bind. En este caso hemos añadido el DNS de CloudFlare 1.1.1.1.
El método para asignar la IP fija dependerá de la distribución Linux Utilizada. El siguiente procedimiento se basa en Rasperri OS.
Una vez tengamos la IP fija, procederemos a habilitar loopback en la tarjeta de red. Esta funcionalidad sirve para que un sistema operativo pueda reenviar paquetes hacía la red y a la vez comunicarse consigo mismo.
# establecer en /etc/sysctl.conf los siguientes valores (manualmente editando el fichero o con el comando sed):
sudo sed -i 's/#net.ipv4.ip_forward=/net.ipv4.ip_forward=/' /etc/sysctl.conf
sudo sed -i 's/net.ipv4.ip_forward=0/net.ipv4.ip_forward=1/' /etc/sysctl.conf
sudo sed -i 's/#net.ipv6.conf.all.forwarding=/net.ipv6.conf.all.forwarding=/' /etc/sysctl.conf
sudo sed -i 's/net.ipv6.conf.all.forwarding=0/net.ipv6.conf.all.forwarding=1/' /etc/sysctl.conf
sudo sed -i 's/#net.ipv4.conf.all.accept_redirects = 0/net.ipv4.conf.all.accept_redirects = 0/' /etc/sysctl.conf
sudo sed -i 's/#net.ipv4.conf.all.send_redirects = 0/net.ipv4.conf.all.send_redirects = 0/' /etc/sysctl.conf
#Aplica el cambio
sudo sysctl -p
StrongSwan (VPN IPSec) #
Para la instalación de StrongSwan utilizaremos los siguientes comandos:
sudo apt install strongswan
sudo systemctl enable strongswan-starter.service
sudo systemctl enable ipsec.service
Bind (Resolución de nombres DNS) #
Para la instalación de Bind utilizaremos el siguiente comando:
sudo apt install -y bind9 bind9utils bind9-doc dnsutils
Por último nos queda instalar Bind9 para añadir resolución de nombres DNS
Habilitar DNS localmente no es un paso obligatorio, dependerá de la funcionalidad que quieras darle, pero es recomendable para poder tener resolución de nombres o quires desplegar privatización contra Azure
Preparación de Router ISP #
La conexión a Internet se establece a través del router del ISP, por lo que este dispositivo actúa como intermediario y debe ser configurado para permitir el tráfico hacia nuestro router, que no dispone de acceso directo. El esquema de red refleja esta topología en modo cascada.
Para que Azure VPN Gateway pueda establecer comunicación con la Raspberry Pi, es necesario implementar reglas de DNAT (Destination Network Address Translation) en el router del ISP. La configuración exacta dependerá del modelo y firmware instalado por el proveedor, pero en términos generales se requiere redirigir el tráfico entrante en los siguientes puertos hacia la dirección interna de la Raspberry:
- UDP 500 (IKE – Internet Key Exchange)
- UDP 4500–4511 (IPsec NAT-T – encapsulación de tráfico VPN a través de NAT)
De esta forma, el gateway de Azure podrá negociar y mantener el túnel VPN con el dispositivo, garantizando la correcta traducción de direcciones y la exposición de los puertos necesarios en la red privada.
Configuración de nuestro dispositivo #
En este punto ya tenemos los dispositivos y redes preparados para levantar el túnel IPSec. Ahora procederemos a configurar StrongSwan y Azure VPN Gateway para crear los túneles.
Azure VPN Gateway #
Primero configuraremos Azure VPN Gateway, para ello deberemos de crear dos componentes en Azure(para este tutorial damos por asumido que ya tienes desplegado y configurado tu VPN Gateway):
- Local Network Gateway: Representa la configuración de la red local (dirección IP pública y rangos de direcciones) con la que se establece una conexión VPN hacia Azure, en otras palabras, sirve como punto de referencia en Azure para enrutar tráfico seguro entre la red on‑premises y la red virtual en Azure.
La configuración de Local Network Gateway es bastante sencillo, deberemos indicarle información como grupo de recursos, nombre y región de Azure donde desplegar, pero la parte interesante para este manual es la configuración del Endpoint (IP pública de tu conexión a Internet) que puede ser una IP o un FQDN y el direccionamiento de la red local:
La IP pública se puede obtener con el comando curl ifconfig.me.
En la mayoría de los ISP, la IP Pública cambia cada vez que reinicies el router y este cambio dejara inutilizado nuestro túnel VPN. Para evitar este problema puedes registrar tu IP con un dominio y utilizar algún sistema de DNS dinámico. En mi caso he utilizado Cloudflare: https://developers.cloudflare.com/dns/manage-dns-records/how-to/managing-dynamic-ip-addresses/
- Connection: Es un recurso de Azure que contiene la configuración de la conexión VPN (tipo de conexión, claves compartidas, protocolos de enrutamiento). El objeto Connection se utiliza para establecer la relación entre nuestro gateway local (Raspberri) y un Local Network Gateway (que a su vez esta asociado a un Azure VPN Gateway).
El objeto Connection presenta dos aspectos clave a considerar:
- Connection Type, que debe configurarse como Site-to-Site (IPSec).
- Authentication Method: En este apartado indicamos la PSK (clave compartida entre los dos extremos). La PSK deberá de ser la misma en ambos extremos del túnel.
- IPsec/IKE Policy: Se establecen los parámetros para la Phase1 y Phase2 del túnel VPN.
-
Phase1:
- Encryption: AES256
- Integrity: SHA256
- DH Group: DHGroup2048
-
Phase2:
- IPSec Encrytion: AES256
- IPSec Integrity: SHA256
- PFS Group: None
-
En una conexión IKE/IPsec, en la Phase1 se establece un canal seguro y autenticado entre los dos extremos (ISAKMP SA), mientras que la Phase 2 negocia las asociaciones de seguridad IPsec que protegen el tráfico real de datos.
🔐 Detalle técnico de las fases IKE/IPsec ⚡ Fase 1 (IKE Phase 1)
- Objetivo: Crear un canal seguro y autenticado entre los dos peers de la VPN.
- Proceso:
- Se negocian algoritmos de cifrado, autenticación y el método de intercambio de claves.
- Se establece la ISAKMP Security Association (SA), que será usada para proteger la negociación posterior.
- Modos posibles:
- Modo Principal (Main Mode): más seguro, con seis mensajes de intercambio.
- Modo Agresivo (Aggressive Mode): más rápido, con tres mensajes, pero menos seguro.
- Resultado: Los peers confirman identidad y parámetros criptográficos, quedando listos para negociar el tráfico real.
🔒 Fase 2 (IKE Phase 2)
- Objetivo: Negociar las IPsec Security Associations (SA) que definirán cómo se cifrará y protegerá el tráfico de datos.
- Proceso:
- Se utiliza el canal seguro creado en Fase 1.
- Se negocian parámetros como:
- Algoritmos de cifrado (AES, 3DES, etc.).
- Algoritmos de integridad (SHA, MD5).
- Tiempo de vida de la SA.
- Identificación de subredes o tráfico que será protegido.
- Se realiza en Modo Rápido (Quick Mode), con tres mensajes de intercambio.
- Resultado: Se establecen las reglas de cifrado y autenticación para el tráfico de usuario que circulará por el túnel VPN.
StrongSwan #
Para configurar StrongSwan será necesario crear/editar dos ficheros (ambos en /etc):
- ipsec.secret: En este fichero configuraremos la PSK (Clave Compartida) que deberá de coincidir con la PSK definida anteriormente.
sudo nano /etc/ipsec.secret
La Primera IP corresponde con la IP de nuestra Raspberri y la segunda IP es la IP pública del VPN Gateway.
- ipsec.conf: En este fichero se configura el túnel en si:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
uniqueids = no
charondebug="all"
# IPSec connection with Azure VPN Basic Tier Demo Lab
conn azure-ipsec-home-vpngw1
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=192.168.200.10
leftsubnet=192.168.200.0/24
right=20.184.130.234
rightsubnet=10.90.0.0/16
ike=aes256-sha256-modp2048!
esp=aes256-sha256!
aggressive=no
keyingtries=%forever
ikelifetime=28800s
lifetime=27000s
dpddelay=30s
dpdtimeout=120s
A destacar, cuando hablamos de left, estamos hablando de la configuración local del túnel (Raspberri) y Right es la configuración de Azure. El resto de valores son los valores de encriptación para los túneles.
Una vez configurados estos valores, reiniciamos la configuración en la raspberri para que se establezca la conexión:
sudo ipsec restart #Reinicia el túnel
sudo ipsec status #Comprueba el estado del túnel
Si la configuración es correcta y el túnel queda levantada nos mostrara un texto como el siguiente:
Resolución local de nombres DNS - Bind #
Como se ha comentado anteriormente, la configuración de Bind es opcional y nos añadirá la opción de utilizar resolución de nombres en local, lo que nos abre a la opción de utilizar Private Endpoint. En este procedimiento voy a entrar de puntillas, ya que la configuración dependerá de varios parámetros y existe una gran cantidad de documentación en Internet para configurar y parametrizar Bind.
Para configurar Bind hay que realizar los siguientes pasos:
- Configurar /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
allow-recursion { any; };
allow-query-cache { any; };
//listen-on-v6 { none; };
listen-on { any; };
allow-transfer { none; };
allow-query { any; };
querylog yes;
auth-nxdomain no;
forwarders {1.1.1.1;8.8.8.8;};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
//listen-on-v6 { any; };
};
//Local Zones
zone "jpp.local" {
type master;
file "/etc/bind/zones/jpp.local.db";
notify no;
};
zone "arcdemo.local" {
type master;
file "/etc/bind/zones/arcdemo.local.db";
notify no;
};
zone "200.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/zones/192.168.200.db";
};
La primera parte del fichero establece la configuración general de Bind, por que tarjeta escuchara las consultas DNS, que recursión tendrá, etc… Para nuestro caso esta en escuchar en cualquier IP (solo tengo una) y establezco dos forwarders, para que haga la resolución de nombres que mi DNS no conozca por no ser zonas autoritativas.
En la segunda parte del fichero de configuración, establezco la configuración de las zonas DNS de las que mi Raspberri será autoritativa. En mi caso las he sacado a un fichero externo, aunque se podría haber configurado directamente aquí: Para realizar cualquier cambio, editar el fichero correspondiente y una vez guardado, reiniciar el servicio de Bind. El siguiente ejemplo muestra la configuración de una zona DNS (arcdemo.local) ubicada en /etc/bind/zones/arcdemo.local.db:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.arcdemo.local. root.arcdemo.local. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.arcdemo.local.
ns IN A 192.168.200.10
ubuntuarc001 IN A 192.168.200.131
ubuntuarc002 IN A 192.168.200.132
ubuntuarc003 IN A 192.168.200.133
ubunutarc004 IN A 192.168.200.134
arcdemo001 IN A 192.168.200.150
Una vez realizado el cambio o añadido el nuevo registro, podemos verificarlo con named-checkzone y luego habrá que reiniciar el servicio:
named-checkzone arcdemo.local /etc/bind/zones/arcdemo.local.db #Checkeamos con este comando y si no indica errores podemos reiniciar
sudo service bind9 restart
sudo service bind9 status
- Para terminar, estableceremos la **IP de nuestro equipo / Opción del DHCP ** para establecer como DNS principal nuestra Raspberri (fuera del alcance de este documento).
Conclusiones #
Para realizar pruebas de conexión desde tu casa/oficina hacía Azure solo necesitas una VM Virtual configurada con Ubuntu (y una adaptación de este documento) o adquirir por un precio bastante económico un dispositivo Raspberri Pi 2w.