L2TP/IPsec एक नेटवर्क पर जुड़ता है और दूसरे पर समय-सीमा पार कर जाता है

वही लैपटॉप, वही प्रोफ़ाइल और वही पासवर्ड एक इमारत में काम करते हैं और दूसरी में विफल हो जाते हैं। यही तुलना टिकट में सबसे उपयोगी साक्ष्य है, और आमतौर पर यही पहली चीज़ होती है जिसे छोड़ दिया जाता है। दो एक्सेस नेटवर्क के बीच आदान-प्रदान अलग पता अनुवाद, अलग फ़िल्टर और अलग राउटर सहायकों से गुज़रता है। क्लाइंट को स्थिर रखना और केवल नेटवर्क बदलना यह पता लगाने का तरीका है कि इनमें से क्या मायने रखता है।

नेटवर्क की तुलना से पहले क्लाइंट तय करें

जब तक काम करने वाले मामले का रिकॉर्ड न हो, डिवाइस पर कुछ न बदलें: क्लाइंट संस्करण, प्रोफ़ाइल की सामग्री, सर्वर का नाम और सफल कनेक्शन का समय। फिर उसी सत्र में दूसरे नेटवर्क पर विफलता दोहराएँ, ताकि क्लाइंट की स्थिति यथासंभव एक जैसी रहे। दोनों प्रयासों के बीच संपादित प्रोफ़ाइल पूरी तुलना को अमान्य कर देती है। लक्ष्य एक चर है, और वह चर नेटवर्क है।

पहले विफल नेटवर्क पर सामान्य इंटरनेट पहुँच की पुष्टि करें, अगर मौजूद हो तो अतिथि पोर्टल सहित। कभी पूरा न किया गया पोर्टल ऐसा समय-समाप्ति पैदा करता है जो फ़िल्टर किए गए टनल जैसा दिखता है, और वह जाँच एक मिनट लेती है।

चार चरण, चार अलग त्रुटि संदेश

L2TP/IPsec कनेक्शन चार चरणों से गुज़रता है, और RFC 3193 उस व्यवस्था का वर्णन करता है जो पहले दो को जोड़ती है। IKE बातचीत वह जगह है जहाँ फ़िल्टर किया गया पथ शांत समय-समाप्ति पैदा करता है। IPsec प्रमाणीकरण वह जगह है जहाँ प्रमाणपत्र या पहले से साझा कुंजी का अंतर इसके बजाय स्पष्ट अस्वीकृति पैदा करता है। L2TP टनल की स्थापना वह जगह है जहाँ पहले से स्थापित सुरक्षा संगठन फिर भी कहीं नहीं ले जा सकता है, और PPP लॉगिन वह जगह है जहाँ गलत क्रेडेंशियल अंततः दिखाई देने वाली विफलता पैदा करता है। लॉग उस चरण के लिए पढ़ें जो रुका, अंतिम छपी पंक्ति के लिए नहीं।

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

strongSwan का लॉग दिखाता है कि IKE आदान-प्रदान किसी प्रस्ताव तक पहुँचा या नहीं और साथी ने बिल्कुल जवाब दिया या नहीं, जो पहुँच को नीति से अलग करता है। xl2tpd का लॉग वहाँ से जारी होता है जहाँ IPsec समाप्त होता है, इसलिए उस लॉग में कुछ भी न होने वाला स्थापित सुरक्षा संगठन L2TP चरण की ओर इशारा करता है। रूट प्रश्न पुष्टि करता है कि क्लाइंट उसी सर्वर पते पर भेज रहा है जिसकी आप सोचते हैं, और यह पिछले नेटवर्क से विरासत में मिला पुराना DNS उत्तर पकड़ लेता है। साथ में, तीनों आउटपुट लक्षण के बजाय चरण का नाम बताते हैं।

NAT की गहराई और सहायक के व्यवहार की तुलना करें

NAT पारगमन संरक्षित ट्रैफ़िक को UDP एनकैप्सुलेशन में ले जाता है जब अनुवाद पहचाना जाता है, इसलिए काम करने वाले सत्र को ले जाने वाले पोर्ट नंबर स्थिर आरेख वाले से अलग हो सकते हैं। एक सेटअप पैकेट की अनुमति देना बाकी आदान-प्रदान के बारे में कुछ साबित नहीं करता, और बाहरी पोर्ट स्कैन आपको नहीं बता सकता कि साथी वैध प्रमाणित ट्रैफ़िक के साथ कैसा व्यवहार करता है। दूसरी अनुवाद परत तस्वीर फिर बदल देती है, क्योंकि मैपिंग अब दो बार मौजूद है और दो अलग समय-सारणियों पर समाप्त होती है। मोबाइल कनेक्शन पर ऑपरेटर स्तर का अनुवाद ही आम कारण है कि काम करने वाली कार्यालय प्रोफ़ाइल फ़ोन हॉटस्पॉट पर विफल होती है।

राउटर सहायक नेटवर्क जितने ही भिन्न होते हैं। कुछ फ़र्मवेयर आदान-प्रदान को रोककर फिर से लिखते हैं, कुछ केवल उसे गिराना बंद कर देते हैं, और कुछ सेटिंग को केवल पुराने मोड में लागू करते हैं। चेकबॉक्स के बारे में स्वयं फ़र्मवेयर का विवरण पढ़ें, और जहाँ संगतता मोड हो, उसे एक जानबूझकर किए गए बदलाव के रूप में परखें, एक साथ तीन के रूप में नहीं।

बाहर जाने वाला क्लाइंट, अंदर आने वाला सर्वर: दो अलग समस्याएँ

बाहर जाने वाले क्लाइंट और अंदर आने वाले सर्वर को ऊपर की ओर अलग पहुँच चाहिए, और वह पास-थ्रू सुविधा जो पहले की मदद करती है दूसरे के लिए कुछ नहीं करती। घरेलू राउटर जो लैपटॉप को दूर के गेटवे तक पहुँचने देता है, इस कारण अपने पीछे के सर्वर तक आने वाले कनेक्शन स्वीकार नहीं करता। दोनों को मिला देना आपको पोर्ट फ़ॉरवर्डिंग खोजने भेजता है जो कभी समस्या नहीं थी। कुछ भी तुलना करने से पहले बताएँ कि विफल डिवाइस कौन-सी भूमिका निभाता है।

किसी समर्थित बदलाव के बाद वही कनेक्शन दोहराएँ और पहुँचे गए चरण को दर्ज करें। काम करने वाली प्रोफ़ाइल और विफल नेटवर्क का नोट साथ रखें, और क्रेडेंशियल रीसेट न करें और क्लाइंट को फिर से इंस्टॉल न करें, क्योंकि इससे वह साक्ष्य बाहर हो जाता है जिस पर तुलना बनी थी।