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 पर लौटने देगी।
दोनों ट्रांसपोर्ट को छोटी क्वेरी और बड़े परिणाम सेट के साथ जाँचें। पुनर्क्रमण आकार-निर्भर अटकाव के रूप में दिखता है, जबकि श्रोता की खराबी दोनों आकारों को समान रूप से रोकती है।