Windows VPN मा इन्टरनेट छैन? ठेगाना पूल शंकास्पद छ

Windows ले टनेललाई जोडिएको देखाउँछ र इन्टरनेट पहुँच छैन भन्ने लेबल दिन्छ, जसलाई मानिसहरू Windows को विचित्रता भनेर पढ्छन्। यो क्लाइन्टले के प्राप्त गर्यो भन्ने कथन हो: प्रयोगयोग्य डिफल्ट गेटवे छैन, चल्ने रिजोल्भर छैन, वा टनेलभित्रका ठेगानाहरूका लागि फर्कने बाटो छैन। सर्भर Windows Incoming Connection हुँदा, एउटै सेटिङले यस्ता अधिकांश रिपोर्टहरू व्याख्या गर्छ। लेबल निदान होइन, तर खोजीलाई तीन ठाउँमा सीमित गर्छ।

परिवर्तन गर्नुअघि लीज पढ्नुहोस्

क्लाइन्टमा ipconfig /all चलाउनुहोस् र प्रविष्टिहरूमाझ VPN एडाप्टर खोज्नुहोस्। यसले सूचीबद्ध गर्ने ठेगाना, डिफल्ट गेटवे र DNS सर्भर तपाईंलाई चाहिने तथ्य हुन्, र ती प्रशासकले वितरण गरिएको ठान्नेभन्दा प्रायः फरक हुन्छन्।

तीन ढाँचा तीन खराबीसँग मिल्छन्। 169.254.0.0/16 मा ठेगाना भन्नुको अर्थ क्लाइन्टले केही पाएन र आफैंलाई लिंक-लोकल ठेगाना दियो। गेटवे नभएको विश्वसनीय ठेगाना भन्नुको अर्थ क्लाइन्टलाई डिफल्ट मार्ग दिने विकल्पबिना पूल दिइयो। पूर्ण लीज तैपनि कतै नपुगेमा सर्भर पक्षको फर्वार्डिङ वा अनुवादतर्फ संकेत गर्छ।

सर्भर छुनुअघि मानहरू लेख्नुहोस्। अर्को चरणले तिनलाई सर्भरले बाँडिरहेको ठान्ने दायरासँग तुलना गर्छ, र सम्झना लीजको खराब विकल्प हो।

स्वतः तोकाइले गेटवे किन नरहन सक्छ

Incoming Connections प्रविष्टिका भौतिक एडाप्टरबाट अलग आफ्नै IPv4 गुणहरू हुन्छन्। त्यहाँको डिफल्टले ठेगानाहरू स्वतः तोक्ने प्रस्ताव गर्छ, जुन ठेगाना, मास्क, गेटवे र DNS दिन कनेक्शनको अन्तर्निहित बाँडफाँटकर्तामा निर्भर हुन्छ।

स्वतन्त्र वर्कस्टेशनमा त्यो बाँडफाँटकर्तासँग लिने कुनै दायरा हुँदैन, जबसम्म मेसिनमा अरू केहीले एउटा दिँदैन, त्यसैले क्लाइन्ट लिंक-लोकल ठेगानामा वा ठेगाना भए पनि गेटवेबिना रहन सक्छ। लिंक माथि आएकाले कनेक्शन स्थापित देखिन्छ, तर त्यसपछिको कन्फिगरेसन अपूर्ण हुन्छ।

त्यसैले निर्दिष्ट दायरामा जानु यस्ता धेरै रिपोर्ट सुधार्छ। तपाईं चलिरहेको नहुन सक्ने सेवालाई लीज कल्पना गर्न भन्न छोड्नुहुन्छ र आफैं लीज भन्न थाल्नुहुन्छ।

त्यही भ्रम तब देखिन्छ जब कोही LAN राउटरको DHCP सर्भरले टनेल क्लाइन्टलाई सेवा दिन्छ भन्ने अपेक्षा गर्छ। ब्रोडकास्ट खोज रुट गरिएको टनेल पार गर्दैन, त्यसैले त्यो सर्भरले अनुरोध कहिल्यै देख्दैन। उल्टो मान्नु नै पूलमाथि त्यस्तो क्लाइन्टको दोष थोपर्ने सबैभन्दा सामान्य कारण हो जसले त्यसलाई कहिल्यै केही सोधेन।

सर्भरले रुट गर्न सक्ने स्पष्ट दायरा सेट गर्नुहोस्

सर्भर पुग्न सक्ने सबनेटभित्र सानो ब्लक छान्नुहोस्, LAN राउटरले बाँड्ने दायराबाहिर र नेटवर्कको अरू कुनै पूलबाहिर। सर्भर 172.20.10.0/24 मा छ र राउटरसँग 172.20.10.1 छ भने, त्यो सबनेटको माथिल्लो भागनजिक सानो ब्लक, मानौं 172.20.10.201 देखि 172.20.10.209 सम्म, टनेल लीजहरूलाई राउटरले पहिले नै व्यवस्थापन गरिरहेको बाँडफाँटबाट टाढा राख्छ।

यसलाई Incoming Connection को IPv4 गुणहरूमा राख्नुहोस्, क्लाइन्ट फेरि जोड्नुहोस्, र अरू केही परिवर्तन गर्नुअघि एडाप्टर फेरि पढ्नुहोस्। दोस्रो पढाइले नै पूल खराबी थियो कि धेरैमध्ये एउटा मात्र खराबी थियो भनी बताउँछ।

यी आदेशहरूले परिणामस्वरूप कन्फिगरेसन र क्लाइन्टसँग अहिले भएका मार्गहरू छाप्छन्:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

लीजको गेटवे सर्भरसँग भएको ठेगाना हुनुपर्छ, र क्लाइन्टको डिफल्ट मार्गले त्यसतर्फ संकेत गर्नुपर्छ। लीज पूर्ण भए पनि मार्ग छैन भने, सर्भरले गेटवे धकेल्नुबिना तोक्यो, र पूल सेटिङहरू अझै हेर्ने ठाउँ हुन्।

ठेगाना इन्टरनेटको बाटो होइन

लीज प्राप्त गर्नुले प्याकेटहरूलाई क्लाइन्टबाट सर्भरतर्फ मात्र सार्छ। इन्टरनेट पहुँचका लागि सर्भरले ती प्याकेट अगाडि पठाउनुपर्छ र आफ्नै अपलिंकतर्फ अनुवाद गर्नुपर्छ, र त्यो आफ्नै असफलता-अवस्था भएको छुट्टै कन्फिगरेसन हो।

Internet Connection Sharing छोटो बाटो हो। यसले इन्टरनेटतर्फ फर्केको एडाप्टरलाई साझा गेटवे बनाउँछ र आफ्नै ठेगाना असाइनमेन्ट चलाउँछ, जसले त्यो एडाप्टरको ठेगाना पुनः लेख्न सक्छ र विद्यमान NAT नियमलाई अब नभएको मानतर्फ संकेत गर्दै छोड्न सक्छ। सक्षम गर्नुअघि मूल सेटिङहरू अभिलेख गर्नुहोस्।

रुट गरिएको विकल्पले ठेगाना असाइनमेन्ट स्थिर राख्छ र फर्वार्डिङ तथा अनुवाद स्पष्ट रूपमा कन्फिगर गर्न भन्छ। कुनै पनि दृष्टिकोण गलत होइन; दुवैलाई आधा बाटोमा मिसाउँदा लीज भएको तर निस्कने बाटो नभएको टनेल बन्छ, र त्यो ठ्याक्कै तपाईंले सुरु गरेको लक्षण हो। एउटा मोडेल छान्नुहोस् र अर्को थप्नुअघि त्यो पूरा गर्नुहोस्।

पहिले बाहिरी बाटो हटाउनुहोस्

टनेल कहिल्यै बनेन भने कुनै पूलले मद्दत गर्न सक्दैन। प्रोटोकलले बाटोले के बोक्नुपर्ने निर्धारण गर्छ: PPTP लाई TCP 1723 र GRE चाहिन्छ, GRE पोर्ट होइन, IP प्रोटोकल 47 हो; L2TP/IPsec लाई UDP 1701 साथै 500 र 4500 चाहिन्छ; SSTP लाई TCP 443 चाहिन्छ।

पोर्ट फर्वार्ड गर्ने तर प्रोटोकल नगर्ने राउटरले कहिल्यै प्रमाणित नहुने जडान प्रयास उत्पन्न गर्छ। टनेल बनेपछि कतै नपुग्ने अवस्थाभन्दा यो फरक असफलता हो, र दुवैलाई सँगै डिबग गर्नु हुँदैन।

उही LAN बाट र टाढाको नेटवर्कबाट परीक्षण गर्नुहोस्। LAN को प्रयास चल्यो र टाढाको प्रमाणीकरणसम्म पुग्न सकेन भने, बाहिरी बाटो समस्या हो। दुवै प्रमाणित भए र टाढाको क्लाइन्टलाई मात्र इन्टरनेट छैन भने, पूल र निस्कने बाटोतर्फ फर्कनुहोस्।