Një pyetës në bazën e të dhënave ngec përmes IPsec: rirregullim UDP apo TCP?
Një pyetës që ngec pas një handshake të pastër tregon brendësinë e rrugës së tunelit. Tre kushte vendosin nëse rruga riparohet apo kthehemi te TCP në 443.
Një pyetës që ngec pas handshake-ut TCP nuk është problem i rrugëtimit. Gabimet e rrugës dështojnë handshake-un, prandaj një sesion që vendoset dhe pastaj hesht tregon brendësinë e rrugës: inspektimi, MTU ose mënyra se si mbërrijnë paketat UDP të tunelit. Vendimi para jush është të riparoni atë rrugë ose ta kaloni tunelin në TCP. Tre kushte e vendosin, dhe asnjëri nuk ka të bëjë me bazën e të dhënave.
Klasifikoni ngecjen përpara se të fajësoni tunelin
Katër rezultate duken njësoj për një përdorues dhe nënkuptojnë gjëra krejt të ndryshme për një inxhinier.
| 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 |
Vetëm dy rreshtat e fundit justifikojnë kohë në tunel. Një lidhje e refuzuar përmes një VPN është zakonisht baza e të dhënave që dëgjon vetëm në loopback, çka është problem dëgjuesi, dhe një skadim kohe përpara handshake-ut është filtër ose rrugë. Asnjëri nuk përmirësohet duke ndryshuar enkapsulimin.
Shkruani klasifikimin në tiketë fillimisht. Është hapi më i lirë dhe heq pjesën më të madhe të hapësirës së kërkimit.
Tre kushte që vendosin midis UDP dhe TCP
Trafiku i enkapsuluar IPsec udhëton mbi UDP, dhe UDP i jep rrugës lirinë të rirregullojë dhe të hedhë poshtë pa i thënë askujt. Kur rirregullimi i shtyn paketat jashtë dritares kundër përsëritjes së tunelit, ato hidhen në heshtje dhe sesioni i brendshëm TCP thjesht pret. Ky është mekanizmi pas një handshake-u që ka sukses dhe një pyetësi që nuk kthehet kurrë.
Riparimi i rrugës ose kthimi te TCP varet nga tri gjëra. Së pari, a ka humbje reale paketash në rrugë, apo vetëm rirregullim? Së dyti, a mund të ndryshoni ku bëhet inspektimi, ose ta përjashtoni këtë tunel nga komponenti që rirregullon? Së treti, a është ngarkesa e ndjeshme ndaj modelit të ngecjeve, për shembull shumë sesione të multipleksuara që ndajnë një lidhje të vetme?
Nëse përgjigjja e parë është humbje dhe e dyta jo,TCP në 443 është alternativa pragmatike. Nëse përgjigjja e dytë është po, riparoni rrugën dhe mbani UDP.
Lexoni regjistrin e firewall-it, jo gabimin e aplikacionit
Aplikacioni raporton një skadim kohe, çka nuk thotë asgjë për shkakun. Regjistri vetë i firewall-it është vendi ku shfaqet hedhja ose bllokimi, prandaj filtroni sipas adresave të bazës së të dhënave dhe të aplikacionit dhe kërkoni hedhje si dhe pranime.Modulet e parandalimit të kërcënimeve mund të hedhin paketa pa gjeneruar gabim në nivel aplikacioni, dhe kjo është pikërisht forma e një pyetësi që ngec. Heshtja në regjistër është gjithashtu të dhënë: tregon diçka që nuk regjistron, si rirregullimi.
Kontrolloni edhe grupin. Një grup i konfiguruar gabimisht mund ta mbajë një sesion në tabelën e gjendjeve në një anëtar ndërsa paketat ndjekin rrugën e një anëtari tjetër, prandaj përgjigjet mbërrijnë atje ku nuk ekziston gjendje. Ngecje të tilla duken të rastësishme dhe nuk korrelojnë me ngarkesën.
Krahasoni të dy skajet përpara se të ndryshoni diçka, dhe krahasoni rendin e mbërritjes jo numrin e paketave:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapÇfarë ju kushton në të vërtetë TCP në 443
Kalimi i tunelit në TCP e heq simptomën e rirregullimit, sepse kutia e mesme tani sheh një rrjedhë të rregullt. Krijon gjithashtu TCP mbi TCP. Lidhja e jashtme ritransmeton atë që lidhja e brendshme ka ritransmetuar tashmë, dhe një humbje e vetme mund t'i ndalojë të gjitha sesionet e multipleksuara njëherësh. Në një rrugë të pastër kjo është e padukshme. Në një me humbje, ilaçi është më i keq se simptoma.
Shkëmbimi është i pranueshëm kur alternativa është mungesa e plotë e lidhjes, dhe duhet të dokumentohet si përjashtim me një pronar në vend që të absorbohet si normale.
Regjistroni transportin, portën, një pyetës shembull dhe rezultatin e matur, plus datën. Pa atë regjistrim inxhinieri tjetër e përsërit eksperimentin, dhe përjashtimi bëhet në heshtje arkitektura.
Mbajeni vendimin të rishikueshëm
Diagnoza e rrugës plaket shpejt. Kutia e mesme zëvendësohet, konfigurimi i modulit ndryshon, lidhja përmirësohet, dhe arsyeja për TCP në 443 zhduket ndërsa konfigurimi mbetet. Vendosni një datë rishikimi për përjashtimin dhe emërtoni kushtin që do t'ju lejonte të ktheheni te UDP.
Provoni të dy transportet me një pyetës të vogël dhe me një grup të madh rezultatesh. Rirregullimi shfaqet si ngecje që varen nga madhësia, ndërsa një defekt dëgjuesi i ndal të dyja madhësitë njësoj.