हटस्पटमार्फत 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 को मालिकसँग समर्थित माइग्रेसनमा सहमत हुनुहोस्। जाँचसूची कुनै उपायको सट्टा निर्णयसँग अन्त्य हुन्छ।