Databaseforespørgsel hænger over IPsec: UDP-omrokering eller TCP?
En forespørgsel, der hænger efter et rent handshake, peger ind i tunnelens sti. Tre betingelser afgør, om stien skal repareres, eller om der skal faldes tilbage til TCP på 443.
En forespørgsel, der hænger efter TCP-handshaket, er ikke et routingproblem. Rutefejl får handshaket til at fejle, så en session, der etableres og derefter tier, peger ind i stien: inspektion, MTU eller den måde, tunnelens UDP-pakker ankommer på. Beslutningen foran dig er, om du skal reparere den sti eller flytte tunnelen til TCP. Tre betingelser afgør det, og ingen af dem handler om databasen.
Klassificér stilstanden, før du giver tunnelen skylden
Fire udfald ser ens ud for en bruger og betyder helt forskellige ting for en ingeniør.
| 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 |
Kun de sidste to rækker retfærdiggør tid på tunnelen. En afvist forbindelse over en VPN er normalt databasen, der kun lytter på loopback, hvilket er et lytterproblem, og en timeout før handshaket er et filter eller en rute. Ingen af dem bliver bedre af at ændre indkapslingen.
Skriv klassifikationen i billetten først. Det er det billigste skridt, og det fjerner det meste af søgerummet.
Tre betingelser, der afgør UDP kontra TCP
Indkapslet IPsec-trafik kører på UDP, og UDP giver stien frihed til at omrokere og droppe uden at fortælle nogen det. Når omrokering skubber pakker uden for tunnelens anti-replay-vindue, kasseres de lydløst, og den indre TCP-session venter bare. Det er mekanismen bag et handshake, der lykkes, og en forespørgsel, der aldrig vender tilbage.
At reparere stien eller falde tilbage til TCP afhænger af tre ting. For det første, er der egentligt pakketab på stien, eller kun omrokering? For det andet, kan du ændre, hvor inspektionen sker, eller udelukke denne tunnel fra komponenten, der omrokerer? For det tredje, er arbejdsbyrden følsom over for stilstandsmønsteret, for eksempel mange multipleksede sessioner, der deler et enkelt link?
Hvis det første svar er tab, og det andet er nej,er TCP på 443 den pragmatiske tilbagefaldsløsning. Hvis det andet svar er ja, skal du reparere stien og beholde UDP.
Læs firewallens post, ikke applikationens fejl
Applikationen rapporterer en timeout, hvilket ikke siger noget om årsagen. Firewallens egen log er det sted, hvor drop eller blokering viser sig, så filtrér på databasens og applikationens adresser, og se efter kasseringer såvel som accept.Blades til trusselsforebyggelse kan kassere pakker uden at generere en fejl på applikationsniveau, hvilket er præcis formen på en forespørgsel, der hænger. Tavshed i loggen er også data: det peger på noget, der ikke logger, som omrokering.
Undersøg også klyngen. En fejlkonfigureret klynge kan holde en session i tilstandstabellen på ét medlem, mens pakkerne tager et andet medlems sti, så svar ankommer, hvor der ikke findes tilstand. Sådanne stop ser tilfældige ud og korrelerer ikke med belastning.
Sammenlign begge ender, før du ændrer noget, og sammenlign ankomstorden i stedet for pakketal:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapHvad TCP på 443 reelt koster dig
At flytte tunnelen til TCP fjerner omrokeringssymtomet, fordi middleboxen nu ser en ordnet strøm. Det skaber også TCP-over-TCP. Den ydre forbindelse gensender det, den indre forbindelse allerede gensendte, og et enkelt tab kan stoppe alle multipleksede sessioner på én gang. På en ren sti er det usynligt. På en tabende sti er kuren værre end symtomet.
Byttehandlen er acceptabel, når alternativet er ingen forbindelse, og den bør dokumenteres som en undtagelse med en ejer i stedet for at blive absorberet som normalt.
Notér transporten, porten, en eksempelforespørgsel og det målte resultat plus datoen. Uden den post gentager den næste ingeniør eksperimentet, og undtagelsen bliver stille arkitekturen.
Hold beslutningen reviderbar
En stidiagnose ældes hurtigt. Middleboxen udskiftes, blade-konfigurationen ændres, linket opgraderes, og grunden til TCP på 443 forsvinder, mens konfigurationen bliver. Sæt en revisionsdato på undtagelsen, og navngiv den betingelse, der ville lade dig vende tilbage til UDP.
Test begge transporter med en lille forespørgsel og med et stort resultatsæt. Omrokering viser sig som størrelsesafhængige stop, mens en lytterfejl stopper begge størrelser lige meget.