El ESP de salida sin respuesta no significa que la VPN esté muerta
ESP protege una dirección por asociación y no reconoce nada. Alinee la conversación interna y la SA de entrada antes de calificar el servidor de insensible.
Capturó tráfico en el host IPsec, vio salir paquetes ESP, no vio volver nada y concluyó que el lado remoto está roto. La captura no sostiene esa conclusión. ESP protege una dirección de una conversación y no reconoce nada en la capa IP, así que la ausencia de ESP de retorno puede significar que la aplicación no tenía nada que decir con la misma facilidad con que puede significar que el túnel está muerto. Lea el intercambio interno y el estado del lado receptor antes de culpar a cualquiera de los dos extremos.
El mito: cada paquete protegido se gana una respuesta
ESP no es un protocolo de petición y respuesta. Cifra y autentica lo que la política selecciona, y el receptor valida, descifra y entrega ese paquete interno sin generar un paquete propio. Una consulta UDP que el destino ignora, o un eco ICMP que la política de entrada descarta, producen silencio en ambas direcciones como resultado correcto. Tratar ese silencio como un fallo de transporte le envía a buscar una avería de red que nunca existió.
Lo que una captura unidireccional demuestra en realidad es que la pila del emisor cifró algo en ese punto de observación. Nada sobre la llegada, y nada sobre la intención de responder. La pregunta útil no es "por qué no hay respuesta" sino "qué debería haber producido la conversación interna".
Dos SA, dos SPI, una conversación
Las asociaciones de seguridad IPsec son unidireccionales, así que un intercambio protegido normal tiene una asociación de entrada y una de salida con identificadores separados y estado independiente. Buscar el tráfico de retorno por el SPI del paquete de salida es, por tanto, un error de categoría, porque cualquier respuesta viaja bajo la SA de salida propia del par con su propio SPI. Empareje el conjunto por selectores de tráfico y direcciones del par.
La renovación de claves complica el cuadro durante unos segundos cada vez, ya que el estado antiguo y el de reemplazo pueden solaparse. Si el síntoma comenzó alrededor de una renovación de claves, recoja los identificadores de asociación y las marcas de tiempo juntos en lugar de solo el nombre de la conexión.
Qué debe hacer el receptor antes de que algo responda
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Cada fila falla de forma independiente y cada fallo tiene un propietario distinto, por eso una sola captura no puede distinguirlas. El contador de entrada es la única evidencia directa de llegada, porque un paquete que falla su autenticación o la comprobación de repetición se descarta sin ninguna respuesta. Un par cuyo contador de entrada no se ha movido, por tanto, no le envía ninguna información sobre su política.
La entrega es un paso separado del descifrado. El estado puede ser válido y el paquete aun así descartarse después por una política de entrada o una ruta que no incluye el destino interno, así que compruebe si el host objetivo vio texto plano en lugar de suponer que un contador limpio significa que el paquete fue donde usted quería.
El ESP nativo no es UDP
El ESP nativo es el protocolo IP 50, que no es ni TCP ni UDP y no tiene ningún puerto. Una regla de firewall que permite IKE en UDP 500 no dice nada, por tanto, sobre la ruta de datos, y un filtro escrito en torno a puertos puede dejar que un túnel negocie y luego descartar todo lo que lleva dentro. Pruebe la ruta de datos por separado, en el modo que observó realmente.
Detrás de un NAT la forma cambia: la carga protegida viaja dentro de UDP, normalmente en el puerto 4500, como define RFC 3948. Registre el modo activo antes de escribir cualquier regla, porque un dispositivo en la ruta puede tratar el ESP nativo y el ESP encapsulado en UDP de forma completamente distinta, y algunos middleboxes permiten uno y descartan el otro.
Lea contadores que pertenezcan a este incidente
En un host strongSwan, swanctl --list-sas informa contadores de paquetes y bytes por asociación en ambas direcciones, lo que basta para separar "nunca llegó" de "llegó y no se respondió". En Linux, /proc/net/xfrm_stat cuenta fallos agregados como estado ausente, política ausente y errores de protocolo. Esos totales se acumulan desde el arranque y pertenecen a un solo espacio de nombres de red, así que un número grande no es una atribución.
Tome dos lecturas alrededor de la ventana del incidente en el espacio de nombres correcto y compare las diferencias, o clavará los errores de la semana pasada en el ticket de esta tarde. Ponga el espacio de nombres y ambas marcas de tiempo en el ticket para que el siguiente lector pueda reproducir la comparación en lugar de fiarse de un total.
Nombre la etapa, no al sospechoso
Una conclusión útil dice dónde se detuvo el paquete: nunca recibido, recibido y descartado, entregado pero sin respuesta, o respondido y perdido de vuelta. Cada uno de esos puntos apunta a un propietario distinto y a un comando siguiente distinto. "Sin respuesta del servidor VPN" colapsa cuatro fallos distintos en una frase que la captura nunca justificó.
Mantenga las capturas estrechas y mantenga el estado crudo del núcleo fuera de los tickets, porque puede llevar material de claves que no tiene nada que hacer fuera del host. Las diferencias de los contadores y las marcas de tiempo son las partes que vale la pena entregar a la siguiente persona.