ike-scan no recibe respuesta de una puerta de enlace IPsec en funcionamiento

La puerta de enlace atiende teléfonos y portátiles cada día, y aun así ike-scan informa de que ningún host respondió. Esa salida parece la prueba de que falta IPsec en el dispositivo. Normalmente significa que el dispositivo descartó todas las propuestas de la sonda y eligió no responder nada. El silencio es una respuesta, y es la menos informativa que la herramienta puede darte.

Trabaja tres preguntas separadas: ¿llegó el paquete, coincidió alguna propuesta y algo más rechazó al par?

Paso 1: lee la propuesta que envía la herramienta

El modo principal comienza con una carga SA que enumera las transformaciones que aceptará el iniciador, e ike-scan llena esa lista desde un conjunto predeterminado compilado. El conjunto predeterminado es deliberadamente antiguo: DES y 3DES para el cifrado, MD5 y SHA1 para el resumen, grupos 1 y 2 para el intercambio de claves, claves precompartidas para la autenticación. Sin AES, sin SHA-2, sin grupo 14. Una puerta de enlace configurada para AES-256 con SHA-256 y modp2048 no comparte nada con eso.

Algunas implementaciones responden a una sonda que no coincide con una notificación NO-PROPOSAL-CHOSEN. Otras simplemente la descartan, algo común en equipos que tratan a los pares desconocidos como ruido. En cualquier caso el escaneo no imprime nada, y esa nada es idéntica a lo que parece un UDP 500 filtrado desde fuera, como la documentación del proyecto ike-scan deja claro sobre el conjunto predeterminado.

Paso 2: ofrece una propuesta moderna

Sustituye el conjunto predeterminado con --trans. La forma de atributos toma los números de atributo IKE directamente: 1 para el cifrado, 2 para el resumen, 3 para la autenticación, 4 para el grupo y 14 para la longitud de clave cuando el algoritmo acepta una. Lo que sale es una línea que puedes leer en voz alta en una revisión de cambios.

La forma posicional lleva los mismos valores en orden y evita los corchetes, lo que importa cuando la orden viaja por un intérprete.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Una propuesta por paquete es lento cuando enumeras, así que recorre los valores plausibles: cifrado 5, 7/128, 7/192, 7/256; resumen 1, 2, 5, 6, 7; grupos 1, 2, 5, 14, 15, 19, 20, 21; autenticación 1 para una clave precompartida y 3 para firmas RSA. Imprime cada orden antes de ejecutarla para que la transcripción muestre qué se ofreció y en qué orden.

Paso 3: interpreta una respuesta

Una respuesta demuestra exactamente dos cosas: hay un respondedor IKE accesible en esa dirección y una propuesta ofrecida era aceptable. No dice nada sobre la clave precompartida, la capa L2TP ni si existe una cuenta de usuario. Un escaneo correcto es del todo compatible con el fallo de cualquier etapa posterior.

En una puerta de enlace que operas, esta es la parte realmente útil. El escaneo te dice qué propuestas sigue aceptando el dispositivo, y un resultado limitado a transformaciones antiguas es un hallazgo sobre la política del dispositivo, no una razón para debilitar el cliente.

Paso 4: interpreta el silencio

El silencio es una evidencia más débil de lo que parece. Puede que se rechazara cada propuesta, que UDP 500 y 4500 estén filtrados, que el origen esté limitado en tasa tras una ráfaga, o que el servicio escuche en una dirección distinta de la que escaneaste. Compara el registro IKE de la puerta de enlace con un cliente que ya conecta con credenciales válidas antes de concluir nada sobre la caja.

El comportamiento de ráfaga pertenece a esa lista porque la enumeración genera muchos paquetes en una ventana corta. Una puerta de enlace que responde a los primeros intentos y luego calla está describiendo su política anti-DoS, no su conjunto de propuestas.

Paso 5: registra qué has demostrado

Escribe la combinación aceptada junto a la versión del firmware y luego compárala con las transformaciones que los clientes que te importan ofrecen por defecto. La brecha entre esas dos listas es el problema de configuración, y el escaneo solo la hizo visible. Si las únicas propuestas aceptadas son las que no elegirías, la corrección pertenece a la política de la puerta de enlace o a un perfil de cliente, nunca a la sonda.

Una sonda que nunca respondió aun así ha respondido algo: muestra qué propuestas este dispositivo está dispuesto a discutir y cuáles preferiría dejar caer al suelo.