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, या NAT-T के साथ L2TP/IPsec जो ESP को UDP 4500 में लपेटता है। PPTP MS-CHAPv2 पर भी निर्भर है, जिसकी प्रलेखित कमज़ोरियाँ त्रुटि दूर होने के बाद भी इसे नए परिनियोजन के लिए खराब विकल्प बनाती हैं।

लिख लें कि किस नियम ने अंतर पैदा किया, क्योंकि दूसरा उपयोगकर्ता पहुँच माँगने पर वही साइट वही सीमा फिर पाएगी। प्रोटोकॉल स्तर का सुधार नेटवर्क नोट्स में होना चाहिए, जहाँ अगला अभियंता देखेगा।