Distinguir la fragmentación de IKEv2 de un problema de cadena de certificados

El túnel funcionaba en la red de la oficina y se atasca en casa, y el registro muestra que el primer intercambio se completa antes de que ocurra cualquier otra cosa. Ese patrón apunta al intercambio de autenticación, no a las credenciales: una cadena de certificados hace que ese mensaje sea mucho más grande que el anterior, y una ruta que no tolera datagramas grandes lo descartará en silencio. Hay dos mecanismos de fragmentación distintos implicados, y saber cuál está mirando decide la solución.

Dos mecanismos de fragmentación, un síntoma

IKEv2 tiene su propia extensión de fragmentación, definida en RFC 7383, que divide los mensajes IKE protegidos en mensajes IKE más pequeños. Los pares negocian esa capacidad, y un mensaje lo reensambla la implementación de IKE en lugar de la capa IP.

La fragmentación IP ordinaria es un mecanismo distinto con un modo de fallo distinto. Un enrutador entre los pares fragmenta un datagrama grande, o lo descarta y devuelve un mensaje ICMP que puede que nunca llegue al emisor. Algunas redes descartan fragmentos en silencio, y algunos dispositivos intermedios manejan el primer fragmento pero no el resto. Desde el punto de vista de la aplicación, los tres casos parecen idénticos.

La travesía de NAT añade una tercera variable, porque entonces ESP se envuelve en UDP y el paquete exterior se hace más grande mientras parece tráfico UDP normal en el puerto 4500. Una ruta que deja pasar bien el UDP todavía puede fallar con un datagrama que ya no cabe.

Lea el intercambio que falló

Busque la transición, no el error. Un registro que muestra el intercambio inicial enviado y respondido, seguido de nada, le dice que el siguiente mensaje nunca se completó. Suba temporalmente el nivel de registro y compare los tamaños reportados en ambos pares.

Lo que quiere establecer es si el respondedor vio la solicitud. Si el iniciador envió algo y el respondedor no tiene ningún registro de ello, el problema es la entrega. Si el respondedor analizó una solicitud y la rechazó, el problema es el propio certificado, y la fragmentación es una distracción. Esa distinción vale más que una página de mensajes de tiempo de espera.

Cambie la ruta, no el certificado

Pruebe el mismo cliente, el mismo certificado y la misma configuración desde otra red. Un punto de acceso móvil suele ser la segunda ruta más barata, y es genuinamente distinto del enlace de la oficina, no solo nominalmente.

Si el apretón de manos se completa por la segunda ruta, la cadena de certificados está bien y la primera ruta es la variable. Si falla de forma idéntica en ambas, deje de probar redes y mire los mensajes mismos. Esa única comparación elimina alrededor de la mitad de las explicaciones posibles.

Mida el intercambio antes de editar nada

Obtenga el tamaño de la cadena y el tamaño de la ruta. Ambos números limitan lo que el apretón de manos puede enviar, y ambos son baratos de medir:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Los dos primeros dan el número de certificados y el tamaño del archivo, que es un indicador razonable de cuán grande será el mensaje de autenticación. La sonda ping informa si un datagrama de ese tamaño sobrevive a la ruta, y los contadores de la interfaz muestran si se descartaron fragmentos en su extremo. En Windows, la sonda equivalente es un ping con la marca do-not-fragment y un tamaño de carga útil explícito.

Repita la sonda hacia abajo hasta que tenga éxito. El tamaño mayor que pasa es el presupuesto de trabajo para esa ruta, y es más útil que cualquier valor predeterminado publicado.

Arregle la capa que realmente está rota

Si la ruta descarta datagramas grandes, active la fragmentación IKE en ambos pares y confirme que la extensión se negoció, no solo se ofreció. Si la ruta maneja mal los fragmentos a nivel de IP, el arreglo pertenece allí o al MTU de la interfaz exterior, no al almacén de certificados.

Si la cadena es innecesariamente larga, recórtela a los certificados intermedios que un par realmente necesita. Quitar una raíz en la que el cliente ya confía es un mantenimiento razonable; quitar un intermedio no lo es, y desactivar la verificación para reducir un mensaje cambia un problema de entrega por uno de seguridad.

Anote qué mecanismo cambió y cómo se veía el apretón de manos después. La siguiente aparición suele ser en otra red con el mismo síntoma, y la nota es lo que convierte dos horas en diez minutos.