Databaseførespurnad heng over IPsec: UDP-omarrangering eller TCP?
Ein førespurnad som heng etter eit reint handshake, peikar inn i tunnelbana. Tre vilkår avgjer om bana skal reparerast eller om vi skal falla tilbake til TCP på 443.
Ein førespurnad som heng etter TCP-handshaket, er ikkje eit ruteproblem. Rutefeil får handshaket til å mislukkast, så ein økt som vert etablert og deretter teier, peikar inn i bana: inspeksjon, MTU eller måten tunnelens UDP-pakkar kjem inn på. Avgjerda framfor deg er om du skal reparera den bana eller flytta tunnelen til TCP. Tre vilkår avgjer det, og ingen av dei handlar om databasen.
Klassifiser stansen før du gir tunnelen skulda
Fire utfall ser like ut for ein brukar og tyder heilt ulike ting for ein 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 |
Berre dei to siste radene rettferdiggjer tid på tunnelen. Ei avvist tilkopling over ein VPN er vanlegvis databasen som berre lyttar på loopback, som er eit lyttarproblem, og eit tidsavbrot før handshaket er eit filter eller ei rute. Ingen av dei vert betre av å endra innkapslinga.
Skriv klassifiseringa i billetten først. Det er det billegaste steget, og det fjernar mesteparten av søkjerommet.
Tre vilkår som avgjer UDP kontra TCP
Innkapsla IPsec-trafikk går på UDP, og UDP gir bana fridom til å omorganisera og sleppa utan å seia det til nokon. Når omorganiseringa dyttar pakkar utanfor anti-replay-vindauget til tunnelen, vert dei forkasta i stillheit, og den indre TCP-økta berre ventar. Det er mekanismen bak eit handshake som lukkast og ein førespurnad som aldri kjem tilbake.
Å reparera bana eller falla tilbake til TCP er avhengig av tre ting. For det første, er det reelt pakketap på bana, eller berre omorganisering? For det andre, kan du endra kvar inspeksjonen skjer, eller utelukka denne tunnelen frå komponenten som omorganiserer? For det tredje, er arbeidslasta kjenslevar for stansemønsteret, til dømes mange multipleksa økter som deler éi lenkje?
Viss det første svaret er tap og det andre er nei,er TCP på 443 den pragmatiske tilbakefallsløysinga. Viss det andre svaret er ja, reparer bana og hald på UDP.
Les oppføringa til brannmuren, ikkje feilen til applikasjonen
Applikasjonen rapporterer eit tidsavbrot, som ikkje seier noko om årsaka. Brannmuren sin eigen logg er staden der forkasting eller blokkering syner seg, så filtrer på adressene til databasen og applikasjonen og sjå etter forkastingar så vel som akseptar.Blades for trugselsførebygging kan forkasta pakkar utan å laga ein feil på applikasjonsnivå, og det er nøyaktig forma på ein førespurnad som heng. Stillheit i loggen er også data: det peikar på noko som ikkje loggar, som omorganisering.
Sjekk klynga òg. Ei feilkonfigurert klynge kan halda ei økt i tilstandstabellen på eitt medlem medan pakkane tek bana til eit anna medlem, slik at svar kjem inn der det ikkje finst tilstand. Slike stansar verkar tilfeldige og korrelerer ikkje med last.
Samanlikn begge endar før du endrar noko, og samanlikn kome-rekkjefølgja i staden for pakketal:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapKva TCP på 443 faktisk kostar deg
Å flytta tunnelen til TCP fjernar omorganiseringssymtomet, fordi mellomleddet no ser ein ordna straum. Det skapar òg TCP over TCP. Den ytre tilkoplinga sender på nytt det den indre allereie har sendt på nytt, og eitt einaste tap kan stansa alle multipleksa økter samtidig. På ei rein bane er det usynleg. På ei med tap er kuren verre enn symtomet.
Byttehandelen er akseptabel når alternativet er inga tilkopling, og han bør dokumenterast som eit unntak med ein eigar i staden for å verta absorbert som normalt.
Noter transporten, porten, ein døme-førespurnad og det målte resultatet, pluss datoen. Utan den oppføringa gjer den neste ingeniøren eksperimentet om att, og unntaket vert stille arkitekturen.
Hald avgjerda reviderbar
Ein banediagnose eldast fort. Mellomleddet vert bytt ut, blade-konfigurasjonen endrar seg, lenkja vert oppgradert, og grunnen til TCP på 443 forsvinn medan konfigurasjonen blir verande. Set ein revisjonsdato på unntaket og nemn vilkåret som ville la deg gå tilbake til UDP.
Test begge transportane med ein liten førespurnad og med eit stort resultatsett. Omorganisering syner seg som storleiksavhengige stansar, medan ein lyttarfeil stansar begge storleikane like mykje.