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 साठी पद्धत आणि खाते स्ट्रिंग, वेळापत्रकानुसार मरणाऱ्या बोगद्यासाठी प्रतिध्वनी सेटिंग्ज।