PPTP और L2TP/IPsec उपयोगकर्ता नाम पूछे जाने से पहले क्यों रुक जाते हैं?
उपयोगकर्ता नाम का संकेत न आना मतलब PPP कभी शुरू नहीं हुआ, इसलिए गड़बड़ी परिवहन, कुंजी अदला-बदली या टनल सेटअप में है। फिर से इंस्टॉल करने से पहले चरणों का क्रम जाँचें।
उपयोगकर्ता नाम का संकेत न आना एक निदान-उपहार है: PPP अभी शुरू नहीं हुआ, इसलिए खाता, पासवर्ड और डोमेन नीति से अभी पूछा ही नहीं गया। PPTP या L2TP/IPsec कनेक्शन में क्लाइंट क्रेडेंशियल तभी माँगता है जब टनल मौजूद हो और सर्वर ने PPP सत्र शुरू कर दिया हो। उस क्षण से पहले जो कुछ भी विफल हो सकता है वह परिवहन, कुंजी अदला-बदली या टनल सेटअप है, जो «VPN टूटा हुआ है» से कहीं छोटा क्षेत्र है।
अनुपस्थित संकेत गड़बड़ी को तीन चरणों में सीमित करता है
आखिरी चरण लिख लें जो दिखाई देने वाला सफल रहा, क्योंकि हर एक का मालिक और उपाय अलग है। दो चरण पहले अटके रहते हुए खाता सेटिंग्स का अनुमान लगाना वही तरीका है जिससे एक दोपहर गायब हो जाती है।
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
बिना संकेत के समय-समाप्त होने वाले क्लाइंट को कभी IPsec साहचर्य नहीं मिला, इसलिए गड़बड़ी IKE में है या इस बात में कि आपके पैकेट गेटवे तक पहुँचते भी हैं या नहीं। जो क्लाइंट क्रेडेंशियल सत्यापित करने की सूचना देकर फिर गिर जाता है, वह संदेश के संकेत से आगे गया था। संकेत के बाद अस्वीकृति आना PPP प्रमाणीकरण है, और उसकी जगह खाते पर लेख में है, इस लेख में नहीं।
पहला चरण: वह प्रोटोकॉल जिसे फ़ायरवॉल चुपचाप गिरा देता है
PPTP को अपने नियंत्रण चैनल के लिए TCP 1723 और डेटा पथ के लिए IP प्रोटोकॉल 47 चाहिए, और दोनों अलग-अलग यात्रा करते हैं। बहुत से नेटवर्क 1723 आगे भेजते हैं और प्रोटोकॉल 47 गिरा देते हैं, जिससे ऐसी टनल बनती है जो बातचीत करती है और फिर कुछ भी नहीं ढोती। NAT करने वाले राउटर को GRE-सक्षम पास-थ्रू भी चाहिए, और केवल IPv6 वाला एक्सेस पथ किसी भी कॉन्फ़िगरेशन में PPTP नहीं ढो सकता।
IPsec पर L2TP IKE के लिए पोर्ट 500 और NAT पार करने के लिए पोर्ट 4500 खर्च करता है, फिर L2TP ट्रैफ़िक को ही 1701 में लपेटता है, जबकि साहचर्य बनने के बाद ESP सुरक्षित पेलोड ढोता है। दोनों नियंत्रण पोर्ट की अनुमति दें पर ESP की नहीं, और आपको ठीक शीर्षक वाला लक्षण मिलेगा: दिखाई देने वाली प्रगति, फिर किसी भी क्रेडेंशियल संवाद से पहले मृत क्लाइंट। फ़ोन हॉटस्पॉट से परीक्षण करना क्लाइंट की समस्या को पथ की समस्या से अलग करने का सस्ता तरीका है।
दूसरा चरण: वह कुंजी जो कुंजी नहीं है, वह प्रस्ताव जो पेश नहीं किया जाता
बेमेल पूर्व-साझा कुंजी तेज़ी से और चुपचाप विफल होती है, और सामान्य रूप वह कुंजी है जो स्क्रीन पर सही दिखती है पर पेस्ट किया गया लाइन ब्रेक या अंत में स्पेस लिए हुए है। Linux क्लाइंट पर संवाद ज़रूरी नहीं कि सत्य का स्रोत हो: NetworkManager का L2TP प्लगइन रहस्यों को /etc/ipsec.d/ के नीचे फ़ाइलों में रखता है, और /etc/ipsec.secrets में अब भी शामिल पुरानी प्रति-कनेक्शन फ़ाइल उस फ़ाइल के बजाय इस्तेमाल होगी जो आपने अभी टाइप की है। उस फ़ाइल को सुरक्षित जगह कॉपी करें, समावेशन पथ से हटाएँ, और फिर कुंजी हाथ से दोबारा टाइप करें।
इस चरण का दूसरा आधा प्रस्ताव है। दोनों सिरों को एक ही चरण 1 एल्गोरिदम सेट — एन्क्रिप्शन, अखंडता और Diffie-Hellman समूह — और चरण 2 के लिए मेल खाते ESP रूपांतरणों पर सहमत होना पड़ता है, वरना साहचर्य बनता ही नहीं। जो गेटवे केवल 3DES, SHA1 और MODP1024 देता है वह मज़बूत एल्गोरिदम के लिए सेट क्लाइंट को अस्वीकार करेगा, और उसका लॉग अस्वीकृत रूपांतरण का नाम बताता है। सेवा को फिर से चालू करने के बजाय लॉग पढ़ें तो लॉग ही असंगति का नाम बताता है। फ़ोरम थ्रेड से एल्गोरिदम की स्ट्रिंग कॉपी करने के बजाय गेटवे से पूछें कि वह वास्तव में किन रूपांतरणों पर बातचीत करेगा: उसके पते पर इंगित ike-scan वही रूपांतरण लौटाता है जिन पर वह बातचीत करेगा। अगर एकमात्र पेशकश ऐसी क्रिप्टोग्राफ़ी है जिसकी आपकी नीति अब अनुमति नहीं देती, तो सुधार गेटवे पर है, क्लाइंट को नीचे गिराने में नहीं।
Windows में कुंजी और प्रमाणीकरण विधि VPN प्रोफ़ाइल में रहती हैं, और असंगति क्रेडेंशियल संकेत के बाद नहीं, पहले सामने आती है। जहाँ प्राप्तकर्ता Windows Server है, वहाँ पुष्टि करें कि दूरस्थ पहुँच भूमिका स्थापित है, प्रमाणपत्र उस नाम से मेल खाता है जिससे क्लाइंट जुड़ते हैं, और कोई पोर्ट फ़िल्टर ऊपर के प्रोटोकॉल से संकरा नहीं है।
तीसरा चरण: टनल मौजूद है और PPP शुरू नहीं होता
IKE पूरा हो जाने पर भी संकेत न आए तो फ़ायरवॉल नहीं, टनल डेमन देखें। L2TP को UDP 1701 पर सुनने वाला कुछ चाहिए — Linux में xl2tpd या kl2tpd, Windows में दूरस्थ पहुँच सेवा — और स्थापित पर रुकी हुई सेवा क्लाइंट की ओर से गिराए गए पैकेट जैसी ही दिखती है। जिन नियमों को आप पहले ही सत्यापित कर चुके हैं उन्हें फिर खोलने से पहले श्रोता जाँचें। फिर PPP को बातचीत करनी होती है, और पहली LCP अदला-बदली वही जगह है जहाँ शांत विफलता आमतौर पर उतरती है।
इस चरण का एक जाल नेटवर्क की गड़बड़ी बिलकुल नहीं है: Windows एक समय में किसी दिए गए VPN प्रकार का केवल एक कनेक्शन अनुमत करता है, इसलिए दूसरा प्रयास त्रुटि 937 लौटाता है, «इस प्रकार का दूसरा कनेक्शन उपयोग में है»। यह स्थानीय नियम है, और इससे बचने का रास्ता दूसरा उपकरण, दूसरा टनल प्रकार, या पहले से मौजूद उस एक कनेक्शन को साझा करना है।
अनुमान लगाने के बजाय चरणों के क्रम में लॉग पढ़ें
क्लाइंट रोकें, फिर चालू करें, और घटकों को उसी क्रम में पढ़ें जिसमें वे लॉग लिखते हैं। यानी पहले IPsec डेमन — strongSwan या Libreswan, और ipsec --version बताता है कौन — फिर L2TP डेमन, फिर pppd। विफलता से पहले जिस घटक ने आखिर में लिखा वही जाँचने वाला चरण बताता है, क्योंकि क्रम में उसके बाद आने वाला कुछ भी चला ही नहीं।
सहेजे गए सत्र के बजाय नए कनेक्शन से सत्यापित करें, क्योंकि कैश से दोबारा जुड़ने वाला क्लाइंट अदला-बदली के हिस्से छोड़ सकता है और पुराना परिणाम दोहरा सकता है। पहुँच, कुंजी अदला-बदली, टनल और PPP एक-एक करके, उसी क्रम में पुष्टि करें। तब अनुपस्थित संकेत रहस्य रहना छोड़ देता है और ऐसी सूची की दूसरी पंक्ति बन जाता है जिस पर सचमुच काम किया जा सकता है। वही सूची आप नेटवर्क टीम को देते हैं, जिससे वरना ऐसी गड़बड़ी के लिए फ़ायरवॉल जाँचने को कहा जाएगा जो बिना चालू हुए डेमन में रहती है।