L2TP/IPsec असफल हुन्छ: IPsec, टनेल प्रमाणीकरण वा PPP लगइन अलग गर्नुहोस्

एउटा L2TP/IPsec जडानभित्र तीनवटा कुराले प्रमाणीकरण गर्छन्, र तीमध्ये एउटाले मात्र डायल गर्ने व्यक्तिलाई समावेश गर्छ। IPsec ले टनेलका छेउहरू प्रमाणित गर्छ, L2TP नियन्त्रण जडानले आफ्नै गोप्य कुराले साथीहरूलाई फेरि प्रमाणित गर्न सक्छ, र त्यसपछि PPP ले सत्रभित्रको प्रयोगकर्ता खाता प्रमाणित गर्छ। कुनै पनि चरणमा असफलता क्लाइन्ट संवादमा सामान्य लगइन त्रुटि जस्तो देखिन्छ र सर्भर लगमा पूर्ण रूपमा फरक देखिन्छ। चरणहरू क्रममा पूरा गर्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्, किनकि नजाँचिएको चरणमुनिको हरेक चरण पनि नजाँचिएको हुन्छ।

तीन प्रमाणीकरण चरण, तीन फरक पहिचान

IPsec ले पूर्व-साझा कुञ्जी वा प्रमाणपत्र प्रयोग गरेर छेउहरू कसको हुन् भनी प्रमाणित गर्छ। त्यो पहिचान मेसिन वा गेटवेको हुन्छ, किबोर्डअगाडिको मानिसको कहिल्यै हुँदैन। यो चरणमा साथीहरू सहमत हुन नसके एक पनि L2TP प्याकेट आदानप्रदान हुँदैन।

L2TP नियन्त्रण जडानले दुवै छेउमा हुनैपर्ने साझा गोप्य कुराले चलाइने दोस्रो, छुट्टै चुनौती-प्रतिक्रिया आदानप्रदान थप्न सक्छ।

RFC 2661 ले त्यो नियन्त्रण जडान प्रमाणीकरणलाई ऐच्छिक बनाउँछ, जसले एउटै गल्तीले दुई सर्भरमा फरक लक्षण किन दिन्छ भन्ने बुझाउँछ। टनेल गोप्य कुरा कहिल्यै नसेट गरेको तैनाथीले चरण पूरै छोड्छ; एउटै पक्षमा मात्र सेट गरेको तैनाथी PPP दिनुअघि नै असफल हुन्छ। त्यसपछि PPP ले प्रयोगकर्तालाई PAP, CHAP वा MSCHAPv2 मार्फत प्रमाणित गरी नाम स्थानीय, chap-secrets वा RADIUS मा हुनसक्ने खाता भण्डारमा दिन्छ। त्यस बेलाको गलत पासवर्डले पनि तपाईंलाई चलिरहेको टनेल र असफल सत्रसँगै छोड्छ।

कन्फिग सम्पादन गर्नुअघि रोकिने ठाउँ पढ्नुहोस्

स्थिति आउटपुट strongSwan को हो वा Libreswan को भनी जान्न ipsec --version बाट सुरु गर्नुहोस्। त्यसपछि क्लाइन्ट संवाद होइन, सर्भर लग पढ्नुहोस्, किनकि कुन चरणले अस्वीकार गर्यो भनी सर्भरले अभिलेख गर्छ।

सामान्यतया एउटा लाइनले टिकट टुंग्याउँछ: IKE वा प्रस्तावको गुनासो पहिलो चरण, नियन्त्रण जडानको सन्देश दोस्रो चरण, र PPP विधि वा खाता अस्वीकृति तेस्रो चरण। त्यो लाइन समय-छापसहित टिकटमा प्रतिलिपि गर्नुहोस्। क्लाइन्टतर्फबाट अनुमान गर्नु तपाईंसँग पहिले नै भएको एउटै प्रमाण बर्बाद गर्नु हो।

कुञ्जी सामग्री र पासवर्ड त्यो टाँसिएकोबाट बाहिर राख्नुहोस्; चरणको नामले कामलाई दिशा दिन्छ, र चुहिएको पूर्व-साझा कुञ्जीले अझ नराम्रो परिणामसहित टिकट फेरि खोल्छ।

पहिलो चरण: IPsec सँग सम्बन्ध छ?

strongSwan मा ipsec statusall वा Libreswan मा ipsec whack --status चलाउनुहोस् र शून्य नभएका गणकसहित स्थापित सन्तान सम्बन्ध खोज्नुहोस्। ip xfrm state ले दुवैमा कर्नेलको दृश्य देखाउँछ। बढ्दो गणकसहित स्थापित SA जोडी भनेको पहिलो चरण सकियो र तपाईं अगाडि बढ्न सक्नुहुन्छ।

सम्बन्धै नहुनुले साथीको ठेगाना, प्रस्ताव समूह वा पूर्व-साझा कुञ्जीलाई सङ्केत गर्छ, र कहिलेकाहीँ UDP 500 पुनःलेखन गरी UDP 4500 छोडिदिने यन्त्रलाई पनि सङ्केत गर्छ। स्थापित भएर केही सेकेन्डपछि हराउने सम्बन्ध सामान्यतया प्रमाणको समस्या नभई दुई छेउबीचको आयु असमझदारी हो। केही पनि फेरि टाइप गर्नुअघि दुवै पक्षले एउटै इन्क्रिप्शन र ह्यास प्रस्ताव सूचीबद्ध गर्छन् कि जाँच्नुहोस्। नगरे, कुनै पनि कुञ्जीले कहिल्यै काम गर्दैन।

सम्बन्ध अनुपस्थित रहेसम्म रोक्नुहोस्। त्यस बेला PPP विकल्प सम्पादन गर्दा केही फेरिँदैन र वास्तविक दोष अर्को व्यक्तिबाट लुकाउँछ।

दोस्रो चरण: L2TP नियन्त्रण जडानले प्रमाणीकरण गर्यो?

IPsec उठेपछि, L2TP डेमनमा स्थापित अवस्थामा पुग्ने नियन्त्रण जडान हेर्नुहोस्, किनकि त्यसअघि PPP सुरु हुन सक्दैन। नियन्त्रण जडानमा अस्वीकृति भनेको छेउहरूबीच टनेल गोप्य कुरा फरक छ, वा एउटा छेउले अर्कोले कहिल्यै नपठाउने गोप्य कुरा माग्छ। क्लाइन्टहरूले प्रायः shared secret लेबल भएको एउटै फिल्ड देखाउँछन्, र त्यो सामान्यतया L2TP को होइन, IPsec को हुन्छ। त्यो भर्दा टनेल गोप्य कुरा सेट हुँदैन, र खाली गर्दा त्यो बन्द हुँदैन।

दुवै पक्षले टनेल गोप्य कुरा सेट नगरेको भए यो चरण छोड्नुहोस् र नियन्त्रण जडानको असफलतालाई सट्टा पहुँचको समस्या मान्नुहोस्। UDP 1701 डेमनसम्म पुग्छ र दुवै छेउ एउटै इन्क्याप्सुलेशनमा सहमत छन् भनी पुष्टि गर्नुहोस्। ती दुई सर्तमध्ये एउटाका लागि लेखिएको फायरवाल नियम आधा खुल्ने जडानको सामान्य कारण हो।

PPP को वार्ता सुरु गर्ने सत्रले मात्र टनेल चरण साँच्चै पार गरेको हुन्छ।

तेस्रो चरण: PPP खाता अस्वीकार गर्दै छ?

PPP असफलता बाहिरबाट फरक देखिन्छ: टनेल स्थापित छ, सत्र सुरु हुन्छ, र डेमनले प्रमाणीकरण विधिको असफलता वा खाता अस्वीकृति अभिलेख गर्छ। त्यो सन्देशमा नाम दिइएको विधि पढ्नुहोस्। PAP र CHAP फरक कारणले असफल हुन्छन्, र एउटा अस्वीकार गर्ने सर्भरले त्यही मात्र दिने क्लाइन्टलाई अस्वीकार गर्नेछ।

Linux सर्भरमा, डेमनले PPP लाई दिने विकल्प फाइल, सामान्यतया /etc/ppp/options.xl2tpd, जाँच्नुहोस् र कुन विधि स्वीकार गरिन्छ र खाता कहाँ टुंग्याइन्छ भनी पुष्टि गर्नुहोस्। RADIUS मा भए पनि स्थानीय गोप्य फाइलमा नभएको नाम सफा रूपमा असफल हुन्छ र गलत पासवर्ड जस्तो देखिन्छ। त्यसपछि क्लाइन्टले सर्भरले स्वीकार गर्ने विधि दिन्छ कि, सर्भरले वार्ता अस्वीकार गर्ने बलियो विधि होइन भनी जाँच्नुहोस्। यो चरण सुधार्न पूर्व-साझा कुञ्जी फेर्नु दिउँसोको समय बर्बाद गर्छ र केही फेर्दैन।

सत्र अन्ततः उठ्दा, ठेगाना बाँडफाँट, DNS र मार्गहरू अझै जाँचिएका छैनन्, र प्रत्येक आफ्नै तरिकाले चुपचाप असफल हुन्छ। तपाईंका टिप्पणीमा तीन तह अलग राख्नुहोस्: सही कुञ्जी र गलत खाता सधैं असफल हुन्छ, र एउटा तह सुधार्दा अर्को कहिल्यै सुध्रिँदैन।