IBM Cloud Docs
Configuración y resolución de problemas de túneles IPSec

Configuración y resolución de problemas de túneles IPSec

Los túneles IPSec se utilizan para conectar de forma segura subredes de espacio privado (rfc1918) a través de una conexión negociada entre dos enrutadores o cortafuegos (comúnmente denominados puntos finales pares con referencia a IPSec). Por lo general, los dos extremos tienen conectividad de red entre sí a través de Internet. Si no tienen una conexión directa a través de Internet, uno o ambos pares pueden estar detrás de NAT/reenvío de puertos. NAT traversal debe estar activado en sus configuraciones. I

En el entorno IBM Cloud específicamente, el Vyatta (u otro dispositivo de puerta de enlace clásico) se utiliza como IBM Cloud. El punto final remoto (con referencia a IBM Cloud) es un router o firewall en el lado "on-prem".

La siguiente figura muestra una representación visual muy básica de un túnel IPSec, desde IBM Cloud Classic a on-prem, a través de Internet.

Configuración del túnel IPSec básico de Vyatta
Figura 1: Configuración del túnel IPSec básico de Vyatta

IPSec basado en rutas y políticas

Con IPSec basado en rutas, no se configuran selectores de tráfico (también llamados prefijos locales y remotos) y en su lugar se configura una interfaz VTI. Además, se configuran manualmente rutas estáticas para subredes remotas con un siguiente salto establecido en esa interfaz.

Para IPSec basado en políticas en el Vyatta, se configuran prefijos locales y remotos y no se configura una interfaz enrutable para el túnel. La interfaz VFP se añadió como función para añadir una interfaz enrutable a las configuraciones IPSec basadas en políticas. Esto elimina la necesidad de migrar a una configuración basada en rutas para utilizar NAT y reglas de cortafuegos más granulares con túneles basados en políticas.

Para obtener más información sobre las diferencias entre IPSec basado en rutas y basado en políticas, consulte el artículo IPsec site-to-site VPN configuration options.

Ejemplo de configuración de IPSec basado en rutas

El siguiente ejemplo es una configuración basada en rutas que se ejecuta en el entorno de infraestructura clásica IBM Cloud:

Lado oeste

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
set security vpn ipsec site-to-site peer 159.8.98.213 authentication id 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 159.8.98.213 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 159.8.98.213 authentication remote-id 159.8.98.213
set security vpn ipsec site-to-site peer 159.8.98.213 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 159.8.98.213 local-address 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 vti bind vti2
set security vpn ipsec site-to-site peer 159.8.98.213 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.5/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.127.132.128/26 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 2 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

Lado Este

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
et security vpn ipsec site-to-site peer 169.50.194.197 authentication id 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 169.50.194.197 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 169.50.194.197 authentication remote-id 169.50.194.197
set security vpn ipsec site-to-site peer 169.50.194.197 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 169.50.194.197 local-address 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 vti bind vti2
set security vpn ipsec site-to-site peer 169.50.194.197 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.6/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.165.125.112/28 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

Cortafuegos basados en interfaz con IPsec basado en rutas

Al aplicar conjuntos de reglas de cortafuegos a sus interfaces, tenga en cuenta cuáles serán las IP de origen y destino de un paquete al entrar y salir de una interfaz. El siguiente diagrama ilustra un paquete típico que atraviesa el Vyatta en la ruta de ida y vuelta a través de un túnel IPSec.

Tráfico IPSec
Figura 2: Flujos de tráfico IPSec

La dirección OUT de un VTI es aquella en la que el paquete será encriptado y enviado fuera del Vyatta. La dirección IN de un VTI es donde el paquete será descifrado y enviado al servidor detrás del Vyatta. Para la interfaz exterior, dp0bond1, el paquete siempre serán las direcciones IP de los extremos de los pares. Los puertos/protocolos son ESP, UDP puerto 500 y UDP puerto 4500 (si utiliza NAT-T).

La IP de origen y la IP de destino de un paquete para la dirección IN de una interfaz VLAN (VIF) deben coincidir con la dirección OUT de la VTI.

Los siguientes registros de reglas de cortafuegos ilustran el flujo:

May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond1 PASS fw rule PubIn:1 proto=(other/50) addr=198.11.194.155->159.8.98.214 macs=e4:c7:22:63:b5:41->0:0:5e:0:1:2 v4=(len:156,ttl:241,tos:00,ecn:Not,prot:50,hl:5)
May 25 05:34:07 gateway02 dataplane[4391]:  In:vti0 PASS fw rule INipsecvti0:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond0.1750 PASS fw rule OUTipsec1750:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:62,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond0.1750 PASS fw rule INipsec1750:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:64,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:vti0 PASS fw rule OUTipsecvti0:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond1 PASS fw rule PubOut:1 proto=(other/50) addr=159.8.98.214->198.11.194.155 v4=(len:156,ttl:255,tos:00,ecn:Not,prot:50,hl:5)

Cortafuegos basados en zonas con IPSec basado en rutas

Para los cortafuegos basados en zonas, las políticas que defina deben asumir que el tráfico fluye entre la interfaz VTI y la interfaz VLAN privada local (VIF) del VRA. No es necesario definir una política entre el VTI y las zonas dp0bond1.

Solución de problemas básicos

Para solucionar problemas de configuración del túnel IPSec, ejecute el siguiente proceso:

  1. Restablezca los túneles y reinicie la VPN.

    Hágalo primero si puede, ya que puede ahorrar tiempo durante un apagón. Asegúrate de recordar qué está reiniciando cada comando y su efecto sobre el resto de túneles.

  2. Comprueba la conectividad de red de extremo a extremo entre pares.

    Asegúrese de que los puertos UDP 500 y 4500 (si utiliza NAT-T), y el protocolo ESP están permitidos en la interfaz exterior para ambos peers.

  3. Comprueba el estado de la fase 1. Un estado "Abajo" podría significar:

    • No has comprobado el paso 2
    • Hay versiones de IKE, algoritmos de cifrado, algoritmos hash o identificadores IKE que no coinciden
    • Hay incompatibilidades de proveedor

  4. Comprueba el estado de la fase 2. Un estado "Abajo" (o ningún estado) podría significar:

    • La fase 1 no funciona
    • No coinciden los algoritmos de cifrado, los algoritmos hash, los selectores de tráfico o los dh-groups
    • Hay incompatibilidades entre proveedores

  5. Analice los registros IPsec disponibles en busca de indicios del problema. Los registros pueden proporcionarle información exacta sobre los desajustes y ayudarle a resolver el problema rápidamente.

  6. Revise los parches del software VRA para obtener información sobre los errores más comunes. También puede solicitar un PDF completo al IBM Cloud.

Comandos de solución de problemas

Para comprobar el estado de la fase 1:

show vpn ike sa
show vpn ike sa peer <Peer IP>

Salida de ejemplo:

vyatta@siferguson-par01-02:~$ show vpn ike sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    State    Encrypt       Hash    D-H Grp  A-Time  L-Time IKEv
    -----  ------------  --------  -------  ------  ------ ----
    up     aes256        sha2_256  14       2154    3600    2

Para comprobar el estado de la fase 2:

show vpn ipsec sa
show vpn ipsec sa peer <Peer IP>

Salida de ejemplo:

vyatta@siferguson-par01-02:~$ show vpn ipsec sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    Tunnel  Id          State  Bytes Out/In   Encrypt       Hash      DH A-Time  L-Time
    ------  ----------  -----  -------------  ------------  --------  -- ------  ------
    vti     44          up     284.3M/27.2G   aes128gcm128  null      n/a 2131    300

Para mostrar rápidamente un conjunto de información detallada sobre una conexión paritaria específica:

show vpn debug peer <Peer IP>

Salida de ejemplo:

vyatta@siferguson-par01-02:~$ show vpn debug peer 169.50.194.197
peer-169.50.194.197:  159.8.98.213...169.50.194.197  IKEv2
peer-169.50.194.197:   local:  [159.8.98.213] uses pre-shared key authentication
peer-169.50.194.197:   remote: [169.50.194.197] uses pre-shared key authentication
peer-169.50.194.197-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
peer-169.50.194.197[48]: ESTABLISHED 38 minutes ago, 159.8.98.213[500][159.8.98.213]...169.50.194.197[500][169.50.194.197]
peer-169.50.194.197[48]: IKEv2 SPIs: 65967eb4beab8549_i 1eacdfa5f926b9a3_r*, pre-shared key reauthentication in 13 minutes
peer-169.50.194.197[48]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-169.50.194.197-tunnel-vti{44}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: 9796e1b4_i db89cc43_o
peer-169.50.194.197-tunnel-vti{44}:  AES_GCM_16_128, 31436172664 bytes_i, 322001309 bytes_o, rekeying active
peer-169.50.194.197-tunnel-vti{44}:   0.0.0.0/0 === 0.0.0.0/0

{: pantalla|

Para mostrar y analizar los registros IPSec disponibles:

show log vpn ipsec
show log vpn ipsec subsystem ike-sa site-to-site peer <Peer IP>
journalctl -f -u strongswan #This live follows the end of the journal logs for ipsec
journalctl -u strongswan > /home/vyatta/journalctl-ipsec-$(date +%Y%m%d) #this creates a file so that you can parse/grep through the logs without them rotating

Para restablecer los túneles IPSec:

 reset vpn ipsec-peer <Peer IP> #reset all tunnels/phase 2's on this peer
 reset vpn ipsec-peer <Peer IP> tunnel <tunnel id> #reset phase 2 tunnel for only the specified tunnel on the specified peer
 restart vpn #This restarts the entire IPSec VPN subsystem - this affects all tunnels on all peers

Problemas habituales

La siguiente lista proporciona algunos problemas comunes que puede encontrar con los túneles IPSec.

  • Hay parámetros de fase 1 y fase 2 no coincidentes entre los dos pares.
  • Hay versiones de IKE que no coinciden.
  • La fase 1 falla con un error de autenticación mientras que todo parece coincidir.
    • Asegúrese de que establece el ID de autenticación y el ID remoto en las direcciones IP local y remota.
  • ESP y los puertos UDP 500 y 4500 no están permitidos en interfaces externas.
    • Asegúrese de que ESP y el puerto 500 están permitidos. Si utiliza NAT-T, asegúrese de que UDP 4500 está permitido.
  • Ciena recomienda utilizar la línea set security vpn ike make-before-break cuando se utilice IKEv2. Omitir esta línea puede provocar cortes.
  • El rendimiento es lento.
    • Utiliza aes128gcm o aes256gcm como algoritmo de cifrado de fase 2. Esto puede aumentar enormemente el rendimiento si el algoritmo de cifrado anterior era el estándar AES128 o AES256.
    • Desactiva el registro por paquete si está implementado. El registro por paquetes del cortafuegos puede disminuir el rendimiento.
  • Los túneles IPSec están funcionando, pero luego en rekey se caen.
    • Comprueba que PFS y dh-groups coinciden en ambos peers.
  • El comando show vpn ipsec sa muestra incrementos en una sola dirección.
    • Esto suele deberse a un enrutamiento asimétrico, en el que un lado envía datos a través del túnel y el otro no.
  • Uso de run-transition-scripts para la conmutación por error de HA en lugar del comando de sustitución notify.

Recursos adicionales

La siguiente lista proporciona algunos recursos adicionales a la hora de configurar y solucionar problemas de túneles IPSec: