Una consulta a la base de datos se cuelga sobre IPsec: ¿reordenación UDP o TCP?
Una consulta que se cuelga tras un handshake limpio apunta al interior de la ruta del túnel. Tres condiciones deciden si conviene reparar la ruta o volver a TCP en el 443.
Una consulta que se cuelga después del handshake TCP no es un problema de enrutamiento. Los fallos de ruta hacen fracasar el handshake, así que una sesión que se establece y luego calla apunta al interior de la ruta: inspección, MTU o la forma en que llegan los paquetes UDP del túnel. La decisión que tiene delante es si reparar esa ruta o mover el túnel a TCP. Tres condiciones lo deciden, y ninguna trata de la base de datos.
Clasifique el bloqueo antes de culpar al túnel
Cuatro resultados parecen iguales para un usuario y significan cosas completamente distintas para un ingeniero.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
Solo las dos últimas filas justifican tiempo en el túnel. Una conexión rechazada a través de una VPN suele ser la base de datos escuchando solo en loopback, que es un problema de escucha, y un tiempo de espera antes del handshake es un filtro o una ruta. Ninguno de los dos mejora cambiando la encapsulación.
Escriba la clasificación en el ticket primero. Es el paso más barato y elimina la mayor parte del espacio de búsqueda.
Tres condiciones que deciden entre UDP y TCP
El tráfico IPsec encapsulado viaja sobre UDP, y UDP da a la ruta libertad para reordenar y descartar sin avisar a nadie. Cuando la reordenación empuja paquetes fuera de la ventana anti-repetición del túnel, se descartan en silencio y la sesión TCP interna simplemente espera. Ese es el mecanismo detrás de un handshake que funciona y una consulta que nunca vuelve.
Reparar la ruta o volver a TCP depende de tres cosas. Primero, ¿hay pérdida real de paquetes en la ruta, o solo reordenación? Segundo, ¿puede cambiar dónde ocurre la inspección, o excluir este túnel del componente que reordena? Tercero, ¿la carga es sensible al patrón de bloqueos, por ejemplo muchas sesiones multiplexadas que comparten un enlace?
Si la primera respuesta es pérdida y la segunda es no,TCP en el 443 es la alternativa pragmática. Si la segunda respuesta es sí, repare la ruta y mantenga UDP.
Lea el registro del cortafuegos, no el error de la aplicación
La aplicación informa de un tiempo de espera, lo que no dice nada sobre la causa. El registro propio del cortafuegos es donde aparece el descarte o el bloqueo, así que filtre por las direcciones de la base de datos y de la aplicación y busque descartes además de aceptaciones.Los módulos de prevención de amenazas pueden descartar paquetes sin generar un error a nivel de aplicación, que es exactamente la forma de una consulta que se cuelga. El silencio en el registro también es información: apunta a algo que no registra, como la reordenación.
Revise también el clúster. Un clúster mal configurado puede retener una sesión en la tabla de estados de un miembro mientras los paquetes siguen la ruta de otro miembro, así que las respuestas llegan donde no hay estado. Esos bloqueos parecen aleatorios y no se correlacionan con la carga.
Compare ambos extremos antes de cambiar nada, y compare el orden de llegada en lugar del número de paquetes:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapLo que realmente le cuesta TCP en el 443
Mover el túnel a TCP elimina el síntoma de la reordenación, porque el middlebox ahora ve un flujo ordenado. También crea TCP sobre TCP. La conexión exterior retransmite lo que la interior ya retransmitió, y una sola pérdida puede detener todas las sesiones multiplexadas a la vez. En una ruta limpia eso es invisible. En una con pérdidas, el remedio es peor que el síntoma.
El intercambio es aceptable cuando la alternativa es quedarse sin conectividad, y debe documentarse como una excepción con un responsable en lugar de absorberse como normal.
Registre el transporte, el puerto, una consulta de muestra y el resultado medido, además de la fecha. Sin ese registro el siguiente ingeniero repite el experimento, y la excepción se convierte en silencio en la arquitectura.
Mantenga la decisión revisable
Un diagnóstico de ruta envejece mal. El middlebox se sustituye, la configuración del módulo cambia, el enlace se actualiza, y la razón para TCP en el 443 desaparece mientras la configuración permanece. Ponga una fecha de revisión a la excepción y nombre la condición que le permitiría volver a UDP.
Pruebe ambos transportes con una consulta pequeña y con un conjunto de resultados grande. La reordenación se manifiesta como bloqueos que dependen del tamaño, mientras que un fallo de escucha detiene ambos tamaños por igual.