pptpd मा GRE लेखन असफलता पासवर्ड समस्या होइन

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

दुई सन्देश, दुई फरक खराबी

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

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

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

प्रोटोकल 47 पोर्ट 47 होइन

PPTP ले कल स्थापना गर्न TCP 1723 र पेलोड बोक्न GRE प्रयोग गर्छ। GRE IP प्रोटोकल 47 हो, पोर्ट नम्बर होइन, त्यसैले पोर्ट 47 खोल्ने फायरवाल नियमले केही उपयोगी अनुमति दिँदैन।

मार्गमा रहेको राउटरलाई PPTP passthrough सुविधा वा स्पष्ट GRE अनुमति चाहिन्छ। त्यो बिना TCP ह्यान्डशेक पूरा हुन्छ र टनेलले कहिल्यै प्याकेट बोक्दैन, जसले माथिको पढ्ने असफलता नै उत्पन्न गर्छ। फायरवालमा पोर्ट 47 नियमहरू यो प्रोटोकलमा सबैभन्दा धेरै बर्बाद भएको दिउँसो हुन्।

कुन पक्षले ट्राफिक फालिरहेको छ अनुमान गर्नुको सट्टा सर्भरमा दुवै दिशा एकैचोटि हेर्नुहोस्: tcpdump -ni any port 1723 or proto gre।

यदि 1723 ले कल स्थापना देखाउँछ र GRE शान्त रहन्छ भने, अवरोध होस्टभन्दा माथि छ। यदि GRE आउँछ र डिमन अझै असफल हुन्छ भने, समस्या स्थानीय छ र विकल्पहरू अर्को हेर्ने ठाउँ हुन्।

होस्टले वास्तवमै अगाडि पठाउने ठाउँमा GRE लाई अनुमति दिनुहोस्

GRE का लागि forward नियम राख्नु टनेल ट्राफिक अगाडि पठाउने होस्टमा उचित परीक्षण हो, र यो नीति होइन। एउटा प्रोटोकलको सबै स्वीकार गर्ने परीक्षण नियम निदान हो, डिजाइन होइन। केही सिक्न पर्याप्त राख्नुहोस्, त्यसपछि सीमित नियमले बदल्नुहोस्।

सर्भरलाई नै पठाइएका प्याकेटका लागि input नियम थप्नुहोस्, किनकि forward शृंखलाले तिनीहरूलाई देख्दैन। त्यसपछि जडान प्रयास अघि र पछि नियमका काउन्टर हेर्नुहोस्, जसले प्याकेट आउँछन् कि आउँदैनन् भन्ने बताउँछ।

प्रत्येक रिबुटपछि फेरि चलाउनुको सट्टा वितरणको फायरवाल सेवामार्फत नियम स्थायी बनाउनुहोस्। nftables होस्टमा input र forward दुवै शृंखलामा ip protocol gre मिलाउनुहोस्।

ppp_generic मोड्युल पनि लोड भएको सुनिश्चित गर्नुहोस्, र जडान ट्र्याकिङले फर्कने दिशा फालिरहेको छ कि जाँच्नुहोस्। दुवैले फायरवाल समस्याजस्तो देखिने तर नभएका असफलता उत्पन्न गर्छन्। हराएको केर्नेल मोड्युल जाँच नगरेसम्म ठ्याक्कै अवरुद्ध प्रोटोकलजस्तो देखिन्छ।

विकल्पहरू तपाईंसँग वास्तवमै भएको क्लाइन्टसँग मिलाउनुहोस्

अर्को प्रतिवेदनको सुधार /etc/ppp/pptpd-options मा छ, जहाँ रेसिपीले PAP, CHAP र MSCHAP अस्वीकार गर्छ, सम्बन्धित require लाइनहरू टिप्पणी गर्छ र स्थिति भएको MPPE राख्छ। त्यो रेसिपी एउटै क्लाइन्ट मिश्रणका लागि लेखिएको थियो, र आँखा चिम्लेर प्रतिलिपि गर्दा सामान्य केस बिग्रन्छ। अस्वीकार लाइनहरूलाई सिफारिस होइन, लेखकसँग कुन क्लाइन्ट थिए भन्ने कथनका रूपमा पढ्नुहोस्।

Windows क्लाइन्टलाई सामान्यतया MS-CHAPv2 सँग MPPE-128 चाहिन्छ। ती आवश्यकता राख्नुहोस् र क्लाइन्टले वास्तवमै वार्ता गर्न नसक्ने विकल्प मात्र हटाउनुहोस्।

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

जडान सफल होस् भनेर इन्क्रिप्शन बन्द गर्नु अवनति हो, मर्मत होइन। यस्तो प्रकार ल्याब लिङ्कमा परीक्षण गर्नुहोस्, त्यसपछि सेवा वास्तविक क्लाइन्टसामु जानु अघि इन्क्रिप्शन पुनःस्थापित गर्नुहोस्। असुरक्षित रूपमा चल्ने जडान इमानदारीपूर्वक असफल हुनेभन्दा नराम्रो हो।

क्लाइन्टको त्रुटि नम्बर पढ्नुहोस्

क्लाइन्टको सङ्ख्यात्मक कोडले सर्भर लगभन्दा छिटो चरण साँघुरो गर्छ। अरू केही पढ्नु अघि यो पढ्नुहोस्। 691 भन्नाले प्रमाण-पत्र अस्वीकृत, 721 भन्नाले सर्भरले कहिल्यै जवाफ दिएन, र 619 भन्नाले जडान टुट्यो। नम्बरसँग दुई मिनेटले कन्फिगरेसनसँग एक घण्टा बचाउँछ।

केही सम्पादन गर्नु अघि त्यो कोडलाई सर्भर लगसँग तुलना गर्नुहोस्, र प्रत्येक परिवर्तनपछि उही क्लाइन्टसँग फेरि परीक्षण गर्नुहोस्। अन्यथा दोस्रो असफलता पहिलोको पछाडि लुक्छ र सुधार अप्रभावी देखिन्छ।

जब लगइन सफल हुन्छ र कुनै ट्राफिक चल्दैन, GRE अझै शंकास्पद छ। त्यो प्रमाण-पत्र भण्डारमा होइन, क्याप्चरमा फर्कने क्षण हो।