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 प्रोफाइलमा त्यसको प्रस्ताव मात्र गलत लाइन होइन। तपाईंले प्रविष्ट गरेको ट्रान्सफर्म सेट प्रोफाइलको छेउमा नोट गर्नुहोस्, ताकि अर्को व्यक्तिले जाँच दोहोर्याउनु नपरोस्।