चालू 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 और फ़ायरवॉल पक्ष को कवर करते हैं।
पूल, प्रीफ़िक्स और ज़िम्मेदार व्यक्ति दर्ज करें
नोट में चार तथ्य आते हैं: क्लाइंट को मिला पूल, उसे ज़रूरी निजी प्रीफ़िक्स, उत्तर का ज़िम्मेदार राउटर, और यदि हो तो अनुवाद नियम। इनके साथ बाद में गेटवे बदलना जाँच नहीं, तुलना बन जाता है।
फिर सामान्य क्लाइंट और ऐप्लिकेशन के असली खाते से दोबारा परीक्षण करें। ऐप्लिकेशन के अधिकार बढ़ाने से पैकेट का लौटने का मार्ग ठीक नहीं होता, और इस निदान के दौरान खाता बदलने से अगली तुलना उलझ जाएगी। अगर रचना अनुवाद पर निर्भर है, तो उसे वहीं दस्तावेज़ित करें जहाँ सर्वर के लॉग पढ़े जाते हैं। ऑडिट ट्रेल में अपरिचित स्रोत पता देखने वाले को टिकट से मैपिंग फिर से खोजनी नहीं पड़नी चाहिए।