Unha consulta á base de datos cólgase sobre IPsec: reordenación UDP ou TCP?
Unha consulta que se colga tras un handshake limpo apunta ao interior da ruta do túnel. Tres condicións deciden se cómpre reparar a ruta ou volver a TCP no 443.
Unha consulta que se colga despois do handshake TCP non é un problema de encamiñamento. Os fallos de ruta fan fallar o handshake, así que unha sesión que se establece e despois cala apunta ao interior da ruta: inspección, MTU ou o xeito en que chegan os paquetes UDP do túnel. A decisión que ten diante é se reparar esa ruta ou mover o túnel a TCP. Tres condicións decídeno, e ningunha trata da base de datos.
Clasifique o bloqueo antes de culpar o túnel
Catro resultados parecen iguais para un usuario e significan cousas completamente distintas para un enxeñeiro.
| 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 |
Só as dúas últimas filas xustifican tempo no túnel. Unha conexión rexeitada a través dunha VPN adoita ser a base de datos escoitando só en loopback, que é un problema de escoita, e un tempo de espera antes do handshake é un filtro ou unha ruta. Ningún dos dous mellora cambiando a encapsulación.
Escriba a clasificación no ticket primeiro. É o paso máis barato e elimina a maior parte do espazo de busca.
Tres condicións que deciden entre UDP e TCP
O tráfico IPsec encapsulado viaxa sobre UDP, e UDP dá á ruta liberdade para reordenar e descartar sen avisar a ninguén. Cando a reordenación empurra paquetes fóra da xanela anti-repetición do túnel, descártanse en silencio e a sesión TCP interior simplemente espera. Ese é o mecanismo detrás dun handshake que funciona e dunha consulta que nunca volve.
Reparar a ruta ou volver a TCP depende de tres cousas. Primeiro, hai perda real de paquetes na ruta, ou só reordenación? Segundo, pode cambiar onde ocorre a inspección, ou excluír este túnel do compoñente que reordena? Terceiro, a carga é sensible ao patrón de bloqueos, por exemplo moitas sesións multiplexadas que comparten unha ligazón?
Se a primeira resposta é perda e a segunda non,TCP no 443 é a alternativa pragmática. Se a segunda resposta é si, repare a ruta e manteña UDP.
Lea o rexistro da devasa, non o erro da aplicación
A aplicación informa dun tempo de espera, o que non di nada sobre a causa. O rexistro propio da devasa é onde aparece o descarte ou o bloqueo, así que filtre polos enderezos da base de datos e da aplicación e busque descartes ademais de aceptacións.Os módulos de prevención de ameazas poden descartar paquetes sen xerar un erro a nivel de aplicación, que é exactamente a forma dunha consulta que se colga. O silencio no rexistro tamén é información: apunta a algo que non rexistra, como a reordenación.
Revise tamén o clúster. Un clúster mal configurado pode reter unha sesión na táboa de estados dun membro mentres os paquetes seguen a ruta doutro membro, así que as respostas chegan onde non hai estado. Eses bloqueos parecen aleatorios e non se correlacionan coa carga.
Compare ambos extremos antes de cambiar nada, e compare a orde de chegada en lugar do número de paquetes:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapO que realmente lle custa TCP no 443
Mover o túnel a TCP elimina o síntoma da reordenación, porque o middlebox agora ve un fluxo ordenado. Tamén crea TCP sobre TCP. A conexión exterior retransmite o que a interior xa retransmitiu, e unha soa perda pode deter todas as sesións multiplexadas á vez. Nunha ruta limpa iso é invisible. Nunha con perdas, o remedio é peor que o síntoma.
O intercambio é aceptable cando a alternativa é quedarse sen conectividade, e debe documentarse como unha excepción cun responsable en lugar de absorberse como normal.
Rexistre o transporte, o porto, unha consulta de mostra e o resultado medido, ademais da data. Sen ese rexistro o seguinte enxeñeiro repite o experimento, e a excepción convértese en silencio na arquitectura.
Manteña a decisión revisable
Un diagnóstico de ruta envellece mal. O middlebox substitúese, a configuración do módulo cambia, a ligazón actualízase, e a razón para TCP no 443 desaparece mentres a configuración permanece. Pona unha data de revisión á excepción e nomee a condición que lle permitiría volver a UDP.
Probe ambos transportes cunha consulta pequena e cun conxunto de resultados grande. A reordenación maniféstase como bloqueos que dependen do tamaño, mentres que un fallo de escoita detén ambos tamaños por igual.