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 अजूनही संशयित आहे. तो क्रेडेन्शियल भांडाराकडे नाही तर कॅप्चरकडे परत जाण्याचा क्षण आहे.