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 चा प्रयत्न चालतो आणि दूरचा प्रमाणीकरणापर्यंत पोहोचत नाही, तर बाहेरील मार्ग ही समस्या आहे. दोन्ही प्रमाणित होतात आणि फक्त दूरच्या क्लायंटला इंटरनेट नाही, तर पूल आणि बाहेर पडण्याकडे परत जा.