Windows पर VPN स्थानीय LAN को अवरुद्ध करता है: रूट या क्लाइंट नीति?
Windows पर स्थानीय LAN तक पहुँच दो अलग कारणों से टूटती है: गायब रूट, या ऐसी गेटवे नीति जो सबनेट को गिरा देती है। तीन जाँच बताती हैं कौन-सा।
आपके अपने डेस्क पर रखा प्रिंटर, NAS या डेवलपमेंट बॉक्स उसी पल जवाब देना बंद कर देता है जब काम का VPN जुड़ता है। कभी एक रूट कमांड उसे सेकंडों में ठीक कर देता है; कभी वही रूट सही होता है और पैकेट फिर भी गायब हो जाते हैं, जिसका मतलब है कि आप मिलते-जुलते लक्षण वाली कोई दूसरी समस्या देख रहे हैं। फैसला तीन सवालों पर आता है, और उन्हें गलत क्रम में पूछना ही वह कारण है जिससे लोग पूरी शाम रूट हटाते और फिर जोड़ते रहते हैं।
किसी भी कमांड से पहले तीन सवाल
पहला: क्या स्थानीय प्रीफ़िक्स के लिए कोई प्रविष्टि है, और क्या वह भौतिक अडैप्टर की ओर इशारा करती है? दूसरा: क्या कनेक्ट होते समय क्लाइंट को गेटवे से स्थानीय नेटवर्क की अनुमति या मनाही मिलती है? तीसरा: क्या आपको केवल LAN तक बाहर जाने की पहुँच चाहिए, या इंटरनेट पर किसी चीज़ को भी आपकी मशीन पर चल रही सेवा तक पहुँचना है?
पहला सवाल रूटिंग खराबी को फ़िल्टरिंग खराबी से अलग करता है। दूसरा बताता है कि रूट सुधार को काम करने की अनुमति है या नहीं। तीसरा मरम्मत बदलता है: रूट बाहर जाने वाले ट्रैफ़िक को ठीक करता है, जबकि पहुँच से बाहर आने वाली सेवा आमतौर पर लिसनर बाइंडिंग और वापसी-पथ की समस्या होती है जिसे रूट और बिगाड़ देता है।
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
सवाल एक: रूट, फ़िल्टर या नाम
कुछ भी जोड़ने से पहले तालिका पढ़ें। इंटरफ़ेस इंडेक्स मायने रखता है, क्योंकि नीचे का हर रूट कमांड उसी पर टिका है:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricसीधे जुड़ा सबनेट आमतौर पर टनल चालू रहने पर भी ऑन-लिंक रूट बनाए रखता है, इसलिए प्रविष्टि मौजूद हो सकती है और ट्रैफ़िक फिर भी विफल हो सकता है। यही संयोजन रूटिंग के बाद चलने वाले फ़िल्टर की पहचान है, और यही वह स्थिति है जहाँ दूसरा, ज़्यादा विशिष्ट रूट कुछ भी नहीं बदलता।
पते से और नाम से अलग-अलग जाँचें। अगर ping 192.168.1.50 जवाब देता है और net view 192.168.1.50 नहीं, तो रूटिंग तालिका कभी समस्या नहीं थी: टनल ने रिज़ॉल्वर बदल दिया और स्थानीय नाम अब हल नहीं होता। उसके लिए रूट जोड़ना व्यर्थ काम है।
सवाल दो: क्या गेटवे स्थानीय LAN तक पहुँच की अनुमति देता है?
व्यावसायिक क्लाइंट सिर्फ़ रूट इंस्टॉल नहीं करता। उसे कनेक्ट होते समय एक नीति मिलती है, और उस नीति में स्पष्ट स्थानीय-नेटवर्क अनुमति हो सकती है। Cisco IPsec परिनियोजनों में समूह नीति split-tunneling सेटिंग और अलग स्थानीय LAN पहुँच फ़्लैग रखती है; क्लाइंट का चेकबॉक्स एक अनुरोध है जिसे गेटवे अस्वीकार कर सकता है। AnyConnect में प्रोफ़ाइल split की शामिल और बहिष्कृत सूचियों तथा वही अनुमति नियंत्रित करती है। Windows RRAS पर समकक्ष प्रोफ़ाइल में डिफ़ॉल्ट गेटवे विकल्प और सर्वर द्वारा दिए गए स्थिर रूट हैं।
जब फ़्लैग बंद होता है, तो प्रलेखित व्यवहार यह है कि क्लाइंट सीधे जुड़े सबनेट तक ट्रैफ़िक रोक देता है, भले ही वैध, ज़्यादा विशिष्ट रूट मौजूद हो। इसीलिए क्लाइंट के स्वामित्व वाले न होने वाले रूट भी जोड़ने के सेकंडों बाद गायब हो सकते हैं: क्लाइंट वह स्थिति दोबारा बना रहा है जिसे बनाने को उससे कहा गया था, वह आपसे लड़ नहीं रहा।
क्लाइंट लॉग कनेक्ट होते समय फैसला दर्ज करता है, और उसे पढ़ना मशीन पर किसी भी प्रयोग से तेज़ है। अगर लॉग कहता है कि स्थानीय पहुँच अवरुद्ध है, तो रुकें: कोई भी कमांड-लाइन सुधार उससे नहीं बचता, और बचे हुए रास्ते केवल नीति बदलना, टनल से संसाधन तक पहुँचना, या क्लाइंट को वर्चुअल मशीन में रखकर होस्ट को स्थानीय नेटवर्क पर छोड़ देना हैं।
सवाल तीन: आपको कौन-सी दिशा चाहिए?
पास के डिवाइस तक बाहर जाने वाला ट्रैफ़िक रूटिंग का सवाल है। LAN प्रीफ़िक्स को स्थानीय गेटवे की ओर ऐसे मीट्रिक के साथ इंगित करें जो टनल के डिफ़ॉल्ट रूट को हरा सके:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pदूसरा रूप एक ही डिवाइस को पिन करता है, और जब एक पता ही पूरी आवश्यकता हो तो आप यही चाहते हैं। netsh समकक्ष वही फैसला इंडेक्स के बजाय इंटरफ़ेस नाम से दर्ज करता है:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentजब पता और मास्क मेल न खाएँ तो रूट कमांड पैरामीटर ग़लत है के साथ विफल होते हैं, जैसे /24 मास्क वाला होस्ट पता। सबनेट रूट के लिए नेटवर्क पता और एकल होस्ट के लिए होस्ट मास्क इस्तेमाल करें।
अंदर आने वाला अलग है। उसी मशीन पर VNC या SSH सर्वर पहुँच से बाहर हो जाता है जब आने वाले कनेक्शन के जवाब VPN गेटवे से बाहर चले जाते हैं और कभी वापस नहीं आते। रूट छूने से पहले जाँचें कि सेवा किस पर सुन रही है:
netstat -ano | findstr :5900एक विशिष्ट पते से बँधा लिसनर दूसरे इंटरफ़ेस पर जवाब नहीं देगा। उसे सभी इंटरफ़ेस से बाँधना जानबूझकर लिया गया फैसला है, जो उस नेटवर्क तक सीमित फ़ायरवॉल नियम के साथ लिया जाता है जिस पर आप भरोसा करते हैं। उसके बाद ही रूट मरम्मत वापसी-पथ बहाल करती है।
जो सबसे छोटा बदलाव फ़िट बैठे उसे लागू करें
दूसरा आम कदम IPv4 की उन्नत विशेषताओं में “दूरस्थ नेटवर्क पर डिफ़ॉल्ट गेटवे का उपयोग करें” का निशान हटाना है। यह इंटरनेट ट्रैफ़िक को स्थानीय रखता है, लेकिन एक साथ दो काम करता है: VPN डिफ़ॉल्ट रास्ता रहना बंद कर देता है, और क्लाइंट दूरस्थ नेटवर्क के लिए रूट मिलाना बंद कर देता है, multicast सहित। निशान हटाएँ और दूरस्थ LAN गायब हो जाता है, जब तक सर्वर हर क्लाइंट को ज़रूरी विशिष्ट दूरस्थ प्रीफ़िक्स न भेजे।
यह असमानता काम का क्रम तय करती है। अगर दूरस्थ पक्ष पूरी तरह पहुँच में रहना चाहिए, तो सर्वर से दूरस्थ सबनेट भेजें और स्थानीय डिफ़ॉल्ट को अकेला छोड़ दें। अगर आप सर्वर नहीं बदल सकते, तो टनल द्वारा दिए गए पते के ज़रिए दूरस्थ प्रीफ़िक्स पर स्थायी रूट जोड़ें, और route print से जाँचें कि प्रीफ़िक्स VPN इंटरफ़ेस की ओर है जबकि डिफ़ॉल्ट अब भी भौतिक गेटवे की ओर है।
फिर पुष्टि करें कि मरम्मत दोबारा कनेक्ट पर टिकी रहती है, क्योंकि गैर-स्थायी रूट अडैप्टर के साथ मर जाते हैं और हर कनेक्शन के बाद चलने वाली स्क्रिप्ट उनके लिए ईमानदार जगह है। एक ही सत्र में एक स्थानीय डिवाइस और एक दूरस्थ संसाधन जाँचें, डिस्कनेक्ट करें, फिर कनेक्ट करें और फिर जाँचें। अगर रूट सही दिखते हुए भी स्थानीय डिवाइस विफल रहे, तो सवाल दो पर लौटें: क्लाइंट फ़िल्टर कर रहा है, और जवाब नीति बदलाव है, दूसरा प्रतिस्पर्धी रूट नहीं।