IPsec माथि डेटाबेस क्वेरी अड्किन्छ: UDP पुनःक्रम वा TCP?
सफा ह्यान्डसेकपछि अड्किने क्वेरी टनेलको मार्गभित्रतिर संकेत गर्छ। मार्ग सुधार्ने हो वा 443 मा TCP मा फर्कने भन्ने तीन सर्तले निर्धारण गर्छ।
TCP ह्यान्डसेकपछि अड्किने क्वेरी राउटिङको समस्या होइन। मार्गका त्रुटिले ह्यान्डसेक असफल बनाउँछन्, त्यसैले स्थापित भएर पछि चुप हुने सत्र मार्गभित्रतिर संकेत गर्छ: निरीक्षण, MTU, वा टनेलका UDP प्याकेट आउने तरिका। तपाईंअगाडिको निर्णय त्यो मार्ग सुधार्ने हो वा टनेल TCP मा सार्ने। तीन सर्तले त्यो निर्धारण गर्छन्, र तीमध्ये एउटै पनि डेटाबेसबारे होइन।
टनेललाई दोष दिनुअघि अड्काउको वर्गीकरण गर्नुहोस्
चार नतिजा प्रयोगकर्तालाई उस्तै देखिन्छन् र इन्जिनियरका लागि पूर्ण रूपमा फरक अर्थ राख्छन्।
| 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 |
अन्तिम दुई पंक्तिले मात्र टनेलमा समय खर्च गर्नु जायज ठहराउँछन्। 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.pcap443 मा TCP ले तपाईंलाई साँच्चै कति खर्च गराउँछ
टनेल TCP मा सार्दा पुनःक्रमको लक्षण हट्छ, किनभने बीचको बक्सले अब क्रमबद्ध स्ट्रिम देख्छ। यसले TCP-over-TCP पनि बनाउँछ। बाहिरको जडानले भित्री जडानले पहिले नै पुनःपठाएको कुरा फेरि पठाउँछ, र एउटै हानिले सबै मल्टिप्लेक्स सत्रहरू एकैचोटि रोक्न सक्छ। सफा मार्गमा यो अदृश्य हुन्छ। हानि भएको मार्गमा उपचार लक्षणभन्दा नराम्रो हुन्छ।
विकल्प जडानको पूर्ण अभाव हुँदा यो साटासाट स्वीकार्य हुन्छ, र यसलाई सामान्य मानेर स्वीकार्नुको सट्टा मालिकसहितको अपवादका रूपमा अभिलेख गर्नुपर्छ।
ट्रान्सपोर्ट, पोर्ट, नमुनाको क्वेरी र नापिएको नतिजा, साथै मिति रेकर्ड गर्नुहोस्। त्यो रेकर्डबिना अर्को इन्जिनियरले प्रयोग दोहोर्याउँछ, र अपवाद चुपचाप स्थापत्य बन्छ।
निर्णयलाई पुनरावलोकनयोग्य राख्नुहोस्
मार्गको निदान छिटो पुरानो हुन्छ। बीचको बक्स फेरिन्छ, ब्लेडको कन्फिगरेसन बदलिन्छ, लिंक अपग्रेड हुन्छ, र 443 मा TCP को कारण हराउँछ जबकि कन्फिगरेसन रहन्छ। अपवादमा पुनरावलोकन मिति राख्नुहोस् र UDP मा फर्कन दिने सर्तको नाम दिनुहोस्।
सानो क्वेरी र ठूलो नतिजा समूहसँग दुवै ट्रान्सपोर्टको परीक्षण गर्नुहोस्। पुनःक्रम आकारमा निर्भर अड्काउका रूपमा देखिन्छ, जबकि श्रोताको खराबीले दुवै आकारलाई समान रूपमा रोक्छ।