Consulta à base de dados pendura-se sobre IPsec: reordenação UDP ou TCP?
Uma consulta que pendura após um handshake limpo aponta para o interior do caminho do túnel. Três condições decidem se se repara o caminho ou se recua para TCP na 443.
Uma consulta que pendura depois do handshake TCP não é um problema de encaminhamento. As falhas de rota fazem falhar o handshake, por isso uma sessão que se estabelece e depois cala aponta para o interior do caminho: inspeção, MTU ou a forma como chegam os pacotes UDP do túnel. A decisão à sua frente é reparar esse caminho ou passar o túnel para TCP. Três condições decidem isso, e nenhuma delas é sobre a base de dados.
Classifique o bloqueio antes de culpar o túnel
Quatro resultados parecem iguais a um utilizador e significam coisas completamente diferentes para um engenheiro.
| 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 duas últimas linhas justificam tempo no túnel. Uma ligação recusada através de uma VPN é normalmente a base de dados a escutar apenas em loopback, o que é um problema de escuta, e um tempo de espera antes do handshake é um filtro ou uma rota. Nenhum dos dois melhora ao mudar o encapsulamento.
Escreva a classificação no ticket primeiro. É o passo mais barato e remove a maior parte do espaço de procura.
Três condições que decidem entre UDP e TCP
O tráfego IPsec encapsulado viaja sobre UDP, e o UDP dá ao caminho liberdade para reordenar e descartar sem avisar ninguém. Quando a reordenação empurra pacotes para fora da janela anti-repetição do túnel, são descartados em silêncio e a sessão TCP interior simplesmente espera. É esse o mecanismo por trás de um handshake que funciona e de uma consulta que nunca volta.
Reparar o caminho ou recuar para TCP depende de três coisas. Primeiro, há perda real de pacotes no caminho, ou apenas reordenação? Segundo, pode mudar onde ocorre a inspeção, ou excluir este túnel do componente que reordena? Terceiro, a carga é sensível ao padrão de bloqueios, por exemplo muitas sessões multiplexadas a partilhar uma só ligação?
Se a primeira resposta for perda e a segunda não,TCP na 443 é a alternativa pragmática. Se a segunda resposta for sim, repare o caminho e mantenha UDP.
Leia o registo da firewall, não o erro da aplicação
A aplicação reporta um tempo de espera, o que nada diz sobre a causa. O registo próprio da firewall é onde o descarte ou o bloqueio aparece, por isso filtre pelos endereços da base de dados e da aplicação e procure descartes e também aceitações.Os módulos de prevenção de ameaças podem descartar pacotes sem gerar um erro ao nível da aplicação, e é exatamente a forma de uma consulta que pendura. O silêncio no registo também é informação: aponta para algo que não regista, como a reordenação.
Verifique também o cluster. Um cluster mal configurado pode manter uma sessão na tabela de estados num membro enquanto os pacotes seguem o caminho de outro membro, pelo que as respostas chegam onde não existe estado. Esses bloqueios parecem aleatórios e não se correlacionam com a carga.
Compare as duas pontas antes de mudar seja o que for, e compare a ordem de chegada em vez do número de pacotes:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapO que TCP na 443 lhe custa realmente
Passar o túnel para TCP elimina o sintoma da reordenação, porque o middlebox passa a ver um fluxo ordenado. Também cria TCP sobre TCP. A ligação exterior retransmite o que a interior já retransmitiu, e uma só perda pode parar todas as sessões multiplexadas ao mesmo tempo. Num caminho limpo isso é invisível. Num caminho com perdas, o remédio é pior do que o sintoma.
A troca é aceitável quando a alternativa é ficar sem conectividade, e deve ser documentada como exceção com um responsável em vez de ser absorvida como normal.
Registe o transporte, a porta, uma consulta de exemplo e o resultado medido, além da data. Sem esse registo o próximo engenheiro repete a experiência, e a exceção torna-se silenciosamente na arquitetura.
Mantenha a decisão revista de forma periódica
Um diagnóstico de caminho envelhece mal. O middlebox é substituído, a configuração do módulo muda, a ligação é atualizada, e a razão para o TCP na 443 desaparece enquanto a configuração permanece. Coloque uma data de revisão na exceção e nomeie a condição que lhe permitiria voltar ao UDP.
Teste os dois transportes com uma consulta pequena e com um conjunto de resultados grande. A reordenação manifesta-se como bloqueios dependentes do tamanho, enquanto uma falha de escuta para os dois tamanhos por igual.