VPN का कौन-सा चरण विफल हुआ: IPsec, L2TP नियंत्रण या PPP प्रमाणीकरण
अंतिम सफल चरण खोजें और केवल उसी परत को ठीक करें: IPsec, L2TP नियंत्रण चैनल, PPP प्रमाणीकरण या पता आवंटन।
आपने पासवर्ड बदला और कुछ नहीं हिला, क्योंकि विफलता कभी PPP में नहीं थी। L2TP/IPsec पाँच बिल्कुल अलग हैंडऑफ़ के लिए एक ही कनेक्शन त्रुटि बताता है, और हर हैंडऑफ़ की अपनी मरम्मत है। उलटी दिशा में काम करें: अंतिम सफल चरण खोजें और केवल उसके बाद आने वाली चीज़ बदलें। नीचे का क्रम यह भी तय करता है कि आप पहले कौन-सा प्रमाण इकट्ठा करेंगे।
चार प्रश्नों के उत्तर क्रम से दें
नया प्रयास थोपें, क्योंकि कुछ क्लाइंट प्रोफ़ाइल डिस्कनेक्ट और फिर से कनेक्ट होने तक पिछली त्रुटि दिखाते रहते हैं। फिर इसका उत्तर दें: क्या IPsec सुरक्षा संबद्धता थी, क्या L2TP नियंत्रण कनेक्शन और कॉल दिखे, क्या PPP प्रमाणीकरण के निर्णय तक पहुँचा, और क्या IPCP ने क्लाइंट को पता दिया? पहला नहीं वही चरण है जिसे आप ठीक करते हैं। उसके बाद सब कुछ अपरीक्षित है, इसलिए जब कभी संबद्धता नहीं रही हो तो अस्वीकृत उपयोक्तानाम कुछ सिद्ध नहीं करता।
तुलना से पहले दोनों सिरों की घड़ियाँ समकालिक करें। जिस पुनःप्रयास ने IPsec साफ़ किया और PPP पर विफल हुआ, वह एक ही विफलता जैसा दिखता है जब क्लाइंट केवल अंतिम संदेश दिखाता है और सर्वर लॉग अभी भी पिछला प्रयास रखता है। सबसे तेज़ पंक्ति से नहीं, समय-चिह्न से पढ़ें।
जब आपके पास केवल उपयोक्ता का स्क्रीनशॉट हो, तो सबसे सस्ते विभाजन पर भरोसा करें: गलत पूर्व-साझित कुंजी और कभी उत्तर न देने वाला xl2tpd Windows संवाद में एक ही पाठ उत्पन्न करते हैं, पर एक को दोनों सिरों पर बदला गया रहस्य चाहिए और दूसरे को सर्वर पर ही डेमन चालू या फ़ायरवॉल नियम चाहिए। बीच का उपकरण भीतरी 1701 को नहीं गिरा सकता जब ट्रांसपोर्ट-मोड IPsec उसे लपेट चुका हो, इसलिए ऐसा पथ-फ़िल्टर मत खोजें जो है ही नहीं।
हर परत वास्तव में क्या रखती है
IPsec दोनों सहकर्मियों के बीच पैकेट की रक्षा करता है; L2TP उस सुरक्षित पथ के भीतर PPP सत्र ढोता है, इसीलिए RFC 3193 अपनी अलग सुरंग के बजाय ट्रांसपोर्ट मोड निर्धारित करता है। क्लाइंट का लेबल L2TP कहता है, इसलिए सुरंग और लॉगिन एक ही तंत्र लगते हैं। वे हैं नहीं: L2TP नियंत्रण कनेक्शन वहाँ सुरंग के सिरों को प्रमाणित करता है जहाँ परिनियोजन उसे चालू करता है, और PPP सर्वर नीति के अंतर्गत CHAP, PAP या MS-CHAPv2 से उपयोक्ता को अलग से प्रमाणित करता है।
यही विभाजन उन दो रहस्यों को समझाता है जिन्हें लोग गड़बड़ाते रहते हैं। पूर्व-साझित कुंजी IPsec सहकर्मियों को प्रमाणित करती है। उपयोक्तानाम और पासवर्ड उपयोक्ता को PPP के सामने पहचानते हैं। प्रमाणपत्रों से प्रमाणित होने वाली प्रोफ़ाइल पर Windows का साझित रहस्य फिर से लिखने से विफल चरण में कुछ नहीं बदलता, और PPP पासवर्ड संपादित करने से अनुपस्थित सुरक्षित चैनल नहीं मिल सकता। वही संयम पहचान जाँच पर भी लागू होता है: सुरंग पाने के लिए सहकर्मी की पहचान या प्रमाणपत्र सत्यापन बंद न करें, क्योंकि तब जुड़ता पथ है, सहकर्मी नहीं।
प्रमाणीकरण भी PPP का अंत नहीं है। उपयोक्ता स्वीकार होने के बाद IPCP क्लाइंट का पता और वे DNS तथा WINS विकल्प तय करता है जो सर्वर देने को तैयार है। क्लाइंट CHAP या MS-CHAPv2 पार करके भी बिना पते का रह सकता है, जो PPP के भीतर की विफलता है, रूटिंग समस्या नहीं। IPsec के बिना सादा L2TP वैध और असुरक्षित रहता है, इसलिए सफल कनेक्शन कभी सिद्ध नहीं करता कि ट्रैफ़िक सुरक्षित है; जाँचें कि सर्वर क्या माँगता है, क्लाइंट का लेबल नहीं।
पहले अनुपस्थित चरण से निर्णय लें
तालिका को पहले अनुपस्थित मद से, बाएँ से दाएँ पढ़ें। दायाँ स्तंभ उस क्षण का एकमात्र सार्थक काम है; उसके बाएँ सब कुछ पहले ही सिद्ध है, और उसे फिर परखना बिना जानकारी जोड़े व्यवधान-खिड़की जला देता है।
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
तीन पंक्तियाँ चेतावनी के योग्य हैं। 1701 पंक्ति वही है जहाँ NAT के पीछे के Windows क्लाइंट आमतौर पर उतरते हैं: संबद्धता पूरी होती है, फिर कुछ नहीं आता, और कारण खराब पासवर्ड नहीं बल्कि एनकैप्सुलेशन है। IPCP पंक्ति वही है जिसे गलती से रूट समस्या पढ़ा जाता है, क्योंकि Windows अनुपस्थित पते को त्रुटि 720 में लपेट देता है और ट्रे आइकन केवल कहता है कि कनेक्शन विफल हुआ; वह विफलता प्रमाणीकरण के बाद और रूटिंग से पहले बैठती है। अंतिम पंक्ति बिल्कुल भी IPsec विफलता नहीं है, भले ही ट्रे आइकन डिस्कनेक्टेड कहता हो।
परतों को अलग करने वाले आदेश
strongSwan चलाने वाले Linux सर्वर पर, swanctl --list-sas स्थापित संबद्धताओं को उनकी सहकर्मी पहचान के साथ सूचीबद्ध करता है, और ipsec statusall पुराने strongSwan तथा libreswan होस्ट को कवर करता है। नीचे ip xfrm state कर्नेल की वास्तविक संबद्धताएँ दिखाता है, जबकि ss -lunp | grep 1701 सिद्ध करता है कि xl2tpd कहाँ बँधा है। नियंत्रण कनेक्शन और कॉल आते देखने के लिए xl2tpd -D को अग्रभूमि में चलाएँ, और प्रस्तावित विधि तथा उत्तर देखने के लिए /etc/ppp/options.xl2tpd में pppd डिबग चालू करें।
जब लॉग सफल प्रमाणीकरण दिखाएँ, तो अगला प्रश्न यह है कि क्या IPCP पूरा हुआ। जाँचें कि /etc/xl2tpd/xl2tpd.conf के [lns default] अनुभाग में ip range में अभी भी मुक्त पते हैं, और यदि क्लाइंट उनकी अपेक्षा करता है तो /etc/ppp/options.xl2tpd वास्तव में ms-dns और ms-wins रखता है। खाली हो चुका पूल और अनुपस्थित DNS विकल्प तार पर अलग दिखते हैं: पहला क्लाइंट को बिना पते और 720 के साथ छोड़ता है, दूसरा पता देता है पर कोई विश्लेषक नहीं, इसलिए नाम विफल होते हैं जबकि कच्चे पतों पर ping काम करता है। दोनों में से कोई पासवर्ड फिर डालने से ठीक नहीं होता।
क्लाइंट पर NetworkManager का L2TP प्लगइन pppd की बातचीत जर्नल में लिखता है, इसलिए journalctl -u NetworkManager -b आमतौर पर सुरंग ऊपर, प्रमाणीकरण अस्वीकृत को कोई सुरंग ही नहीं से अलग करता है। Windows पर Get-VpnConnection प्रोफ़ाइल की वास्तविक प्रमाणीकरण सेटिंग बताता है, और Event Viewer में Application के अंतर्गत RasClient घटनाएँ विफल घटक का नाम लेती हैं। जब संवाद बहुत अस्पष्ट हो, तो netsh ras set tracing * enable सक्षम करें।
कैप्चर के लिए एक सावधानी चाहिए। ट्रांसपोर्ट-मोड IPsec के साथ भीतरी UDP 1701 एन्क्रिप्टेड रहता है, इसलिए बाहरी इंटरफ़ेस पर कैप्चर ESP दिखाता है, या NAT-T के अंतर्गत UDP 4500, और L2TP बिल्कुल नहीं। कैप्चर में 1701 का न होना अपेक्षित है और अवरुद्ध पोर्ट का प्रमाण नहीं; देखें कि ESP या 4500 काउंटर हिलते हैं या नहीं।
NAT, MTU और रूट: जहाँ स्टैक आपको भ्रमित करता है
NAT कुछ भी प्रमाणित होने से पहले मान्यताएँ तोड़ देता है। ESP अपना अलग IP प्रोटोकॉल है, इसलिए अनुवाद करने वाला उपकरण उसे छोड़ देता है जब तक सहकर्मी एनकैप्सुलेट न करें; UDP 4500 यही प्रदान करता है। ऐसे Windows सर्वर पर जो स्वयं घरेलू राउटर या क्लाउड NAT गेटवे के पीछे है, IPsec चरण त्रुटि 789 के साथ विफल रहता है जब तक PolicyAgent कुंजी के अंतर्गत AssumeUDPEncapsulationContextOnSendRule को 2 पर सेट कर मशीन पुनःप्रारंभ न हो, और विफलता बंद पोर्ट से अलग पहचानी नहीं जाती। NAT के पीछे के क्लाइंट आसान हैं: सर्वर पर सार्वजनिक पता होने पर UDP 4500 पर NAT-T उन्हें ढोता है और वह मान शामिल नहीं होता।
PPP ऊपर आने के बाद, काला छेद वाला MTU मृत सुरंग की नकल करता है: छोटे पैकेट पार होते हैं, TLS हाथ मिलाना या पृष्ठ लोड अटक जाता है, और क्लाइंट अभी भी जुड़ा दिखा सकता है। सर्वर को दोष देने से पहले इंटरफ़ेस MTU घटाएँ या गेटवे पर MSS कसें। विभाजित सुरंग रूटिंग दूसरा धोखेबाज़ है; गलत मास्क के साथ भेजा गया सबनेट सुरंग को स्वस्थ और एक अनुप्रयोग को अगम्य छोड़ता है। निजी होस्टनाम अपना कदम जोड़ता है: यदि क्वेरी स्थानीय विश्लेषक से बाहर जाती है, तो कोई भी रूट परखे जाने से पहले नाम हल होने में विफल हो जाता है।
प्रत्ययपत्र छूने से पहले जाँचसूची
सूची क्रम से करें और पहली विफल मद पर रुकें। हर कदम सस्ता है, और हर एक संपादनों का पूरा वर्ग बाहर कर देता है।
- पुष्टि करें कि संबद्धता दोनों सिरों पर है, जुड़ा हुआ लेबल नहीं बल्कि सहकर्मी पहचान से मिलाई गई।
- पुष्टि करें कि UDP 1701 xl2tpd तक पहुँचता है; बिना कॉल की संबद्धता ही आपकी विफलता है।
- पासवर्ड गलत मानने से पहले PPP का निर्णय, और यदि प्रमाणित हुआ तो IPCP का परिणाम पढ़ें।
- अब ही प्रत्ययपत्र उसी प्रारूप में फिर डालें जिसकी सर्वर अपेक्षा करता है, क्योंकि डोमेन उपसर्ग खाता बदल देता है।
- यदि फिर भी विफल हो, तो दोनों सिरों को संरेखित समय-चिह्नों के साथ कैप्चर करें और चरण-दर-चरण तुलना करें।
दूसरे चरण पर रुकना पथ या एनकैप्सुलेशन की समस्या है, और पासवर्ड का कोई संपादन उसे नहीं हिलाएगा। तीसरे चरण पर रुकना मतलब लॉग पहले ही ठीक करने वाली विधि या पता-पूल का नाम ले चुका है। दोनों हालत में अगला बदलाव वही है जिसे आप न्यायसंगत ठहरा सकें, और आप उन सेटिंग्स में घूमना बंद कर देते हैं जो कभी शामिल ही नहीं थीं।