कार्यरत VPN असूनही उत्तरावर वेळ संपते का
विनंती खाजगी सर्व्हरपर्यंत पोहोचणे हा देवघेवीचा फक्त अर्धा भाग आहे. तिच्या उत्तराला इच्छित गेटवे, मार्ग किंवा भाषांतरातून टनेल क्लायंट शोधावा लागतो.
विनंती येते, सर्व्हर ती नोंदवतो, आणि तरीही क्लायंट वेळ संपल्याची तक्रार करतो. या संयोगाचा अर्थ असा की उत्तराला परत जाण्याचा मार्ग सापडला नाही, आणि हा अशा थोड्या बिघाडांपैकी एक आहे जो तुम्ही दोन्ही टोकांवरून एकाच वेळी पडताळू शकता. तपासण्या क्रमाने करा आणि यापैकी एक अयशस्वी झाल्यास थांबा.
विनंती कुठे पोहोचली यापासून सुरुवात करा
दुसरे काहीही तपासण्यापूर्वी पॅकेट सेवेपर्यंत पोहोचले याची खात्री करा. सर्व्हरकडील लॉग नोंद, कनेक्शन मोजणी किंवा दूरच्या टोकावर परवानगी दिलेले कॅप्चर—सर्व एकाच प्रश्नाचे उत्तर देतात, आणि ते नसल्यास तुम्हाला उत्तराकडे नव्हे तर टनेलकडे परत पाठवते. हीच ती तपासणी आहे जी फॉरवर्डिंगची अडचण परतीच्या मार्गाच्या अडचणीपासून वेगळी करते.
विनंती कधीही पोहोचली नसल्यास येथे थांबा. टनेल, खाजगी प्रीफिक्सपर्यंतचे राउटिंग किंवा प्रवेश नियम हा विषय आहे, आणि उत्तराचा मार्ग अजून संबंधित नाही. सर्व्हरने पाहिलेला स्रोत पत्ताही नोंदवा. तो एकतर क्लायंटला मिळालेला पूल पत्ता आहे किंवा भाषांतरित पत्ता, आणि हाच फरक पुढीलपैकी कोणती तपासणी लागू होते हे ठरवतो.
उत्तराला पूलपर्यंत मार्ग हवा
रिमोट-प्रवेश क्लायंटला सहसा पूलमधून पत्ता मिळतो, आणि खाजगी नेटवर्कला त्या पूलपर्यंत परतीचा मार्ग हवा असतो. ज्या सर्व्हरचा डीफॉल्ट मार्ग स्वतःच्या गेटवेकडे दाखवतो तो पॅकेट त्या गेटवेला देतो, ज्याला पूल कुठे आहे याची कल्पनाही नसते, त्यामुळे उत्तर तिथेच मरते. काहीही परत आले नाही म्हणून क्लायंटला वेळ संपलेली दिसते, आणि हे कधीही न निघालेल्या विनंतीपासून वेगळे करता येत नाही.
सर्व्हर स्वतःच्या सबनेटसाठी वापरतो तो मार्ग नव्हे, तर क्लायंट पत्त्यासाठी निवडतो तो मार्ग तपासा. या दोन शोधांमध्ये वेगळी उत्तरे येऊ शकतात, आणि येथे दुसरेच महत्त्वाचे आहे. भाषांतर ही पर्यायी रचना आहे आणि ती सर्व्हरला जे दिसते ते बदलते. ती परतीचा मार्ग सोपा करू शकते, आणि सर्व्हरच्या लॉगमधून मूळ क्लायंट पत्ताही काढून टाकते, ज्याचा परिणाम त्या क्षेत्रावर उभ्या केलेल्या कोणत्याही नियमावर किंवा अहवालावर होतो.
सर्व्हर कॅप्चरची गेटवे कॅप्चरशी तुलना करा
सर्व्हरमधून जे बाहेर पडते त्याची गेटवेवर जे पोहोचते त्याशी तुलना करा. सर्व्हरच्या आउटबाउंड इंटरफेसवरील कॅप्चर आणि टनेल गेटवेवरील कॅप्चर प्रश्नाच्या वेगवेगळ्या अर्ध्या भागांचे उत्तर देतात, आणि त्यांच्यातील अंतर नुकसानीचे स्थान दाखवते.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
गेटवे स्वतः तयार करतो ती विनंती क्लायंट चाचणीचा निकृष्ट पर्याय आहे, कारण ती दुसऱ्या पत्त्यावरून येते आणि दुसऱ्या नियमांना सामोरे जाते. म्हणूनच गेटवेवरून यशस्वी ping आणि क्लायंटकडून अयशस्वी विनंती दोन्ही एकाच वेळी खरी असू शकतात.
मार्गावर अनेक राउटर असल्यास पूलपर्यंत मार्ग लागणाऱ्या प्रत्येकाची तपासणी करा. साइट-ते-साइट रचनेत दूरचे प्रीफिक्स एकापेक्षा जास्त उपकरणांवर माहीत असणे अनेकदा आवश्यक असते, आणि गेटवेलाच टनेल व LAN दरम्यान फॉरवर्ड करावे लागते; strongSwan च्या फॉरवर्डिंगवरील टिपा त्याची sysctl आणि फायरवॉल बाजू व्यापतात.
पूल, प्रीफिक्स आणि जबाबदार व्यक्ती नोंदवा
टिपेत चार तथ्ये येतात: क्लायंटला मिळालेला पूल, त्याला लागणारा खाजगी प्रीफिक्स, उत्तरासाठी जबाबदार राउटर, आणि असल्यास भाषांतर नियम. यांच्यासह नंतरचा गेटवे बदल तपासणी नव्हे, तुलना बनतो.
मग नेहमीच्या क्लायंटसह आणि ॲप्लिकेशनच्या खऱ्या खात्यासह पुन्हा चाचणी करा. ॲप्लिकेशनचे अधिकार वाढवल्याने पॅकेटचा परतीचा मार्ग सुधारत नाही, आणि या निदानादरम्यान खाते बदलल्यास पुढील तुलना गोंधळेल. रचना भाषांतरावर अवलंबून असल्यास, सर्व्हरचे लॉग जिथे वाचले जातात तिथे तिची नोंद करा. ऑडिट ट्रेलमध्ये अनोळखी स्रोत पत्ता पाहणाऱ्याला तिकिटातून मॅपिंग पुन्हा शोधावे लागू नये.