tutoriales.com

Configuración de una VPN Site-to-Site con IPsec: Interconectando Redes Remotas de Forma Segura

Este tutorial te guiará a través del proceso de configuración de una VPN Site-to-Site utilizando el protocolo IPsec. Aprenderás a establecer túneles seguros para conectar dos redes locales distantes, permitiendo la comunicación privada y cifrada entre ellas como si estuvieran en la misma ubicación física. Ideal para empresas con múltiples sucursales o usuarios avanzados que buscan conectar sus redes domésticas.

Intermedio15 min de lectura40 views
Reportar error

🚀 Introducción a las VPN Site-to-Site con IPsec

En el mundo conectado de hoy, la necesidad de comunicación segura entre ubicaciones geográficamente dispersas es más crucial que nunca. Las Redes Privadas Virtuales (VPN) Site-to-Site (sitio a sitio) son la solución perfecta para interconectar dos o más redes locales como si fueran una sola, creando un túnel cifrado a través de una red pública como Internet.

A diferencia de las VPN de cliente a sitio (Client-to-Site), que conectan usuarios individuales a una red, las VPN Site-to-Site conectan redes enteras. Esto significa que todos los dispositivos dentro de una red local pueden comunicarse de forma segura con todos los dispositivos de otra red local remota sin necesidad de configurar VPNs individuales en cada máquina.

En este tutorial, nos centraremos en la implementación de una VPN Site-to-Site utilizando el protocolo IPsec (Internet Protocol Security). IPsec es un conjunto de protocolos que proporcionan servicios de seguridad a nivel de la capa de red del modelo OSI. Ofrece autenticación, integridad de datos y confidencialidad para los paquetes IP, lo que lo convierte en la elección preferida para conexiones VPN robustas y de grado empresarial.

¿Por qué IPsec para Site-to-Site? 🎯

IPsec es la base de muchas soluciones VPN debido a su fortaleza y flexibilidad. Aquí algunas de sus ventajas clave:

  • Seguridad Integral: Proporciona un cifrado fuerte y autenticación mutua entre los extremos del túnel.
  • Transparencia: Opera a nivel de capa de red, lo que lo hace transparente para las aplicaciones y los usuarios finales.
  • Estándar de la Industria: Es un estándar abierto y ampliamente adoptado, garantizando compatibilidad entre diferentes proveedores.
  • Flexibilidad: Permite elegir diferentes algoritmos de cifrado y autenticación, adaptándose a diversas necesidades de seguridad.
🔥 Importante: Aunque existen otras tecnologías VPN (como SSL/TLS), IPsec es el estándar de oro para las conexiones Site-to-Site debido a su robustez, rendimiento y capacidad de cifrado a nivel de paquete IP.

📖 Conceptos Fundamentales de IPsec

Antes de sumergirnos en la configuración, es vital entender los componentes clave de IPsec:

1. Fases de Negociación IPsec

IPsec establece una conexión segura en dos fases:

  • Fase 1 (IKEv1 o IKEv2): También conocida como la Fase de Intercambio de Claves por Internet (Internet Key Exchange). El objetivo principal de la Fase 1 es establecer una Asociación de Seguridad (SA) IKE, que es un canal de comunicación seguro y autenticado. Durante esta fase, los peers (puntos finales del túnel VPN) se autentican entre sí y negocian los parámetros para proteger la comunicación de la Fase 2. Esto incluye el método de autenticación (clave precompartida, certificados), algoritmos de cifrado y hashing para la propia conexión IKE.

    • Modo Principal: Más seguro, ofrece protección de identidad en el intercambio inicial. Utiliza 6 mensajes.
    • Modo Agresivo: Más rápido, pero la identidad del peer no está cifrada. Utiliza 3 mensajes.
  • Fase 2 (IPsec SA): Una vez que la Fase 1 ha establecido un canal seguro, la Fase 2 negocia los parámetros para proteger el tráfico de datos real que fluirá a través del túnel VPN. Aquí se establecen las Asociaciones de Seguridad IPsec (SA IPsec). Esto incluye los algoritmos de cifrado y autenticación para los datos, el modo IPsec (Transporte o Túnel) y el PFS (Perfect Forward Secrecy).

2. Protocolos IPsec

IPsec utiliza dos protocolos principales para proteger los datos:

  • Encapsulating Security Payload (ESP): Proporciona confidencialidad (cifrado), autenticación de datos, integridad y anti-replay. Es el protocolo más comúnmente utilizado para VPNs Site-to-Site ya que cifra la carga útil completa del paquete IP original y añade una nueva cabecera IPsec.
  • Authentication Header (AH): Proporciona autenticación de datos, integridad y anti-replay, pero NO confidencialidad (no cifra los datos). Se utiliza menos en VPNs donde la privacidad es una prioridad.
📌 Nota: Para las VPN Site-to-Site, el protocolo ESP es casi siempre la elección debido a la necesidad de cifrar el tráfico.

3. Modos de Operación IPsec

  • Modo Túnel (Tunnel Mode): Es el modo estándar para VPNs Site-to-Site. El paquete IP original se encapsula completamente dentro de un nuevo paquete IP. Esto significa que la cabecera IP original se cifra junto con la carga útil, y se añade una nueva cabecera IP externa. Es ideal para conectar redes enteras.
  • Modo Transporte (Transport Mode): Solo se cifra y/o autentica la carga útil del paquete IP original. La cabecera IP original permanece inalterada. Se usa principalmente para proteger comunicaciones end-to-end entre dos hosts directamente, no para redes completas.
💡 Consejo: Para una VPN Site-to-Site, siempre configuraremos IPsec en *Modo Túnel* utilizando el protocolo *ESP*.

4. Perfect Forward Secrecy (PFS)

El PFS es una característica de seguridad que asegura que si una clave de sesión se ve comprometida, esto no comprometerá las claves de sesiones anteriores o futuras. Cada sesión utiliza una clave generada de forma independiente. Esto se logra típicamente mediante el intercambio de claves de Diffie-Hellman en la Fase 2.


🛠️ Requisitos y Topología de Ejemplo

Para este tutorial, asumiremos la siguiente topología de red. Necesitarás dos dispositivos de borde (routers, firewalls o servidores Linux con soporte IPsec) que actúen como gateways VPN, uno en cada sitio.

Sitio A (Oficina Principal)

  • Red Local: 192.168.1.0/24
  • Gateway VPN (Router A):
    • Interfaz WAN (Pública): 203.0.113.1 (IP Pública)
    • Interfaz LAN (Privada): 192.168.1.254

Sitio B (Sucursal Remota)

  • Red Local: 192.168.2.0/24
  • Gateway VPN (Router B):
    • Interfaz WAN (Pública): 198.51.100.1 (IP Pública)
    • Interfaz LAN (Privada): 192.168.2.254
Túnel VPN IPsec Sitio A 192.168.1.0/24 Router A LAN: 192.168.1.254 WAN: 203.0.113.1 Internet Router B WAN: 198.51.100.1 LAN: 192.168.2.254 Sitio B 192.168.2.0/24

Lista de Verificación Pre-configuración ✅

  • Ambos gateways VPN deben tener direcciones IP públicas estáticas (o DNS dinámico configurado y actualizándose correctamente). Para un entorno de producción, las IPs estáticas son altamente recomendadas.
  • Permitir el tráfico de los puertos UDP 500 (IKE) y UDP 4500 (NAT Traversal) en los firewalls externos de cada gateway VPN si están detrás de otro NAT o firewall.
  • Identificar las redes locales que se interconectarán (192.168.1.0/24 y 192.168.2.0/24 en nuestro ejemplo).
  • Definir una clave precompartida (PSK) fuerte y compleja que se usará para la autenticación en la Fase 1. Ejemplo: MiClaveUltraSecretaParaVPN!@#
⚠️ Advertencia: NUNCA uses una clave precompartida débil o fácil de adivinar. Una PSK comprometida invalida toda la seguridad del túnel VPN.

⚙️ Configuración Paso a Paso (Ejemplo con Strongswan en Linux)

La configuración de IPsec puede variar ligeramente dependiendo del dispositivo (Cisco, Juniper, FortiGate, pfSense, Strongswan, etc.). Aquí usaremos Strongswan, una implementación popular y de código abierto de IPsec para sistemas Unix-like (como Linux), que es muy versátil y te dará una buena base para entender los conceptos.

Asumiremos que Strongswan ya está instalado en ambos Router A y Router B. Si no, puedes instalarlo en Debian/Ubuntu con sudo apt install strongswan.

Paso 1: Configurar el Archivo /etc/ipsec.conf en el Router A

Este archivo define las conexiones IPsec. Abrimos el archivo:

sudo nano /etc/ipsec.conf

Y añadimos la siguiente configuración:

conn oficina_remota
  left=203.0.113.1                 # IP Pública de Router A (Local)
  leftsubnet=192.168.1.0/24        # Subred Local de Sitio A
  right=198.51.100.1               # IP Pública de Router B (Remoto)
  rightsubnet=192.168.2.0/24       # Subred Remota de Sitio B
  ike=aes256-sha2_256-modp1024!    # Fase 1: Cifrado, Hash, Grupo DH (ej. AES256, SHA256, DH group 2 - 1024 bits)
  esp=aes256-sha2_256!             # Fase 2: Cifrado, Hash (ej. AES256, SHA256)
  ikelifetime=8h                   # Tiempo de vida SA Fase 1
  lifetime=1h                      # Tiempo de vida SA Fase 2
  keyexchange=ikev2                # Usar IKEv2 para la negociación
  authby=secret                    # Autenticación por clave precompartida
  type=tunnel                      # Modo túnel
  dpddelay=30s                     # Retardo DPD (Dead Peer Detection)
  dpdtimeout=120s                  # Timeout DPD
  dpdaction=restart                # Acción DPD si el peer no responde
  auto=start                       # Iniciar la conexión automáticamente
  compress=no                      # No compresión
  pfs=yes                          # Habilitar Perfect Forward Secrecy
📌 Nota: Los algoritmos `ike` y `esp` (`aes256-sha2_256-modp1024!` y `aes256-sha2_256!`) son ejemplos. Deben ser acordados y *exactamente iguales* en ambos extremos del túnel para que la negociación sea exitosa. Puedes usar algoritmos más modernos como `aes256gcm16-sha2_256-modp3072` para una mayor seguridad si ambos *peers* lo soportan.

Paso 2: Configurar el Archivo /etc/ipsec.secrets en el Router A

Este archivo contiene las claves precompartidas. Abrimos el archivo:

sudo nano /etc/ipsec.secrets

Y añadimos la PSK:

203.0.113.1 198.51.100.1 : PSK "MiClaveUltraSecretaParaVPN!@#"

Aquí especificamos las IPs públicas de ambos peers y la clave precompartida. Asegúrate de que la clave sea la misma que la configurada en el Router B.

Paso 3: Configurar el Archivo /etc/ipsec.conf en el Router B

En el Router B, la configuración es simétrica, pero los roles left y right se invierten. Abrimos el archivo:

sudo nano /etc/ipsec.conf

Y añadimos la configuración:

conn oficina_principal
  left=198.51.100.1                # IP Pública de Router B (Local)
  leftsubnet=192.168.2.0/24        # Subred Local de Sitio B
  right=203.0.113.1                # IP Pública de Router A (Remoto)
  rightsubnet=192.168.1.0/24       # Subred Remota de Sitio A
  ike=aes256-sha2_256-modp1024!    # Debe coincidir con Router A
  esp=aes256-sha2_256!             # Debe coincidir con Router A
  ikelifetime=8h                   # Debe coincidir con Router A
  lifetime=1h                      # Debe coincidir con Router A
  keyexchange=ikev2                # Debe coincidir con Router A
  authby=secret                    # Debe coincidir con Router A
  type=tunnel                      # Debe coincidir con Router A
  dpddelay=30s                     # Debe coincidir con Router A
  dpdtimeout=120s                  # Debe coincidir con Router A
  dpdaction=restart                # Debe coincidir con Router A
  auto=start                       # Iniciar la conexión automáticamente
  compress=no                      # No compresión
  pfs=yes                          # Habilitar Perfect Forward Secrecy

Paso 4: Configurar el Archivo /etc/ipsec.secrets en el Router B

Abrimos el archivo:

sudo nano /etc/ipsec.secrets

Y añadimos la PSK (la misma que en el Router A):

198.51.100.1 203.0.113.1 : PSK "MiClaveUltraSecretaParaVPN!@#"

Paso 5: Habilitar el Reenvío IP (IP Forwarding) en Ambos Routers

Para que los routers puedan reenviar el tráfico entre las subredes, debes habilitar el reenvío IP en el kernel. Esto se hace modificando el archivo /etc/sysctl.conf.

sudo nano /etc/sysctl.conf

Busca la línea net.ipv4.ip_forward y asegúrate de que esté configurada a 1 (descomenta si es necesario):

net.ipv4.ip_forward=1

Guarda el archivo y aplica los cambios inmediatamente con:

sudo sysctl -p

Paso 6: Ajustar Reglas de Firewall (IPTables)

Debes asegurarte de que tu firewall (iptables en Linux) permita el tráfico IPsec. Esto es crítico. Aquí tienes un ejemplo básico para ambos routers. Ajusta según tu configuración de firewall existente.

# Permitir tráfico IKE (Fase 1)
sudo iptables -A INPUT -p udp --dport 500 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 500 -j ACCEPT

# Permitir tráfico IKE con NAT-T (si hay NAT de por medio, puerto 4500)
sudo iptables -A INPUT -p udp --dport 4500 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 4500 -j ACCEPT

# Permitir tráfico ESP (Fase 2 - protocolo IP 50)
sudo iptables -A INPUT -p 50 -j ACCEPT
sudo iptables -A OUTPUT -p 50 -j ACCEPT

# Permitir tráfico AH (Fase 2 - protocolo IP 51, si se usa, pero ESP es más común)
# sudo iptables -A INPUT -p 51 -j ACCEPT
# sudo iptables -A OUTPUT -p 51 -j ACCEPT

# Permitir tráfico entre la interfaz LAN y la interfaz de túnel (que Strongswan creará)
# Esto es un ejemplo. Las interfaces pueden ser diferentes.
# Asumiendo 'eth0' para WAN y 'eth1' para LAN
sudo iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -d 192.168.2.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT # En Router A
sudo iptables -A FORWARD -i eth0 -o eth1 -s 192.168.2.0/24 -d 192.168.1.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT # En Router B

# Guardar las reglas (depende de tu distribución, ej. iptables-persistent)
sudo apt install iptables-persistent
sudo netfilter-persistent save
⚠️ Advertencia: Las reglas de firewall son cruciales. Un firewall mal configurado es una de las principales causas de fallos en la conexión VPN. Asegúrate de adaptar estas reglas a tu infraestructura específica y de que sean persistentes tras un reinicio.

Paso 7: Reiniciar el Servicio Strongswan

Después de configurar los archivos, reinicia el servicio Strongswan en ambos routers:

sudo systemctl restart strongswan

Si el servicio no inicia o tienes errores, revisa los logs de Strongswan (sudo journalctl -u strongswan o /var/log/syslog).

✨ Verificación y Solución de Problemas

Una vez que ambos servicios Strongswan estén en marcha, es hora de verificar la conexión.

Verificar el Estado del Túnel

En ambos routers, puedes verificar el estado del túnel con el siguiente comando:

sudo ipsec status

Deberías ver una salida similar a esta (indicando que la SA de IKE y la SA de ESP están establecidas):

Status of IKE charon daemon (strongSwan 5.x.x, Linux x.x.x, x86_64):
  uptime: 12 minutes, since Jan 01 12:00:00 2023
  ... (omitted details) ...
Connections:
 oficina_remota:  203.0.113.1...198.51.100.1  IKEv2, dpddelay=30s
 oficina_remota:   local:  [203.0.113.1] uses pre-shared key authentication
 oficina_remota:   remote: [198.51.100.1] uses pre-shared key authentication
 oficina_remota:   child:  192.168.1.0/24 === 192.168.2.0/24 TUNNEL, ESP:AES_CBC_256/HMAC_SHA2_256_128
Security Associations (1 up, 0 connecting):
 oficina_remota[1]: ESTABLISHED 10 minutes ago, 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]
 oficina_remota[1]: IKEv2 SPIs: fc1a...c64e_i a71b...d9f3_r, pre-shared key, DPD: active
 oficina_remota[1]: IKE SA:  AES_CBC_256/HMAC_SHA2_256_128/MODP_1024
 oficina_remota[1]: CHILD_SA: 192.168.1.0/24 === 192.168.2.0/24 TUNNEL, ESP:AES_CBC_256/HMAC_SHA2_256_128

Si ves ESTABLISHED, ¡felicidades! El túnel VPN está activo.

Probar la Conectividad

Desde un host en la red 192.168.1.0/24 (por ejemplo, 192.168.1.10), intenta hacer ping a un host en la red 192.168.2.0/24 (por ejemplo, 192.168.2.10):

ping 192.168.2.10

Si los pings son exitosos, el tráfico está fluyendo correctamente a través del túnel VPN.

💡 Consejo: Asegúrate de que los firewalls internos de los hosts (ej. Windows Defender, firewalld en Linux) no estén bloqueando los pings o las conexiones. Temporalmente deshabilítalos si tienes problemas para aislar la causa.

Solución de Problemas Comunes Troubleshooting 🔍

  • El túnel no se establece:
    • Verifica los logs de Strongswan: sudo journalctl -u strongswan -f te dará información en tiempo real sobre la negociación IKE.
    • Firewall: Es la causa más común. Asegúrate de que UDP 500, UDP 4500 y protocolo IP 50 (ESP) estén permitidos en ambos sentidos en ambos gateways.
    • Clave Precompartida: Verifica que la PSK sea exactamente igual en ambos archivos ipsec.secrets.
    • Parámetros IKE/ESP: Confirma que los algoritmos de cifrado, hashing y grupos Diffie-Hellman (DH) sean idénticos en ambos archivos ipsec.conf para las fases 1 y 2.
    • IPs y Subredes: Revisa que las IPs públicas (left/right) y las subredes (leftsubnet/rightsubnet) estén correctamente definidas y correspondan a la topología.
    • IP Forwarding: Asegúrate de que net.ipv4.ip_forward=1 esté habilitado y aplicado en ambos routers.
  • El túnel se establece pero no hay tráfico:
    • Reglas de FORWARD del firewall: Las reglas iptables -A FORWARD deben permitir el tráfico entre las subredes locales a través de la interfaz del túnel.
    • Rutas de red: Asegúrate de que los hosts en las redes locales tengan su gateway predeterminado apuntando a la IP LAN de su respectivo router VPN. Los routers gestionarán el enrutamiento a través del túnel.
    • MTU: En casos raros, problemas de fragmentación de paquetes pueden ser causados por una MTU (Maximum Transmission Unit) demasiado grande. Considera ajustar la MTU del túnel a un valor más bajo (ej. 1360 o 1400 bytes) si experimentas pérdidas de paquetes.

🔒 Consideraciones de Seguridad Adicionales

Una vez que tu VPN Site-to-Site esté funcionando, considera estas prácticas recomendadas para mejorar la seguridad:

  • Algoritmos Fuertes: Usa siempre los algoritmos de cifrado y hashing más modernos y seguros que soporten tus dispositivos (ej. AES256-GCM, SHA384, DH group 14 o superior).
  • Perfect Forward Secrecy (PFS): Asegúrate de que pfs=yes esté configurado en ipsec.conf para proteger las sesiones futuras incluso si una clave se ve comprometida.
  • Auditoría y Monitoreo: Configura el registro (logging) de Strongswan y monitoriza activamente los logs para detectar actividades sospechosas o fallos en el túnel.
  • Actualizaciones: Mantén tus sistemas operativos y el software Strongswan (o el firmware de tu router/firewall) siempre actualizados para protegerte contra vulnerabilidades conocidas.
  • Acceso Mínimo: Restringe el acceso a la configuración de los routers VPN solo al personal autorizado. Usa SSH con autenticación de clave y deshabilita el acceso por contraseña si es posible.
  • Políticas de Firewall: Aunque el túnel cifra el tráfico, aún puedes aplicar políticas de firewall en la capa de aplicación para controlar qué tipo de tráfico se permite entre las redes (ej. solo permitir tráfico HTTP/S entre la oficina principal y el servidor web de la sucursal).
¿Por qué Strongswan y no otra solución? Strongswan es una excelente opción de código abierto que se ejecuta en Linux, lo que te da un control granular y la flexibilidad de usar hardware commodity. Es robusto, ampliamente probado y soporta los estándares IPsec más recientes. Además, entender su configuración te proporcionará una base sólida para configurar cualquier otro dispositivo VPN con IPsec, ya que los conceptos subyacentes son los mismos. Sin embargo, si ya dispones de routers/firewalls de hardware específicos, lo más probable es que su interfaz web o CLI te permita configurar IPsec de forma similar.
95% Completado

Este tutorial te ha proporcionado los conocimientos y pasos necesarios para establecer una VPN Site-to-Site segura y eficiente con IPsec usando Strongswan. Interconectar redes remotas nunca había sido tan accesible y seguro.

Tutoriales relacionados

Comentarios (0)

Aún no hay comentarios. ¡Sé el primero!