Una consulta a la base de dades es penja sobre IPsec: reordenació UDP o TCP?
Una consulta que es penja després d'un handshake net apunta a l'interior del camí del túnel. Tres condicions decideixen si cal reparar el camí o tornar a TCP al 443.
Una consulta que es penja després de l'handshake TCP no és un problema d'encaminament. Les fallades d'encaminament fan fracassar l'handshake, així que una sessió que s'estableix i després s'atura assenyala l'interior del camí: inspecció, MTU o la manera com arriben els paquets UDP del túnel. La decisió que teniu al davant és si reparar aquest camí o moure el túnel a TCP. Tres condicions ho decideixen, i cap d'elles no tracta de la base de dades.
Classifiqueu l'aturada abans de culpar el túnel
Quatre resultats semblen iguals per a un usuari i signifiquen coses completament diferents per a un enginyer.
| 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 |
Només les dues últimes files justifiquen temps al túnel. Una connexió rebutjada a través d'una VPN sol ser la base de dades escoltant només a loopback, que és un problema d'escolta, i un temps d'espera abans de l'handshake és un filtre o una ruta. Cap de les dues no millora canviant l'encapsulament.
Escriviu la classificació al tiquet primer. És el pas més barat i elimina la major part de l'espai de cerca.
Tres condicions que decideixen UDP enfront de TCP
El trànsit IPsec encapsulat viatja per UDP, i UDP dóna al camí llibertat per reordenar i descartar sense avisar ningú. Quan la reordenació empeny els paquets fora de la finestra anti-repetició del túnel, es descarten en silenci i la sessió TCP interior simplement espera. Aquest és el mecanisme darrere d'un handshake que té èxit i d'una consulta que no torna mai.
Reparar el camí o tornar a TCP depèn de tres coses. Primer, hi ha pèrdua real de paquets al camí, o només reordenació? Segon, podeu canviar on es fa la inspecció, o excloure aquest túnel del component que reordena? Tercer, la càrrega és sensible al patró d'aturades, per exemple moltes sessions multiplexades que comparteixen un enllaç?
Si la primera resposta és pèrdua i la segona és no,TCP al 443 és l'alternativa pragmàtica. Si la segona resposta és sí, repareu el camí i manteniu UDP.
Llegiu el registre del tallafoc, no l'error de l'aplicació
L'aplicació informa d'un temps d'espera, cosa que no us diu res sobre la causa. El registre propi del tallafoc és on apareix el descart o el bloqueig, així que filtreu per les adreces de la base de dades i de l'aplicació i busqueu descarts així com acceptacions.Els mòduls de prevenció d'amenaces poden descartar paquets sense generar cap error a nivell d'aplicació, que és exactament la forma d'una consulta que es penja. El silenci al registre també és informació: assenyala alguna cosa que no registra, com la reordenació.
Reviseu també el clúster. Un clúster mal configurat pot retenir una sessió a la taula d'estats d'un membre mentre els paquets segueixen el camí d'un altre membre, així que les respostes arriben on no hi ha estat. Aquestes aturades semblen aleatòries i no es correlacionen amb la càrrega.
Compareu els dos extrems abans de canviar res, i compareu l'ordre d'arribada en lloc del nombre de paquets:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapQuè us costa realment TCP al 443
Moure el túnel a TCP elimina el símptoma de la reordenació, perquè el middlebox ara veu un flux ordenat. També crea TCP sobre TCP. La connexió exterior retransmet el que la interior ja ha retransmès, i una sola pèrdua pot aturar totes les sessions multiplexades alhora. En un camí net això és invisible. En un camí amb pèrdues, la cura és pitjor que el símptoma.
L'intercanvi és acceptable quan l'alternativa és quedar-se sense connectivitat, i s'ha de documentar com una excepció amb un responsable en lloc d'absorbir-la com a normal.
Registreu el transport, el port, una consulta de mostra i el resultat mesurat, més la data. Sense aquest registre el següent enginyer repeteix l'experiment, i l'excepció es converteix en silenci en l'arquitectura.
Manteniu la decisió revisable
Un diagnòstic de camí envelleix malament. El middlebox es substitueix, la configuració del mòdul canvia, l'enllaç s'actualitza, i la raó per a TCP al 443 desapareix mentre la configuració es queda. Posa una data de revisió a l'excepció i anomena la condició que us permetria tornar a UDP.
Proveu els dos transports amb una consulta petita i amb un conjunt de resultats gran. La reordenació es mostra com a aturades dependents de la mida, mentre que una fallada d'escolta atura les dues mides per igual.