Une requête de base de données se bloque sur IPsec : réordonnancement UDP ou TCP ?
Une requête qui se bloque après une poignée de main propre désigne l'intérieur du chemin du tunnel. Trois conditions décident s'il faut réparer le chemin ou revenir à TCP sur le 443.
Une requête qui se bloque après la poignée de main TCP n'est pas un problème de routage. Les erreurs de route font échouer la poignée de main, donc une session qui s'établit puis se tait désigne l'intérieur du chemin : inspection, MTU, ou la manière dont arrivent les paquets UDP du tunnel. La décision qui vous attend est de réparer ce chemin ou de basculer le tunnel sur TCP. Trois conditions la tranchent, et aucune ne concerne la base de données.
Qualifiez le blocage avant d'accuser le tunnel
Quatre résultats se ressemblent pour un utilisateur et signifient des choses totalement différentes pour un ingénieur.
| 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 |
Seules les deux dernières lignes justifient du temps sur le tunnel. Une connexion refusée à travers un VPN est généralement la base de données qui n'écoute que sur loopback, ce qui est un problème d'écoute, et un délai d'attente avant la poignée de main est un filtre ou une route. Ni l'un ni l'autre ne s'améliore en changeant l'encapsulation.
Écrivez le classement dans le ticket d'abord. C'est l'étape la moins coûteuse et elle élimine la plus grande partie de l'espace de recherche.
Trois conditions qui décident entre UDP et TCP
Le trafic IPsec encapsulé circule sur UDP, et UDP laisse le chemin libre de réordonner et de supprimer sans le dire à personne. Quand le réordonnancement pousse des paquets hors de la fenêtre anti-rejeu du tunnel, ils sont écartés en silence et la session TCP intérieure attend simplement. C'est le mécanisme derrière une poignée de main qui réussit et une requête qui ne revient jamais.
Réparer le chemin ou revenir à TCP dépend de trois choses. Premièrement, y a-t-il une vraie perte de paquets sur le chemin, ou seulement du réordonnancement ? Deuxièmement, pouvez-vous changer l'endroit où l'inspection a lieu, ou exclure ce tunnel du composant qui réordonne ? Troisièmement, la charge est-elle sensible au schéma de blocage, par exemple de nombreuses sessions multiplexées partageant un seul lien ?
Si la première réponse est perte et la seconde non,TCP sur le 443 est l'alternative pragmatique. Si la seconde réponse est oui, réparez le chemin et gardez UDP.
Lisez l'enregistrement du pare-feu, pas l'erreur de l'application
L'application signale un délai d'attente, ce qui ne dit rien sur la cause. Le journal propre au pare-feu est l'endroit où le rejet ou le blocage apparaît, alors filtrez sur les adresses de la base de données et de l'application et cherchez les rejets autant que les acceptations.Les modules de prévention des menaces peuvent rejeter des paquets sans générer d'erreur au niveau applicatif, ce qui est exactement la forme d'une requête qui se bloque. Le silence dans le journal est aussi une donnée : il pointe vers quelque chose qui ne journalise pas, comme le réordonnancement.
Vérifiez aussi le cluster. Un cluster mal configuré peut retenir une session dans la table d'états sur un membre pendant que les paquets suivent le chemin d'un autre membre, si bien que les réponses arrivent là où aucun état n'existe. Ces blocages semblent aléatoires et ne corrèlent pas avec la charge.
Comparez les deux extrémités avant de changer quoi que ce soit, et comparez l'ordre d'arrivée plutôt que le nombre de paquets :
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapCe que TCP sur le 443 vous coûte réellement
Déplacer le tunnel sur TCP supprime le symptôme du réordonnancement, car le middlebox voit désormais un flux ordonné. Cela crée aussi du TCP sur TCP. La connexion extérieure retransmet ce que la connexion intérieure a déjà retransmis, et une seule perte peut bloquer toutes les sessions multiplexées à la fois. Sur un chemin propre, c'est invisible. Sur un chemin avec pertes, le remède est pire que le symptôme.
Le compromis est acceptable quand l'alternative est l'absence de connectivité, et il devrait être documenté comme une exception avec un responsable plutôt qu'absorbé comme la normale.
Consignez le transport, le port, une requête d'exemple et le résultat mesuré, plus la date. Sans cet enregistrement, l'ingénieur suivant refait l'expérience, et l'exception devient discrètement l'architecture.
Gardez la décision révisable
Un diagnostic de chemin vieillit mal. Le middlebox est remplacé, la configuration du module change, le lien est mis à niveau, et la raison de TCP sur le 443 disparaît tandis que la configuration reste. Mettez une date de revue sur l'exception et nommez la condition qui vous permettrait de revenir à UDP.
Testez les deux transports avec une petite requête et avec un grand jeu de résultats. Le réordonnancement se manifeste par des blocages dépendant de la taille, tandis qu'une panne d'écoute arrête les deux tailles également.