हॉटस्पॉटमधून 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 च्या मालकासोबत समर्थित स्थलांतरावर सहमत व्हा। चेकलिस्ट उपायाऐवजी निर्णयाने संपते।