TCP હેન્ડશેક પછી અટકતી ક્વેરી રાઉટિંગ સમસ્યા નથી. રૂટની ખામી હેન્ડશેક નિષ્ફળ કરે છે, તેથી સ્થપાયેલું અને પછી શાંત થઈ જતું સત્ર માર્ગની અંદર તરફ ઇશારો કરે છે: નિરીક્ષણ, MTU, અથવા ટનલના UDP પેકેટ આવવાની રીત. તમારી સામેનો નિર્ણય એ છે કે એ માર્ગ સુધારવો કે ટનલને TCP પર ખસેડવી. ત્રણ શરતો એ નક્કી કરે છે, અને એમાંની એક પણ ડેટાબેઝ વિશે નથી.

ટનલને દોષ આપતાં પહેલાં અટકવાનું વર્ગીકરણ કરો

ચાર પરિણામો વપરાશકર્તાને સરખા લાગે છે અને એન્જિનિયર માટે સાવ અલગ અર્થ ધરાવે છે.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

ફક્ત છેલ્લી બે પંક્તિઓ ટનલ પર સમય ગાળવાનું વાજબી ઠેરવે છે. VPN દ્વારા નકારાયેલું જોડાણ સામાન્ય રીતે ડેટાબેઝ ફક્ત loopback પર સાંભળતું હોવાનું હોય છે, જે શ્રોતાની સમસ્યા છે, અને હેન્ડશેક પહેલાંનો સમયસમાપ્તિ ફિલ્ટર કે માર્ગ છે. બંનેમાંથી એક પણ એન્કેપ્સ્યુલેશન બદલવાથી સુધરતું નથી.

વર્ગીકરણ પહેલાં ટિકિટમાં લખો. એ સૌથી સસ્તું પગલું છે અને શોધની મોટા ભાગની જગ્યા દૂર કરે છે.

UDP અને TCP વચ્ચે નિર્ણય કરતી ત્રણ શરતો

એન્કેપ્સ્યુલેટેડ IPsec ટ્રાફિક UDP પર ચાલે છે, અને UDP માર્ગને કોઈને કહ્યા વિના ફરી ગોઠવવા અને પડતા મૂકવાની સ્વતંત્રતા આપે છે. જ્યારે ફરી ગોઠવણ પેકેટોને ટનલની એન્ટી-રિપ્લે વિન્ડોની બહાર ધકેલે છે, ત્યારે તે શાંતિથી કાઢી નાખવામાં આવે છે અને અંદરનું TCP સત્ર ફક્ત રાહ જુએ છે. સફળ હેન્ડશેક અને કદી પાછી ન ફરતી ક્વેરી પાછળની ક્રિયાવિધિ એ જ છે.

માર્ગ સુધારવો કે TCP પર પાછા જવું એ ત્રણ બાબતો પર આધાર રાખે છે. પ્રથમ, માર્ગ પર ખરેખર પેકેટ ખોટ જાય છે કે ફક્ત ફરી ગોઠવણ? બીજું, નિરીક્ષણ ક્યાં થાય છે એ બદલી શકો છો, કે આ ટનલને ફરી ગોઠવતા ઘટકમાંથી બાકાત રાખી શકો છો? ત્રીજું, કાર્યભાર અટકવાની પેટર્ન પ્રત્યે સંવેદનશીલ છે, જેમ કે એક લિંક વહેંચતાં ઘણાં મલ્ટિપ્લેક્સ સત્રો?

જો પહેલો જવાબ ખોટ હોય અને બીજો ના હોય,તો 443 પર TCP વ્યવહારુ વિકલ્પ છે. જો બીજો જવાબ હા હોય, તો માર્ગ સુધારો અને UDP રાખો.

એપ્લિકેશનની ભૂલ નહીં, ફાયરવોલનો રેકોર્ડ વાંચો

એપ્લિકેશન સમયસમાપ્તિ જણાવે છે, જે કારણ વિશે કંઈ કહેતું નથી. ફાયરવોલનું પોતાનું લોગ એ જગ્યા છે જ્યાં ડ્રોપ કે બ્લોક દેખાય છે, તેથી ડેટાબેઝ અને એપ્લિકેશનના સરનામાં પ્રમાણે ફિલ્ટર કરો અને સ્વીકાર સાથે સાથે કાઢી નાખવાનું પણ શોધો.ધમકી નિવારણ બ્લેડ એપ્લિકેશન સ્તરે ભૂલ પેદા કર્યા વિના પેકેટો કાઢી શકે છે, અને અટકતી ક્વેરીનો આ જ આકાર છે. લોગમાં શાંતિ પણ માહિતી છે: એ એવી વસ્તુ તરફ ઇશારો કરે છે જે લોગ કરતી નથી, જેમ કે ફરી ગોઠવણ.

ક્લસ્ટર પણ તપાસો. ખોટી રીતે ગોઠવાયેલું ક્લસ્ટર એક સભ્યના સ્ટેટ ટેબલમાં સત્ર રાખી શકે છે જ્યારે પેકેટો બીજા સભ્યના માર્ગે જાય છે, તેથી જવાબ ત્યાં પહોંચે છે જ્યાં કોઈ સ્ટેટ નથી. એવી અટકવણી અવ્યવસ્થિત લાગે છે અને ભાર સાથે સહસંબંધ ધરાવતી નથી.

કંઈપણ બદલતાં પહેલાં બંને છેડા સરખાવો, અને પેકેટની સંખ્યા નહીં, આવવાનો ક્રમ સરખાવો:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443 પર TCP ખરેખર તમને કેટલું મોંઘું પડે છે

ટનલને TCP પર ખસેડવાથી ફરી ગોઠવણનું લક્ષણ જતું રહે છે, કારણ કે વચ્ચેનું બોક્સ હવે ક્રમબદ્ધ પ્રવાહ જુએ છે. તે TCP-over-TCP પણ બનાવે છે. બહારનું જોડાણ જે અંદરના જોડાણે પહેલેથી ફરી મોકલ્યું છે તે ફરી મોકલે છે, અને એક જ ખોટ એકસાથે બધાં મલ્ટિપ્લેક્સ સત્રો અટકાવી શકે છે. સ્વચ્છ માર્ગ પર આ અદૃશ્ય છે. ખોટવાળા માર્ગ પર ઉપાય લક્ષણ કરતાં પણ ખરાબ છે.

જ્યારે વિકલ્પ કોઈ જ જોડાણ ન હોવું હોય ત્યારે આ અદલાબદલી સ્વીકાર્ય છે, અને તેને સામાન્ય ગણી લેવાને બદલે માલિક સાથેના અપવાદ તરીકે દસ્તાવેજ કરવી જોઈએ.

પરિવહન, પોર્ટ, નમૂનારૂપ ક્વેરી અને માપેલું પરિણામ, તેમજ તારીખ નોંધો. એ રેકોર્ડ વિના આગલો એન્જિનિયર પ્રયોગનું પુનરાવર્તન કરે છે, અને અપવાદ શાંતિથી સ્થાપત્ય બની જાય છે.

નિર્ણયને ફરી સમીક્ષા કરી શકાય તેવો રાખો

માર્ગનું નિદાન ઝડપથી જૂનું થાય છે. વચ્ચેનું બોક્સ બદલાય છે, બ્લેડની રૂપરેખા બદલાય છે, લિંક અપગ્રેડ થાય છે, અને 443 પર TCPનું કારણ અદૃશ્ય થાય છે જ્યારે રૂપરેખા રહી જાય છે. અપવાદ પર સમીક્ષા તારીખ મૂકો અને એ શરતનું નામ આપો જે તમને UDP પર પાછા ફરવા દેશે.

નાની ક્વેરી અને મોટા પરિણામ સમૂહ સાથે બંને પરિવહનની કસોટી કરો. ફરી ગોઠવણ કદ-આધારિત અટકવણી તરીકે દેખાય છે, જ્યારે શ્રોતાની ખામી બંને કદને સરખી રીતે અટકાવે છે.

સંબંધિત લેખો