Nabitin ang query sa database sa ibabaw ng IPsec: muling pag-aayos ng UDP o TCP?
Ang query na nabitin pagkatapos ng malinis na handshake ay tumuturo sa loob ng landas ng tunnel. Tatlong kondisyon ang nagpapasya kung aayusin ang landas o babalik sa TCP sa 443.
Ang query na nabitin pagkatapos ng TCP handshake ay hindi problema sa routing. Binabagsak ng mga depekto sa ruta ang handshake, kaya ang session na nabuo at pagkatapos ay tumahimik ay tumuturo sa loob ng landas: inspeksyon, MTU, o ang paraan ng pagdating ng UDP packets ng tunnel. Ang desisyon sa harap mo ay kung aayusin ang landas na iyon o ililipat ang tunnel sa TCP. Tatlong kondisyon ang nagpapasya nito, at wala sa mga ito ang tungkol sa database.
Uriin ang pagkahinto bago sisihin ang tunnel
Apat na resulta ang magkamukha sa isang gumagamit at magkaiba ang kahulugan sa isang inhinyero.
| 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 |
Ang huling dalawang hilera lamang ang nagbibigay-katuwiran sa oras sa tunnel. Ang tinanggihang koneksyon sa VPN ay karaniwang database na nakikinig lamang sa loopback, na problema sa listener, at ang timeout bago ang handshake ay filter o ruta. Wala sa dalawa ang bumubuti sa pagpapalit ng encapsulation.
Isulat muna ang pag-uuri sa ticket. Ito ang pinakamurang hakbang at inaalis ang malaking bahagi ng espasyo ng paghahanap.
Tatlong kondisyon na nagpapasya sa pagitan ng UDP at TCP
Ang naka-encapsulate na IPsec traffic ay dumadaan sa UDP, at binibigyan ng UDP ang landas ng kalayaan na muling ayusin at magtapon nang walang pagsasabi sa kahit kanino. Kapag itinulak ng muling pag-aayos ang mga packet sa labas ng anti-replay window ng tunnel, tahimik silang itinatapon at ang panloob na TCP session ay naghihintay lamang. Iyon ang mekanismong nasa likod ng handshake na nagtagumpay at query na hindi na bumabalik.
Ang pag-aayos ng landas o pagbabalik sa TCP ay nakasalalay sa tatlong bagay. Una, may tunay na pagkawala ng packet ba sa landas, o muling pag-aayos lamang? Ikalawa, mababago mo ba kung saan nangyayari ang inspeksyon, o maisasangkati ang tunnel na ito sa component na nag-aayos? Ikatlo, sensitibo ba ang workload sa pattern ng pagkahinto, halimbawa maraming multiplexed session na nagbabahagi ng isang link?
Kung ang unang sagot ay pagkawala at ang pangalawa ay hindi,TCP sa 443 ang pragmatikong alternatibo. Kung ang pangalawang sagot ay oo, ayusin ang landas at panatilihin ang UDP.
Basahin ang rekord ng firewall, hindi ang error ng application
Nag-uulat ang application ng timeout, na walang sinasabi tungkol sa sanhi. Ang log ng firewall mismo ang lugar kung saan lumilitaw ang pagtatapon o pagharang, kaya i-filter ayon sa mga address ng database at application at hanapin ang pagtatapon gayundin ang pagtanggap.Maaaring itapon ng mga blade ng pag-iwas sa banta ang mga packet nang hindi nagbubunga ng error sa antas ng application, at iyon mismo ang hugis ng query na nabitin. Ang katahimikan sa log ay data rin: tumuturo ito sa isang bagay na hindi nagla-log, gaya ng muling pag-aayos.
Suriin din ang cluster. Ang maling naka-configure na cluster ay maaaring maghawak ng session sa state table sa isang miyembro habang dumadaan ang mga packet sa landas ng ibang miyembro, kaya dumarating ang mga tugon sa lugar na walang state. Ang mga pagkahintong iyon ay mukhang random at walang kaugnayan sa load.
Ihambing ang dalawang dulo bago magbago ng anuman, at ihambing ang pagkakasunod-sunod ng pagdating kaysa bilang ng packet:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapAno talaga ang halaga sa iyo ng TCP sa 443
Ang paglipat ng tunnel sa TCP ay nag-aalis ng sintomas ng muling pag-aayos, dahil nakikita na ng middlebox ang isang maayos na stream. Gumagawa din ito ng TCP sa ibabaw ng TCP. Ang panlabas na koneksyon ay muling nagpapadala ng naipadala na ng panloob, at ang isang pagkawala ay maaaring huminto sa lahat ng multiplexed session nang sabay. Sa malinis na landas ito ay hindi nakikita. Sa may pagkawala, mas masama ang lunas kaysa sa sintomas.
Katanggap-tanggap ang pagpapalit kapag ang alternatibo ay kawalan ng koneksyon, at dapat itong idokumento bilang eksepsyon na may may-ari sa halip na tanggapin bilang normal.
Itala ang transport, port, sample na query at ang sinukat na resulta, kasama ang petsa. Kung wala ang rekord na iyon, uulitin ng susunod na inhinyero ang eksperimento, at tahimik na nagiging arkitektura ang eksepsyon.
Panatilihing nasusuri ang desisyon
Mabilis tumanda ang diagnosis ng landas. Pinapalitan ang middlebox, nagbabago ang configuration ng blade, ina-upgrade ang link, at nawawala ang dahilan para sa TCP sa 443 habang nananatili ang configuration. Lagyan ng petsa ng pagsusuri ang eksepsyon at pangalanan ang kondisyon na magpapahintulot sa iyong bumalik sa UDP.
Subukan ang dalawang transport gamit ang maliit na query at malaking set ng resulta. Lumilitaw ang muling pag-aayos bilang pagkahintong nakadepende sa laki, habang ang depekto ng listener ay humihinto sa dalawang laki nang pantay.