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 चाहिए, जो पोर्ट नहीं बल्कि IP प्रोटोकॉल 47 है; L2TP/IPsec को UDP 1701 के साथ 500 और 4500 चाहिए; SSTP को TCP 443 चाहिए।

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

उसी LAN से और दूर के नेटवर्क से परखें। अगर LAN का प्रयास काम करता है और दूर वाला कभी प्रमाणीकरण तक नहीं पहुँचता, तो बाहरी रास्ता समस्या है। अगर दोनों प्रमाणित हों और केवल दूर का क्लाइंट बिना इंटरनेट हो, तो पूल और निकास पर लौटें।