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 स्थापना की पुष्टि करें, और बाद में होने वाली किसी भी प्रमाणीकरण अस्वीकृति को अगले चरण का मानें। फिर स्वीकृत परीक्षण प्रक्रिया में नवीनीकरण जाँचें, क्योंकि पहला संबंध स्थापित होना उसके शेष जीवनकाल के बारे में कुछ नहीं कहता।