L2TP पर NO_PROPOSAL_CHOSEN? पहले गेटवे स्कैन करें

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

संदेश क्या बाहर कर देता है

अस्वीकृति मुख्य मोड में, किसी भी L2TP या PPP के आदान-प्रदान से पहले होती है, इसलिए टनल और उपयोगकर्ता डेटाबेस से कुछ नहीं पूछा गया। फ़ेज़ 1 एन्क्रिप्शन, अखंडता और एक Diffie-Hellman समूह पर बातचीत करता है। फ़ेज़ 2 डेटा के लिए ESP प्रस्ताव पर बातचीत करता है। फ़ेज़ 1 की विफलता को फ़ेज़ 2 की PFS सेटिंग बदलकर ठीक नहीं किया जा सकता, और पूरा हुआ IKE संबंध यह साबित नहीं करता कि ESP प्रस्ताव उपयुक्त है।

सिंटैक्स संपादित करने से पहले बैकएंड दर्ज करें: ipsec --version। libreswan और strongSwan एक ही एल्गोरिदम के लिए प्रस्ताव की अलग-अलग वर्तनियाँ स्वीकार करते हैं।

फिर अस्वीकृति को संदर्भ में इसके साथ पढ़ें: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd।

गेटवे का ट्रांसफ़ॉर्म सेट स्कैन करें

स्कैनर गेटवे से सीधे पूछता है कि वह किन ट्रांसफ़ॉर्म पर बातचीत करेगा। पहले स्थानीय IPsec सेवा रोकें ताकि जाँच आपके अपने क्लाइंट से प्रतिस्पर्धा न करे, फिर SA पंक्तियाँ पढ़ें। सूची को दूसरे सिरे के बारे में सबूत मानें, न कि ऐसे मेन्यू के रूप में जिसे पूरा चालू करना है।

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

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

सुरक्षा बंद किए बिना ओवरलैप मिलाएँ

केवल वही ट्रांसफ़ॉर्म दर्ज करें जो स्कैन और आपकी नीति दोनों में दिखें। नीचे का उदाहरण फ़ेज़ 1 में 3DES, SHA1 और MODP1024 पेश करने वाले गेटवे को दर्शाता है। बैकएंड की चेतावनी पर ध्यान दें: libreswan 4.x modp1024 समूह को कंपाइल नहीं करता, इसलिए यह strongSwan या DH2 समर्थन वाले libreswan बिल्ड पर लागू होता है। क्लाइंट को खराब मानने से पहले संस्करण जाँचें।

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

फिर से प्रयास करने से पहले डेमॉन और पोर्ट जाँचें

NetworkManager-l2tp अपना अलग xl2tpd इंस्टेंस शुरू करता है। अगर सिस्टम सेवा के पास पहले से UDP 1701 है, तो क्लाइंट क्षणिक स्रोत पोर्ट पर चला जाता है, जिसे RFC 3193 अनुमति देता है और कुछ सर्वर चुपचाप गिरा देते हैं। अगले प्रयास से पहले सॉकेट का स्वामी जाँचें।

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

बासी उत्पन्न रहस्य एक और ख़ामोश कारण है। यहाँ की फ़ाइलें /etc/ipsec.d/ पुराने कनेक्शन के नाम पर बनी फ़ाइलें उन्हें बनाने वाली प्रोफ़ाइल से अधिक जी सकती हैं, इसलिए जिनका कोई संदर्भ नहीं देता उन्हें हटाएँ और फिर प्रयास करें।

अंत में, जाँचें कि सलाह कहाँ से आई। ipsec.conf IKEv1 XAuth के लिए लिखी फ़ाइल अलग प्रकार के VPN का वर्णन करती है, और L2TP प्रोफ़ाइल में उसका प्रस्ताव ही एकमात्र गलत पंक्ति नहीं है। जो ट्रांसफ़ॉर्म सेट आपने दर्ज किया उसे प्रोफ़ाइल के पास लिखें, ताकि अगला व्यक्ति जाँच दोहराए नहीं।