🥇Cómo solucionar problemas de IPsec VPN nacional. Parte 1

Situación

Es fin de semana. Estoy tomando café. El estudiante configuró una conexión VPN entre dos puntos y desapareció. Verifico: el túnel realmente existe, pero no hay tráfico en el túnel. No responde a las llamadas.

Pongo a calentar agua y me sumerjo en la solución de problemas del Gateway de C-Terra. Comparto mi experiencia y metodología.

Datos de entrada

Dos ubicaciones geográficamente separadas están conectadas por un túnel GRE. Necesitamos cifrar GRE:

Verifico el funcionamiento del túnel GRE. Para ello, ejecuta un ping desde el dispositivo R1 hasta la interfaz GRE del dispositivo R2. Este es el tráfico objetivo para el cifrado. No hay respuesta:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.

--- estadísticas de ping 1.1.1.2 ---
4 paquetes transmitidos, 0 recibidos, 100% de pérdida de paquetes, tiempo 3057ms

Reviso los logs en Gate1 y Gate2. El log informa con alegría que el túnel IPsec se ha establecido con éxito, sin problemas:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119  Conexión IPSec 5 establecida, selector de tráfico 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filtro 
IPsec:Protect:CMAP:1:LIST, Acción IPsec IPsecAction:CMAP:1, Regla IKE IKERule:CMAP:1

En las estadísticas del túnel IPsec en Gate1 veo que el túnel realmente existe, pero el contador Rcvd está en cero:

root@Gate1:~# sa_mgr show
Sesiones ISAKMP: 0 iniciadas, 0 respondidas

Conexiones ISAKMP:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Estado Enviado Recibido
1 3 (10.10.10.251,500)-(10.10.10.252,500) activo 1070 1014

Conexiones IPsec:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Protocolo Tipo Acción Enviado Recibido
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP túnel 480 0

Estoy solucionando problemas en C-Terra de esta manera: busco dónde se pierden los paquetes en el camino de R1 a R2. En el proceso (spoiler) encuentro un error.

Solución de problemas

Paso 1. ¿Qué recibe Gate1 de R1?

Utilizo el sniffer de paquetes integrado – tcpdump. Inicia el sniffer en la interfaz interna (Gi0/1 en notación similar a Cisco o eth1 en notación de OS Debian):

root@Gate1:~# tcpdump -i eth1

tcpdump: salida detallada suprimida, use -v o -vv para un decodificación completa del protocolo
escuchando en eth1, tipo de enlace EN10MB (Ethernet), tamaño de captura 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 1, longitud 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 2, longitud 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 3, longitud 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 4, longitud 64

Veo que Gate1 recibe paquetes GRE de R1. Sigo adelante.

Paso 2. ¿Qué hace Gate1 con los paquetes GRE?

Con la utilidad klogview, reviso qué está sucediendo con los paquetes GRE dentro VPN del controlador de C-Terra:

root@Gate1:~# klogview -f 0xffffffff

resultado de filtración para paquete saliente 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: cadena 4 "IPsecPolicy:CMAP", filtro 8, id de evento IPsec:Protect:CMAP:1:LIST, estado PASS
encapsulando con SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
paquete saliente 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulado

Veo que el tráfico GRE objetivo (proto 47) 172.16.0.1 -> 172.17.0.1 pasó (PASS) bajo la regla de cifrado LIST en la política criptográfica CMAP y fue cifrado (encapsulado). Luego, el paquete fue enrutado (pasado). No hay tráfico de respuesta en la salida de klogview.

Estoy revisando las listas de acceso en el dispositivo Gate1. Veo una lista de acceso LIST, que define el tráfico objetivo para el cifrado, lo que significa que no hay reglas de MÁ configuradas:

Gate1#show access-lists
Lista de acceso IP extendida LIST
    10 permitir gre host 172.16.0.1 host 172.17.0.1

Conclusión: el problema no está en el dispositivo Gate1.

Más sobre klogview

El controlador VPN procesa todo el tráfico de red, no solo aquel que debe ser cifrado. Estos mensajes son visibles en klogview, si el controlador VPN procesó el tráfico de red y lo envió en formato no cifrado:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

resultado de filtración para paquete saliente 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: cadena 4 "IPsecPolicy:CMAP": no coincide
paquete saliente 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrado

Veo que el tráfico ICMP (proto 1) 172.16.0.1->172.17.0.1 no coincidió (no match) con las reglas de cifrado de la política criptográfica CMAP. El paquete fue enrutado (pasado) en formato abierto.

Paso 3. Qué recibe Gate2 de Gate1

Ejecutando un sniffer en la interfaz WAN (eth0) de Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: salida detallada suprimida, use -v o -vv para una decodificación completa del protocolo
escuchando en eth0, tipo de enlace EN10MB (Ethernet), tamaño de captura 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), longitud 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), longitud 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), longitud 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), longitud 140

Veo que Gate2 recibe paquetes ESP de Gate1.

Paso 4. Qué hace Gate2 con los paquetes ESP

Ejecutando la utilidad klogview en Gate2:

root@Gate2:~# klogview -f 0xffffffff
resultado de filtración para paquete entrante 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: cadena 17 "FilterChain:L3VPN", filtro 21, estado DROP
paquete entrante descartado 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

Veo que los paquetes ESP (proto 50) fueron descartados (DROP) por la regla (L3VPN) del firewall. Me aseguro de que la lista de acceso L3VPN realmente esté vinculada a Gi0/0:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 está activo, el protocolo de línea está activo
  Dirección de Internet es 10.10.10.252/24
  MTU es de 1500 bytes
  Lista de acceso saliente no está configurada
  Lista de acceso entrante es L3VPN

He encontrado el problema.

Paso 5. Qué está mal con la lista de acceso

Veo cómo es la lista de acceso L3VPN:

Gate2#show access-list L3VPN
Lista de acceso IP extendida L3VPN
    10 permitir udp host 10.10.10.251 any eq isakmp
    20 permitir udp host 10.10.10.251 any eq non500-isakmp
    30 permitir icmp host 10.10.10.251 any

Veo que se permiten paquetes ISAKMP, así que se establece el túnel IPsec. Sin embargo, no hay una regla que permita ESP. Parece que el estudiante confundió icmp y esp.

Corregiré la lista de acceso:

Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 any

Paso 6. Verifico la funcionalidad

Primero me aseguro de que la lista de acceso L3VPN sea correcta:

Gate2#show access-list L3VPN
Lista de acceso IP extendida L3VPN
    10 permitir udp host 10.10.10.251 any eq isakmp
    20 permitir udp host 10.10.10.251 any eq non500-isakmp
    30 permitir esp host 10.10.10.251 any

Ahora desde el dispositivo R1 inicio el tráfico objetivo:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms

--- Estadísticas de ping de 1.1.1.2 ---
4 paquetes transmitidos, 4 recibidos, 0% pérdida de paquetes, tiempo 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

Victoria. El túnel GRE se ha establecido. El contador de tráfico entrante en las estadísticas IPsec no es cero:

root@Gate1:~# sa_mgr show
Sesiones ISAKMP: 0 iniciadas, 0 respondidas

Conexiones ISAKMP:
Num Conn-id (Dirección Local, Puerto)-(Dirección Remota, Puerto) Estado Enviado Recibido
1 3 (10.10.10.251,500)-(10.10.10.252,500) activo 1474 1350

Conexiones IPsec:
Num Conn-id (Dirección Local, Puerto)-(Dirección Remota, Puerto) Protocolo Acción Tipo Enviado Recibido
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

En el gateway Gate2, aparecieron mensajes en el klogview indicando que el tráfico objetivo 172.16.0.1->172.17.0.1 fue descifrado correctamente (PASS) por la regla LIST en el mapa criptográfico CMAP:

root@Gate2:~# klogview -f 0xffffffff
resultado de filtración para el paquete entrante 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: cadena 18 "IPsecPolicy:CMAP", filtro 25, id de evento IPsec:Proteger:CMAP:1:LIST, estado PASS
paquete entrante 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: descapsulado

Resultados

El estudiante estropeó la salida.
Cuidado con las reglas MЭ.

Ingeniero anónimo
t.me/anonimous_engineer

Fuente: habr.com