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 मा पनि निर्भर छ, जसका अभिलेखित कमजोरीहरूले त्रुटि हटेपछि पनि यसलाई नयाँ परिनियोजनका लागि खराब विकल्प बनाउँछन्।

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