किन एउटै PPP CHAP ले MPPE को आवश्यकता पूरा गर्न सक्दैन

इन्क्रिप्शनमा जोड दिने PPTP प्रोफाइल सामान्यतया एउटै ठाउँमा असफल हुन्छ: PPP यस्तो प्रमाणीकरण आदानप्रदानमा सहमत हुन्छ जसले कहिल्यै MPPE लाई चाहिने कुञ्जी सामग्री उत्पादन गर्दैन। टनेल आधा जीवित देखिन्छ, पासवर्ड स्वीकारिन्छ, र कुनै पनि ट्राफिक त्यसलाई पार गर्नुअघि लिङ्क झर्छ। केही जोडिएसम्म CHAP ड्रपडाउनतिर हात बढाउनु वास्तविक दोष लुकाउँछ, र त्यो दोष प्रमाणीकरण विधि र संरक्षण नीतिबीचको सम्झौता हो। तलका जाँचहरू यसरी क्रमबद्ध छन् कि प्रत्येकले अर्कोभन्दा सस्तो कारण हटाउँछ।

एउटै PPTP जडानभित्र दुई वार्ता चल्छन्

PPTP ले GRE टनेलभित्र सामान्य PPP सत्र बोक्छ, र दुवै छुट्टाछुट्टै वार्ता गर्छन्। बाहिरी तहले प्याकेट कसरी इन्क्याप्सुलेट हुने र कुन नियन्त्रण च्यानल रहने निर्धारण गर्छ; भित्री PPP सत्रले साथी को हो र माथि कुन संरक्षण चल्छ भन्ने निर्धारण गर्छ। त्यसैले पासवर्डको अनुरोधले भित्री तहको बारेमा मात्र केही प्रमाणित गर्छ, र पूरा भएको बाहिरी ह्यान्डशेकले दुवैमध्ये कसैको बारेमा केही प्रमाणित गर्दैन। प्रोफाइलहरू यहाँ असफल हुन्छन् किनभने मानिसहरू टनेल डिबग गर्छन् जबकि मतभेद PPP भित्र बसेको हुन्छ।

सामान्य CHAP भनेको RFC 1994 को चुनौती-प्रतिक्रिया आदानप्रदान हो, साझा रहस्य र अरू केहीमा होइन आधारित। MS-CHAPv2 फरक सन्देश र फरक आउटपुट भएको अर्को आदानप्रदान हो, RFC 2759 मा मानकीकृत। दुई नाममा साझा शब्द नै तारमा उनीहरूको एकमात्र साझा कुरा हो। कुनै पनि नामले आदानप्रदानले के उत्पादन गर्छ भन्ने बताउँदैन, र त्यही एकमात्र महत्त्वपूर्ण भाग हो।

त्यसैले केवल CHAP लेबल भएको विकल्प पुरानो प्रोफाइलमा अस्पष्ट हुन्छ। जब सर्भरले MS-CHAPv2 चाहन्छ र क्लाइन्टले सामान्य CHAP प्रस्ताव गर्छ, लिङ्क नियन्त्रण अझै पूरा हुन सक्छ र पासवर्ड अझै स्वीकारिन सक्छ। असफलता पछि आउँछ, जब सर्भरले केही उत्पादन नगरेको आदानप्रदानबाट संरक्षण कुञ्जी निकाल्न खोज्छ।

आवश्यक विधिलाई यसले उत्पादन गर्न सक्ने कुञ्जीसँग मिलाउनुहोस्

MPPE कुञ्जीहरू सामान्य रूपमा PPP को गुण होइनन्। Microsoft CHAP परिवारका लागि व्युत्पत्ति RFC 3079 मा निर्दिष्ट छ, र यसले इनपुटको रूपमा साझा रहस्यको सट्टा MS-CHAP आदानप्रदानको आउटपुट लिन्छ। EAP विधिहरू अर्को बाटोबाट त्यही ठाउँमा पुग्छन्, जहाँ प्रमाणीकरण सर्भरले कुञ्जीहरू MS-MPPE-Recv-Key र MS-MPPE-Send-Key विशेषताका रूपमा फर्काउँछ। सामान्य CHAP दुवै बाटोमा कतै देखिँदैन, र यो असमझदारी हुनुको पूरै कारण त्यही हो।

कुञ्जी दिन सक्ने हरेक विधि अस्वीकार गर्दै MPPE माग्ने कन्फिगरेसन आन्तरिक रूपमा विरोधाभासी हुन्छ। pppd त्यो विरोधाभास कुञ्जी बनाएर होइन, लिङ्क अस्वीकार गरेर समाधान गर्छ, त्यसैले देखिने परिणाम प्रमाणीकरण गरेर त्यसपछि नेटवर्क चरणमा अन्त्य हुने सत्र हो। सर्भरले केही व्युत्पन्न गर्ने एकमात्र विधिहरू अस्वीकार गरिरहेसम्म क्लाइन्ट फेरि प्रयास गर्दा त्यो बदलिँदैन।

यसबाट आउने नियम छोटो छ: प्रोफाइलले MPPE माग्छ भने विधि MS-CHAP को प्रकार वा सर्भरले कुञ्जी फर्काउने EAP विधि हुनुपर्छ। केवल MS-CHAPv2 अस्वीकार गर्दा त्यो लागू हुँदैन, किनभने MS-CHAPv1 पनि कुञ्जी व्युत्पन्न गर्छ र छुट्टै अस्वीकार नगरेसम्म उपलब्ध रहन्छ; दुवै अस्वीकार गर्दा सामान्य CHAP र PAP बाँकी रहन्छन्, जसले केही व्युत्पन्न गर्दैनन् र आवश्यकतालाई अपूरणीय बनाउँछन्। मन नपर्नेको सूची बनाउनुको सट्टा स्वीकारिएको विधिको स्पष्ट नाम दिनुहोस्। क्लाइन्ट जोडियोस् भनेर इन्क्रिप्शनको आवश्यकता छोड्नु मर्मत होइन, अवनति हो।

क्लाइन्ट सम्पादन गर्नुअघि सर्भरका विकल्प पढ्नुहोस्

यी असमझदारीमध्ये धेरैजसो सर्भरमा दुई फाइलमा देखिन्छन्, र ती पढ्नु क्लाइन्ट पुनर्निर्माण गर्नुभन्दा सस्तो हुन्छ। Linux PPTP इन्डपोइन्टमा सम्बन्धित सेटिङहरू pptpd ले पठाउने pppd विकल्प फाइलमा बस्छन्। यसलाई सर्भरमा चलाउनुहोस्, क्लाइन्ट स्थिति स्क्रिनबाट होइन। संरक्षण मोड माग्ने, अस्वीकार गर्ने वा नाम दिने लाइनबाट सुरु गर्नुहोस्:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

आउटपुटलाई फ्ल्यागको सूची होइन, सम्झौता का रूपमा पढ्नुहोस्। MPPE माग्दै MS-CHAP का दुवै प्रकार अस्वीकार गर्ने लाइन कुनै पनि क्लाइन्टले पूरा गर्न सक्दैन, र MS-CHAP विधिका लागि आवश्यकता नहुनु कुञ्जी नदिने आदानप्रदानका लागि ढोका खुला राख्छ। त्यसपछि कसलाई प्रमाणीकरणको अनुमति छ भनी जाँच गर्नुहोस्, यो रहस्य फाइलले निर्धारण गर्छ:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

केही परिवर्तन गर्नुअघि तीन मान लेख्नुहोस्: बाहिरी प्रोटोकल, सर्भरले माग्ने प्रमाणीकरण विधि, र संरक्षण अनिवार्य हो वा वैकल्पिक। यी तीनले पछिका हरेक निर्णय निर्धारण गर्छन्, र क्लाइन्ट संवादबाट तिनीहरूको अनुमान लगाउनु नै प्रोफाइल आधा कन्फिगर भएर बस्ने बाटो हो। काम गर्दा फाइल खुला राख्नुहोस्, किनभने अर्को खण्डलाई तीही तीन मान चाहिन्छ।

PPP चरण अनुसार असफलता पत्ता लगाउनुहोस्

PPP ले असफलताहरू चरणमा जनाउँछ, र चरणले सम्झौताको कुन धारा भाँचियो भन्ने बताउँछ। जुन लिङ्क कहिल्यै लिङ्क नियन्त्रण छोड्दैन त्यसमा इन्क्याप्सुलेसन वा वार्ताको समस्या हुन्छ, जबकि प्रमाणीकरण गरेर त्यसपछि मर्ने लिङ्कमा सामान्यतया नीति वा कुञ्जीको समस्या हुन्छ। जुन लिङ्क माथि रहन्छ र केही बोक्दैन त्यो राउटिङतिर गएको छ, जुन अर्कै अनुसन्धान हो।

जर्नलले चरणका लाइनहरू राख्छ, र ती उच्च डिबग स्तरभन्दा उपयोगी हुन्छन्। PPP प्रक्रिया र संरक्षण सन्देश माग्नुहोस्, त्यसपछि सबैभन्दा पहिले प्रमाणीकरणको नतिजा पढ्नुहोस्। अन्तिम लाइनहरूले सामान्यतया अस्वीकार गर्ने धाराको नाम दिन्छन्:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

त्यो आउटपुटमा पहिले प्रमाणीकरणको नतिजा र त्यसपछि संरक्षण मागिएको थियो तर वार्ता भएन भन्ने गुनासो खोज्नुहोस्। दोस्रो सन्देश माथिको विरोधाभासको हस्ताक्षर हो, र सर्भरले कुञ्जी उत्पादन गर्न सक्ने एकमात्र विधि अस्वीकार गरिरहेसम्म कति पटक प्रयास गरे पनि त्यो मेटिँदैन। दुई जालको नाम दिन लायक छ: चरणका लाइन नपढी डिबग स्तर बढाउँदा हल्ला उत्पन्न हुन्छ, र चुनौती सामग्री वा पासवर्ड समात्दा कन्फिगरेसनको काम प्रमाणपत्र चुहावटमा बदलिन्छ। कुनै पनि विकल्प बदल्नुअघि त्यो चरण रेकर्ड गर्नुहोस्।

पुरानो इन्डपोइन्ट बन्द हुनुअघि निकासको योजना बनाउनुहोस्

MPPE लिङ्क संरक्षणको ऐतिहासिक संयन्त्र हो, र यसको उपस्थितिले PPTP लाई नयाँ तैनातीका लागि समझदार विकल्प बनाउँदैन। Microsoft को हालको मार्गदर्शनले नयाँ टाढा पहुँच तैनातीका लागि PPTP र पूर्व-साझा कुञ्जीसहित L2TP/IPsec विरुद्ध पहिले नै सल्लाह दिन्छ। पुरानो इन्डपोइन्ट जीवित राख्नु विद्यमान सेवाको बारेमा निर्णय हो, अर्कोका लागि नमुना होइन।

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

जानाजान गरिएको अस्वीकार अस्वीकार नै रहनुपर्छ, किनभने परीक्षा उत्तीर्ण होस् भनेर असुरक्षित मोडमा फर्कनु नीतिको असफलतालाई खुलासामा बदल्छ। तयार अवस्था समर्थित, कागजातीकृत सम्झौता हो, एउटा पुरानो जडान सफल पार्ने सबैभन्दा सानो परिवर्तन समूह होइन। प्रतिस्थापनले तीही जाँच पास नगरेसम्म पुरानो प्रोफाइललाई यसको ठाउँमा, नप्रयोग गरिएको र कागजातीकृत राख्नुहोस्।