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