Databaseforespørsel henger over IPsec: UDP-omorganisering eller TCP?
En forespørsel som henger etter et rent handshake, peker inn i tunnelbanen. Tre betingelser avgjør om banen skal repareres eller om vi skal falle tilbake til TCP på 443.
En forespørsel som henger etter TCP-handshaket, er ikke et ruteproblem. Rutefeil får handshaket til å feile, så en økt som etableres og deretter tier, peker inn i banen: inspeksjon, MTU eller måten tunnelens UDP-pakker ankommer på. Beslutningen foran deg er om du skal reparere den banen eller flytte tunnelen til TCP. Tre betingelser avgjør det, og ingen av dem handler om databasen.
Klassifiser stansen før du gir tunnelen skylden
Fire utfall ser like ut for en bruker og betyr helt forskjellige 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 |
Bare de to siste radene rettferdiggjør tid på tunnelen. En avvist tilkobling over en VPN er vanligvis databasen som bare lytter på loopback, som er et lytterproblem, og en tidsavbrudd før handshaket er et filter eller en rute. Ingen av dem blir bedre av å endre innkapslingen.
Skriv klassifiseringen i billetten først. Det er det billigste trinnet, og det fjerner mesteparten av søkerommet.
Tre betingelser som avgjør UDP kontra TCP
Innkapslet IPsec-trafikk går på UDP, og UDP gir banen frihet til å omorganisere og slippe uten å si det til noen. Når omorganiseringen skyver pakker utenfor tunnelens anti-replay-vindu, blir de forkastet i stillhet, og den indre TCP-økten bare venter. Det er mekanismen bak et handshake som lykkes og en forespørsel som aldri kommer tilbake.
Å reparere banen eller falle tilbake til TCP avhenger av tre ting. For det første, er det reelt pakketap på banen, eller bare omorganisering? For det andre, kan du endre hvor inspeksjonen skjer, eller utelukke denne tunnelen fra komponenten som omorganiserer? For det tredje, er arbeidslasten følsom for stansmønsteret, for eksempel mange multipleksede økter som deler én lenke?
Hvis det første svaret er tap og det andre er nei,er TCP på 443 den pragmatiske tilbakefallsløsningen. Hvis det andre svaret er ja, reparer banen og behold UDP.
Les brannmurens oppføring, ikke applikasjonens feil
Applikasjonen rapporterer en tidsavbrudd, som ikke sier noe om årsaken. Brannmurens egen logg er stedet der forkasting eller blokkering vises, så filtrer på databasens og applikasjonens adresser og se etter forkastinger så vel som aksepter.Blades for trusselsforebygging kan forkaste pakker uten å generere en feil på applikasjonsnivå, og det er nøyaktig formen på en forespørsel som henger. Stillhet i loggen er også data: det peker på noe som ikke logger, som omorganisering.
Sjekk klyngen også. En feilkonfigurert klynge kan holde en økt i tilstandstabellen på ett medlem mens pakkene tar et annet medlems bane, slik at svar ankommer der det ikke finnes tilstand. Slike stanser virker tilfeldige og korrelerer ikke med last.
Sammenlign begge ender før du endrer noe, og sammenlign ankomstorden i stedet for pakketall:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapHva TCP på 443 faktisk koster deg
Å flytte tunnelen til TCP fjerner omorganiseringssymtomet, fordi mellomleddet nå ser en ordnet strøm. Det skaper også TCP over TCP. Den ytre forbindelsen sender på nytt det den indre allerede har sendt på nytt, og ett enkelt tap kan stanse alle multipleksede økter samtidig. På en ren bane er det usynlig. På en med tap er kuren verre enn symtomet.
Byttehandelen er akseptabel når alternativet er ingen forbindelse, og den bør dokumenteres som et unntak med en eier i stedet for å absorberes som normalt.
Noter transporten, porten, en eksempelforespørsel og det målte resultatet, pluss datoen. Uten den oppføringen gjentar neste ingeniør eksperimentet, og unntaket blir stille arkitekturen.
Hold beslutningen reviderbar
En banediagnose eldes raskt. Mellomleddet byttes ut, blade-konfigurasjonen endres, lenken oppgraderes, og grunnen til TCP på 443 forsvinner mens konfigurasjonen blir. Sett en revisjonsdato på unntaket og navngi betingelsen som ville la deg gå tilbake til UDP.
Test begge transportene med en liten forespørsel og med et stort resultatsett. Omorganisering viser seg som størrelsesavhengige stanser, mens en lytterfeil stanser begge størrelsene like mye.