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 अभी भी संदिग्ध है। यही क्रेडेंशियल भंडार के बजाय कैप्चर पर लौटने का क्षण है।