हॉटस्पॉट से PPTP: TCP 1723 केवल आधा हिस्सा है

जाँचें क्रम से करें: नियंत्रण कनेक्शन खुलता है या नहीं, GRE रास्ते में टिकता है या नहीं, सर्वर कॉल स्वीकार करता है या नहीं, और प्रमाणीकरण पूरा होता है या नहीं। PPTP क्लाइंट को 1723 पर TCP सत्र और डेटा ले जाने वाला GRE रास्ता दोनों चाहिए, और हॉटस्पॉट एक को पार करके दूसरे को गिरा सकता है। इन्हें क्रम से करने पर अनुमान लगाने के बजाय पता चलता है कि कौन-सी सीमा जाँचनी है। Windows के त्रुटि नंबर आपके लिए यह नहीं करते।

GRE IP प्रोटोकॉल 47 है। यह TCP या UDP पोर्ट 47 नहीं है, और यही अंतर फ़ायरवॉल के बारे में अधिकांश भ्रम समझाता है।

दो रास्ते, एक कनेक्शन

नियंत्रण कनेक्शन गंतव्य पोर्ट 1723 पर एक सामान्य TCP सत्र है, जिसे अधिकांश नेटवर्क बिना शिकायत के अनुमति देते हैं। डेटा पथ GRE, प्रोटोकॉल 47 है, और पहले को अनुमति देने वाला फ़ायरवॉल दूसरे से पूरी तरह अनजान हो सकता है। यह संयोजन ऐसा क्लाइंट बनाता है जो शुरू होता दिखता है और फिर कुछ नहीं ले जाता, जो अस्वीकृत कनेक्शन से कहीं कम सूचनाप्रद लक्षण है। ऑपरेटर के बारे में कुछ भी निष्कर्ष निकालने से पहले दोनों रास्ते अलग-अलग जाँचें।

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

हॉटस्पॉट दो और सीमाएँ जोड़ता है

क्लाइंट ट्रैफ़िक आमतौर पर फ़ोन के अपने साझा NAT और फिर सर्वर तक पहुँचने से पहले ऑपरेटर-स्तरीय अनुवाद से गुजरता है। ऑफ़िस राउटर पर एक नियम किसी और के स्वामित्व वाले मध्य-बॉक्स को ठीक नहीं कर सकता, इसलिए घर की ओर पोर्ट फ़ॉरवर्डिंग शायद ही कभी मदद करती है। बाहर जाने वाले क्लाइंट को भीतर आने वाला पोर्ट खोलने की भी जरूरत नहीं होती; अनुवादित कनेक्शन के उत्तर गेटवे द्वारा बनाई गई स्थिति से लौटते हैं। NAT के पीछे होस्ट किए गए सर्वर की आवश्यकताएँ पूरी तरह अलग होती हैं।

PPTP passthrough नाम का मेनू आइटम, जहाँ मौजूद हो, यह तय करता है कि वह डिवाइस इस प्रोटोकॉल को कैसे संभालता है। यह फ़ोन पर VPN होस्ट करने या हर प्रोटोकॉल को बिना शर्त आगे भेजने जैसी वही सुविधा नहीं है, और इसे सक्षम करना GRE पार करने की सामान्य अनुमति नहीं है।

807 को फैसला नहीं, रुकावट के रूप में पढ़ें

Windows 807 को बाधित कनेक्शन के रूप में बताता है, जो कारण नहीं बल्कि परिणाम का वर्णन करता है। इसकी त्रुटि तालिका 806 को GRE-संबंधित श्रेणी के रूप में अलग रखती है, और सिद्धांत बनाने से पहले यह अंतर जानने योग्य है। कोई भी संख्या यह नहीं बताती कि ऑपरेटर ने प्रोटोकॉल 47 फ़िल्टर किया, सर्वर की क्षमता खत्म हुई, या क्रेडेंशियल सही थे। त्रुटि कहती है कि सत्र समाप्त हुआ; रास्ता बताता है कि कहाँ।

हॉटस्पॉट पर सफल ब्राउज़र परीक्षण केवल यह साबित करता है कि सामान्य एप्लिकेशन पथ काम करता है। यह GRE के बारे में कुछ नहीं कहता।

जो चरण विफल हुआ उसे अलग करें

लैपटॉप, सर्वर और प्रोफ़ाइल स्थिर रखें, फिर केवल एक्सेस नेटवर्क को किसी अन्य स्वीकृत नेटवर्क में बदलें। परिणाम बदलता है तो, जिन सीमाओं को आप नियंत्रित करते हैं उन पर TCP और GRE का आदान-प्रदान कैप्चर करें और सबसे शुरुआती चरण खोजें जो कभी नहीं होता: नियंत्रण स्थापना, कॉल सेटअप, डेटा वितरण, या PPP प्रमाणीकरण। हर एक कैप्चर में अलग हस्ताक्षर छोड़ता है। काम करने वाले नेटवर्क की असफल नेटवर्क से तुलना त्रुटि का पाठ फिर पढ़ने से कहीं अधिक सूचनाप्रद है।

यह सब पहले से मौजूद परिनियोजन का निदान करता है। यह नई PPTP सेवा खड़ी करने का तर्क नहीं है, और प्रोटोकॉल को बातचीत से दरकिनार नहीं किया जा सकता: अलग क्लाइंट स्थापित करने से अपरिवर्तित सर्वर कुछ और नहीं बोलने लगता।

निरंतर पहुँच के लिए, VPN के मालिक के साथ समर्थित माइग्रेशन पर सहमत हों। चेकलिस्ट किसी उपाय के बजाय निर्णय के साथ समाप्त होती है।