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 कडे परतण्याची परवानगी देणाऱ्या अटीचे नाव द्या.
दोन्ही वाहतुकी लहान क्वेरी आणि मोठ्या निकाल संचासह तपासा. पुनर्‍क्रमण आकारावर अवलंबून असलेली अडकणे म्हणून दिसते, तर श्रोत्याची बिघाड दोन्ही आकार समानपणे थांबवते.