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 प्रोफाइलमध्ये तिचा प्रस्ताव ही एकमेव चुकीची ओळ नाही. तुम्ही प्रविष्ट केलेला ट्रान्सफॉर्म संच प्रोफाइलच्या शेजारी नोंदवा, जेणेकरून पुढची व्यक्ती तपासणी पुन्हा करणार नाही.