PPTP त्रुटि 800 बनाम 812 और एक मिनट बाद कनेक्शन टूटना

एक PPTP क्लाइंट के तीन त्रुटि संदेश आमतौर पर तीन अलग खराबियों का वर्णन करते हैं। त्रुटि 800 का अर्थ है कि टनल कभी बना ही नहीं, त्रुटि 812 का अर्थ है कि सर्वर ने प्रमाणीकरण विधि अस्वीकार कर दी, और एक मिनट बाद टूटना एक keepalive टाइमर है जो तय करता है कि स्वस्थ साथी चला गया। हर चरण अपने कारण से विफल होता है, इसलिए हर एक को अपनी जाँच चाहिए।

त्रुटि 800 का अर्थ है कि टनल कभी बना ही नहीं

Windows त्रुटि 800 तब उठाता है जब वह टनल बिल्कुल नहीं बना सकता, और अनुपलब्ध सर्वर या अनुपयुक्त सुरक्षा मापदंडों के बारे में पाठ निदान नहीं बल्कि सारांश है। PPTP को किसी भी क्रेडेंशियल की जाँच से पहले नेटवर्क से दो अलग चीजें चाहिए। TCP 1723 नियंत्रण चैनल ले जाता है, और IP प्रोटोकॉल 47, यानी GRE, एनकैप्सुलेटेड पेलोड ले जाता है।

उस बाहरी मार्ग को अपने LAN के बाहर से जाँचें, क्योंकि दफ्तर के अंदर काम करने वाला कनेक्शन किनारे के बारे में कुछ सिद्ध नहीं करता:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

अगर 1723 जवाब देता है और क्लाइंट के जुड़ने की कोशिश करते समय कैप्चर खाली रहता है, तो मार्ग प्रोटोकॉल 47 गिरा रहा है। ऐसा राउटर जिसमें 1723 फ़ॉरवर्ड है पर PPTP पासथ्रू बंद है, ठीक वही पैटर्न देता है: TCP हैंडशेक पूरा होता है, फिर GRE पैकेट गायब हो जाते हैं, इसलिए विफलता क्रेडेंशियल की समस्या जैसी दिखती है, हालाँकि कोई लॉगिन प्रयास नहीं किया गया।

फ़ॉरवर्डिंग को सर्वर के मौजूदा LAN पते पर निर्देशित करें, जहाँ राउटर देता है वहाँ PPTP पासथ्रू चालू करें, और उसी बाहरी स्थान से फिर कोशिश करें। जब GRE ऊपर की ओर फ़िल्टर होता है और आप उसे बदल नहीं सकते, तो TCP 443 पर SSTP या UDP 500 और 4500 पर L2TP/IPsec के पास Windows की ओर आपके किसी भी बदलाव से बेहतर संभावना है।

त्रुटि 812 का अर्थ है सर्वर का आपकी प्रमाणीकरण विधि को अस्वीकार करना

त्रुटि 812 टनल के ऊपर आने के बाद लौटती है, इसलिए यह पासवर्ड की समस्या जैसी लगती है। सर्वर कनेक्शन के लिए तय प्रमाणीकरण विधि को अस्वीकार कर रहा है, ज़रूरी नहीं कि पासवर्ड को ही। क्लाइंट पर VPN प्रविष्टि खोलें, सुरक्षा टैब पर जाएँ, प्रकार को Point-to-Point Tunneling Protocol पर सेट करें, स्पष्ट प्रोटोकॉल सूची चुनें और Microsoft CHAP संस्करण 2 पर टिक लगाएँ।

आप डायलॉग में क्लिक किए बिना मौजूदा सेटिंग पढ़ सकते हैं:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

जो सर्वर MS-CHAP v2 माँगता है वह PAP पर या ऐसे स्वचालित प्रकार पर छोड़े गए क्लाइंट को अस्वीकार करता है जो कुछ कमज़ोर तय करता है, और त्रुटि किसी भी उपयोगकर्ता पासवर्ड के मूल्यांकन से पहले आती है। खाता प्रारूप उसी अस्वीकृति का दूसरा आधा हिस्सा है। एक मामले में Windows ने MicrosoftAccount\[email protected] आकार की Microsoft खाता पहचान भेजी जबकि सर्वर स्थानीय या डोमेन खाता चाहता था। SERVERNAME\username लिखने से Windows को बताया गया कि किस खाता भंडार से परामर्श लेना है और त्रुटि हट गई। नाम हाथ से दर्ज करें, सहेजे गए क्रेडेंशियल को पिछला प्रारूप दोहराने देने के बजाय।

एक मिनट बाद टूटना एक keepalive निर्णय है

जब टनल जुड़ता है, थोड़ा ट्रैफ़िक गुज़ारता है और फिर डिस्कनेक्ट हो जाता है, तो क्लाइंट को छूने से पहले सर्वर का LCP इको व्यवहार देखें। डेमन समय-समय पर साथी से पुष्टि करने को कहता है कि वह अब भी वहाँ है। अगर तय बजट के भीतर बहुत कम उत्तर आते हैं, तो सत्र तोड़ दिया जाता है, भले ही उपयोगकर्ता के पास अब भी काम करने वाला लिंक हो।

Linux pptpd सर्वर पर वे मान /etc/ppp/options.pptpd में रहते हैं, और सामान्य मरम्मत अंतराल छोटा करने के बजाय बजट बढ़ाना है:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

पाँच सेकंड के अंतराल पर तीस चूक एक छोटी रुकावट को माफ कर देती हैं, साथी को गया घोषित करने के बजाय। संख्या को एक या दो करने से अनुवादित मार्ग पर सामान्य जिटर लगभग हर मिनट डिस्कनेक्शन बन जाता है। अगर आपका सर्वर pptpd के बजाय Windows RRAS है, तो इसके बजाय PPP सत्र का समय-समाप्ति और निष्क्रियता पर डिस्कनेक्ट नीति देखें। वे कहीं और रहते हैं, और जो pppd फ़ाइल नहीं है उसे संपादित करने से कुछ नहीं बदलेगा।

अतिव्यापी सबनेट डेटा पथ तोड़ते हैं

PPTP टनल साफ़ तरीके से प्रमाणित हो सकता है और फिर भी कहीं नहीं पहुँच सकता जब दोनों साइटें एक ही निजी श्रेणी इस्तेमाल करती हैं, उदाहरण के लिए दफ्तर और घर में 192.168.1.0/24। क्लाइंट यह नहीं बता सकता कि दिया गया पता किस होस्ट को संदर्भित करता है, और कुछ स्टैक एक चुनने के बजाय रूट स्थापित करने से ही इंकार कर देते हैं।

इसे डिज़ाइन दोष मानें और एक तरफ़ को फिर से क्रमांकित करें, या क्लाइंट को जान-बूझकर अनूदित प्रवेश श्रेणी दें। PPTP क्लाइंट को डीबग करना दो बार मौजूद पता स्थान को ठीक नहीं कर सकता, और लक्षण बेतरतीब टूटने जैसा ही दिखता रहेगा।

उस चरण से शुरू करें जो विफल हुआ: 800 के लिए GRE, 812 के लिए विधि और खाता स्ट्रिंग, समय-सारणी के अनुसार मरने वाले टनल के लिए इको सेटिंग्स।