PPTP पासथ्रू नाही: Windows VPN त्रुटी 807 दुरुस्त करा

TCP 1723 फॉरवर्ड केल्याने अनेकदा PPTP चा पहिला भाग उघडतो आणि उर्वरित तुटलेला राहतो, त्यामुळे प्रयत्नात Windows अजूनही त्रुटी 807 देतो। पुढील सहज प्रवृत्ती पोर्ट 47 साठी नियम जोडणे ही असते, आणि हाच टप्पा पूर्ण दुपार वाया घालवतो: GRE हा IP हेडरमधील प्रोटोकॉल क्रमांक आहे, फॉरवर्डिंग टेबल जुळवू शकणारा पोर्ट नाही। राउटरने प्रोटोकॉल 47 पास केला आणि त्याच कॉलशी जोडला तरच बोगदा सुरू होऊ शकतो। खालील विभाग दोन चॅनेल वेगळे करतात आणि नंतर त्यांची एक एक करून चाचणी करतात।

पोर्ट टेबलमध्ये प्रोटोकॉल क्रमांकासाठी ओळ नसते

PPTP वेगवेगळ्या प्रकारे अयशस्वी होणाऱ्या दोन संभाषणांचा वापर करते। TCP 1723 वरील संभाषण कॉल सुरू करते, लिंकची माहिती देत आणि वापरकर्ता डिस्कनेक्ट झाल्यावर ती बंद करते। पेलोड बाजू GRE च्या आत चालते, जिला IP हेडर प्रोटोकॉल क्रमांक 47 ने चिन्हांकित करते, आणि त्या बोगद्याच्या आत PPP लिंकवर बोलणी करते तर MS-CHAPv2 ओळखपत्रे तपासते।

GRE कोणतेही ट्रान्सपोर्ट हेडर वाहत नाही, म्हणून ते कोणतेही पोर्ट उघड करत नाही, त्यामुळे पोर्टसाठी लिहिलेल्या नियमाकडे जुळवण्यासारखे काही नसते। 1723 फॉरवर्ड करणारा राउटर त्या TCP सत्रासाठी मॅपिंग तयार करतो आणि तिथेच थांबतो। दुसरा अर्धा भाग हाताळणारा फर्मवेअर या सुविधेला PPTP पासथ्रू किंवा PPTP ALG म्हणतो, आणि काही फर्मवेअर दोन्हीपैकी काहीही देत नाहीत व ती उणीव कधीच नमूद करत नाहीत। चेकबॉक्सवरील लेबलापेक्षा प्रोटोकॉल 47 अजिबात ओळखला जातो का हे अधिक महत्त्वाचे आहे।

डेटा मार्ग मेल्यावर Windows काय कळवते

त्रुटी 807 सांगते की कनेक्शन पूर्ण होऊ शकले नाही, प्रत्यक्षात याचा अर्थ कॉल सर्व्हरपर्यंत पोहोचला आणि डेटा चॅनेल वर आला नाही। हा वाहतुकीबाबतचा निर्णय आहे, खात्याबाबतचा नाही। ओळखपत्रे किंवा प्रमाणीकरण प्रोटोकॉलची विसंगती दर्शविणारी त्रुटी 691 आहे, त्यामुळे ती तुम्हाला पूर्णपणे दुसरीकडे पाठवते।

पासवर्डला हात लावण्यापूर्वी वाहतुकीवर काम करा। 807 च्या मागे लागून ओळखपत्रे बदलल्याने खरी खराबी जागच्या जागी राहते आणि पुढील प्रयत्न वाचणे कठीण होते।

दुसरा क्लायंट चालणारा बोगदा का तोडतो

त्यांना वेगळे करण्यासाठी पोर्ट नसल्याने, NAT उपकरण दोन HTTPS सत्रे वेगळी करते त्याप्रमाणे दोन PPTP क्लायंट वेगळे करू शकत नाही। म्हणून अनेक ग्राहक उपकरणे एकच PPTP कॉल अनुमत करतात आणि स्रोत पत्त्यावरून त्याचा मागोवा घेतात। एकट्याने चालणारा लॅपटॉप दुसरे यंत्र डायल करताच पूर्ण होणे थांबवतो, आणि क्लायंटच्या बाजूने अपयश यादृच्छिक वाटते। हा नमुना फर्मवेअरचा आहे, आणि कोणताही प्रोफाइल बदल तो बदलणार नाही।

दोन्ही क्लायंट डायल करत असताना कनेक्शन टेबल पाहा। जर नेहमी फक्त पहिला होस्टच मॅपिंग ठेवत असेल, तर राउटरने आपल्या आधाराच्या मर्यादेपर्यंत पोहोचले आहे आणि क्लायंटची कोणतीही सेटिंग ते हलवणार नाही।

कोणता अर्धा भाग अयशस्वी होतो हे सिद्ध करा

राउटरवर काहीही बदलण्यापूर्वी TCP 1723 येत आहे याची खात्री करा, कारण तेच उत्तर तुम्ही कोणता अर्धा भाग तपासत आहात हे ठरवते। हे Windows क्लायंटवरून तुमच्याच सर्व्हर नावाविरुद्ध चालवा। पहिले पोर्टने उत्तर दिले का ते छापते, आणि दुसरे कोणत्याही संवादाशिवाय डायल करते, ज्यामुळे वारंवारचे प्रयत्न तुलनीय होतात।

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

पोर्ट चाचणीत खरे निकाल म्हणजे नियंत्रण चॅनेल उघडे आहे आणि GRE हाच उरलेला संशयित आहे। खोटा निकाल म्हणजे राउटिंग, फिल्टर किंवा फॉरवर्डिंग तुटलेले आहे, आणि GRE मधील कोणताही बदल ते वाचवणार नाही। डेटा बाजू जिथे दिसते तिथेच पाहावी लागेल, सर्व्हरवर किंवा राउटरवर।

tcpdump -ni any proto 47

Wireshark मधील समतुल्य म्हणजे डिस्प्ले फिल्टर ip proto 47, जो कमांड लाइनवर सोयीस्कर नसलेल्या व्यक्तीला देणे सोपे आहे। उत्तरात काहीही बाहेर न जाता GRE आले तर परतीचा मार्ग दुरुस्त करावा लागेल असा अर्थ होतो।

त्रुटी प्रत्यक्षात काय दुरुस्त करते

जिथे राउटर सेटिंग दाखवतो तिथे PPTP पासथ्रू सुरू करा, किंवा नियम स्वीकारणाऱ्या फर्मवेअरवर प्रोटोकॉल 47 स्पष्टपणे परवानगी द्या। RouterOS मध्ये फॉरवर्डिंग नियम थेट प्रोटोकॉलशी जुळतो, जे पोर्ट-आधारित फॉरवर्डिंगला कधीच करता आले नसते। ग्राहक फर्मवेअर सहसा तोच निर्णय चेकबॉक्समागे लपवते, कधीकधी पोर्ट फॉरवर्डिंगऐवजी सुरक्षा सेटिंग्जखाली। असे नियंत्रण नसल्यास, क्लायंटवर काहीही त्याची भरपाई करणार नाही।

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP बदलणे हा दुसरा पर्याय आहे आणि बऱ्याचदा स्वस्त। VPN स्वतः संपवणारा राउटर येणाऱ्या क्लायंटसाठी दुहेरी NAT टाळतो, आणि पोर्ट-आधारित NAT आधीच हाताळत असलेल्या प्रोटोकॉलला पासथ्रूची गरजच नसते: UDP वर OpenVPN, TCP 443 वर SSTP, किंवा ESP ला UDP 4500 मध्ये गुंडाळणाऱ्या NAT-T सह L2TP/IPsec। PPTP MS-CHAPv2 वरही अवलंबून आहे, ज्याच्या नोंदवलेल्या कमकुवतपणांमुळे त्रुटी गेल्यानंतरही ते नवीन उपयोजनासाठी वाईट निवड ठरते।

कोणत्या नियमाने फरक पाडला ते लिहून ठेवा, कारण दुसरा वापरकर्ता प्रवेश मागेल तेव्हा त्याच साइटला तीच मर्यादा भेटेल। प्रोटोकॉल पातळीवरील दुरुस्ती नेटवर्क टिपांमध्ये असावी, जिथे पुढील अभियंता पाहील।