L2TP NO_PROPOSAL_CHOSEN: प्रत्यक्षात कोणता टप्पा अयशस्वी झाला?
सूचना सांगते की एक प्रस्ताव नाकारला गेला, कोणता हे नाही. टप्प्यासाठी बॅकएंड लॉग वाचा, नंतर गेटवे चालवणाऱ्याशी संचाची तुलना करा.
NO_PROPOSAL_CHOSEN कोणतेही PPP वापरकर्तानाव तपासल्या जाण्यापूर्वी येते, ही उपयुक्त गोष्ट आहे आणि संदेश का दिशाभूल करतो याचे कारणही आहे। एका बाजूने प्रस्ताव नाकारला असे ते सांगते; कोणता मापदंड जुळला नाही हे सांगत नाही, आणि नकार IKE संबंध बांधताना झाला की नंतर रहदारीच्या संरक्षणावर वाटाघाटी करताना झाला याबद्दलही काहीच सांगत नाही। या दोन शक्यतांच्या मागे दोन वेगळ्या दुरुस्त्या आहेत, आणि त्यापैकी एकच लोक प्रथम हात घालतात त्या PFS चेकबॉक्सशी संबंधित आहे।
एक संदेश, दोन प्रस्ताव संच
IKEv1 L2TP/IPsec रचनेत दोन वाटाघाटी क्रमाने होतात। टप्पा 1 एन्क्रिप्शन अल्गोरिदम, अखंडता अल्गोरिदम आणि Diffie-Hellman गटातून IKE सुरक्षा संबंध बांधतो। नंतर टप्पा 2 रहदारीचे संरक्षण कसे होईल यावर वाटाघाटी करतो, आणि PFS ची आवश्यकता त्या दुसऱ्या संभाषणाची आहे।
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
टप्पे क्रमिक असल्याने, अयशस्वी ठिकाण कोणती यादी तुलना करावी हे सांगते। संदेशाचे संपूर्ण निदान मूल्य यातच आहे, आणि कोणत्याही सेटिंगला हात लावण्यापूर्वी ते काढून घेणे योग्य आहे।
PFS चेकबॉक्स टप्पा 1 दुरुस्त का करू शकत नाही
PFS बंद केल्याने टप्पा 2 चा एक गुणधर्म बदलतो। जर पक्ष कधीही टप्पा 1 वर सहमत झाले नाहीत, तर ESP संभाषण कधीच होत नाही, त्यामुळे चेकबॉक्सचा नकारावर कोणताही परिणाम होत नाही, आणि म्हणूनच तो बदलल्यास तीच त्रुटी वेगळ्या वेळमुद्रेसह येते।
उलटी चूकही तितकीच सामान्य आहे। यशस्वी IKE संबंध हे ESP प्रस्ताव स्वीकार्य असल्याचे सिद्ध करत नाही, आणि टप्पा 2 चा गट जुळतो हे तर कदापि सिद्ध करत नाही। प्रस्थापित व्यवस्थापन सुरंगाकडे केवळ टप्पा 1 बद्दलचा पुरावा म्हणून पाहा। लोक हिरवी रेष «सुरंग सुरू आहे» असे वाचतात, नंतर दुसरी वाटाघाटी सुरू झाली नाही हे कोणीही न सांगितल्यामुळे चुकीच्या टप्प्यावर एक तास घालवतात।
अल्गोरिदम निवडण्यापूर्वी लॉग वाचा
नाकाराच्या तात्काळ आधीचे संदेश जो कनेक्शन प्रत्यक्षात हाताळतो त्या बॅकएंडकडून गोळा करा आणि त्यांना त्याच प्रयत्नाशी जोडा। त्या जोडणीशिवाय तुम्ही दुसऱ्या कनेक्शनचा इतिहास वाचत आहात आणि त्यातून निष्कर्ष काढत आहात।
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanत्या ओळींमधून दोन प्रश्नांची उत्तरे द्या: टप्पा 1 चा संबंध प्रस्थापित झाला का, आणि कोणती देवघेव अयशस्वी झाली। ही दोन उत्तरे शोध एका गुणधर्म-यादीपर्यंत आकुंचित करतात। आजूबाजूच्या संदर्भाशिवाय नुसती सूचना ते करू शकत नाही, फोरम थ्रेडमधून प्रस्ताव करून पाहणे कितीही मोहक असले तरी। वेगळ्या बॅकएंडच्या यंत्रावरून चालणारी मालिका कॉपी केल्याने सहसा एक नकार दुसऱ्याने बदलला जातो, थोड्या उशिरा।
बॅकएंडची वाक्यरचना प्रवास करत नाही
काहीही तुलना करण्यापूर्वी NetworkManager-l2tp ची आवृत्ती आणि IPsec बॅकएंडची आवृत्ती नोंदवा। Libreswan आणि strongSwan प्रस्ताव-वाक्यरचना किंवा समान अल्गोरिदम-संच सामायिक करत नाहीत, त्यामुळे एकात चालणारी मालिका दुसऱ्यात वाक्यरचना त्रुटी आहे। स्थापित बॅकएंड धोरणानुसार IKEv1 लाही नकारू शकतो, आणि मग कोणताही प्रस्ताव कधीही स्वीकारला जाणार नाही।
प्रकल्पाचे README त्या बॅकएंड फरकांची नोंद करते आणि टप्पा 1 व टप्पा 2 ची क्षेत्रे वेगळी ठेवते। ते रचनेचे दस्तऐवज म्हणून वाचा, प्रत्येक ऐतिहासिक सिफर आणि दुर्बल गट सुरू करण्याचे निमंत्रण म्हणून नाही, कारण केवळ तसे करून यशस्वी होणारे कनेक्शन हे तुम्हाला बांधायला सांगितलेले कनेक्शन नाही।
संचावर सहमती करा, नंतर टप्पे पडताळा
गेटवे ऑपरेटरला विचारा की कोणते IKE आणि ESP संच समर्थित व मंजूर आहेत, नंतर त्या उत्तराची तुलना क्लायंटच्या संरचना-फाइलशी नाही तर त्याच्या प्रत्यक्ष प्रस्तावांशी करा। मतभेद विशेषतः टप्पा 2 च्या PFS बद्दल असल्यास, समर्थित गट किंवा स्पष्टपणे मंजूर PFS-विरहित धोरणावर निर्णय घ्या। त्रुटीच्या नावावरून धोरणाचा अंदाज करू नका।
जेव्हा एकमेव आच्छादन अशा क्रिप्टोग्राफीची मागणी करते जी संस्था आता स्वीकारत नाही, तेव्हा निर्णय गेटवेचा किंवा प्रोटोकॉल स्थलांतराचा असतो। काहीतरी वाटाघाटी होईपर्यंत क्लायंट मालिका रुंदावणे म्हणजे ज्ञात दुर्बलता शेजारी हिरवी खूण लावून पाठवणे।
खरे असंगत दुरुस्त केल्यानंतर, L2TP आणि PPP ची चौकशी करण्यापूर्वी IPsec प्रस्थापना निश्चित करा, आणि नंतरचा कोणताही प्रमाणीकरण नकार पुढील टप्प्याचा माना। नंतर मंजूर चाचणी प्रक्रियेत नूतनीकरण तपासा, कारण पहिल्या संबंधाची प्रस्थापना त्याच्या उर्वरित आयुष्याबद्दल काहीच सांगत नाही।