VPN जुड़ा होने पर भी लोकल नेटवर्क उपलब्ध नहीं? चार जाँच

टनल ऊपर आता है, इंट्रानेट दिखता है, और प्रिंटर जवाब देना बंद कर देता है। लोकल नेटवर्क में कुछ भी खराब नहीं हुआ; क्लाइंट ने उन पतों के लिए इस्तेमाल होने वाला रास्ता बदल दिया है जिन्हें वह अब लोकल नहीं मानता। नीचे दी गई चार जाँच क्रम में करें और जब कोई ठोस असंगति दिखाए तब रुकें, क्योंकि एक ही लक्षण के चार आम कारण होते हैं और उनमें से सिर्फ़ एक VPN बदलकर ठीक होता है।

पहले, क्लाइंट द्वारा लगाई गई रूट तालिका देखें

VPN जुड़ा होने पर क्लाइंट की रूट तालिका खोलें। Linux पर ip route, Windows पर route print या Get-NetRoute, और macOS पर netstat -rn इस्तेमाल करें। आप टनल से जाने वाला डिफ़ॉल्ट रूट और भौतिक डिफ़ॉल्ट रूट का क्या हुआ, यह देख रहे हैं।

फ़ुल-टनल क्लाइंट अक्सर 0.0.0.0/0 बदलने के बजाय दो आधे-डिफ़ॉल्ट रूट जोड़ देता है, 0.0.0.0/1 और 128.0.0.0/1। मूल डिफ़ॉल्ट रूट दिखता रहता है पर हर खोज खो देता है, इसलिए तालिका साबुत लग सकती है जबकि सबनेट से बाहर का सारा ट्रैफ़िक खिसक जाता है। अगर VPN क्लाइंट स्प्लिट-टनल विकल्प देता है और नीति अनुमति देती है, तो वही सबसे साफ़ सुधार है।

अगर टनल को ही डिफ़ॉल्ट रहना है, तो इसके बजाय लोकल सबनेट पिन करें। Linux पर रूट भौतिक इंटरफ़ेस और गेटवे बताता है; Windows पर उसे स्थायी बनाने के लिए -p जोड़ें और अनुमान लगाने के बजाय route print से इंटरफ़ेस नंबर पढ़ें:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

पिन किया गया रूट तभी टिकता है जब तक वह जिस पते को बताता है वह वही रहे। जो लैपटॉप हर कनेक्शन पर अपने Wi-Fi एडाप्टर को फिर से नंबर देता है वह नियम फिर तोड़ देगा, इसलिए सुधार विफल हुआ है यह तय करने से पहले इंटरफ़ेस पता जाँचें।

दूसरे, पुष्टि करें कि पता शुरू से ही लोकल था

अगर गंतव्य जुड़े हुए सबनेट के अंदर है, तो टनल का डिफ़ॉल्ट रूट कभी लागू नहीं होता और VPN कारण नहीं है। 192.168.1.0/24 वाले क्लाइंट पर 192.168.1.40 का प्रिंटर जुड़े हुए रूट का इस्तेमाल करता है; अगर वह पता विफल हो, तो VPN नहीं, बल्कि डिवाइस, स्विच या क्लाइंट का फ़ायरवॉल देखें।

लोगों को भ्रमित करने वाला मामला लोकल सर्वर के लिए सार्वजनिक पता है। लोकल नेटवर्क के अंदर से राउटर के WAN पते तक पहुँचकर वापस आने के लिए हेयरपिन NAT चाहिए, और कई राउटर पोर्ट फ़ॉरवर्डिंग के लिए इसे लागू ही नहीं करते। सार्वजनिक पते के बगल में निजी पता जाँचें। अगर निजी पता काम करता है और सार्वजनिक नहीं, तो VPN ने केवल पहले से मौजूद NAT सीमा उजागर की है।

होस्टनेम इसे और बिगाड़ता है। अगर लोकल नाम अब सार्वजनिक पते पर रिज़ॉल्व होता है, तो क्लाइंट उस रास्ते पर प्रयास करता रहेगा जो वापस नहीं आ सकता। परीक्षण के लिए निजी पता इस्तेमाल करें, फिर दूसरा पोर्ट फ़ॉरवर्ड जोड़ने के बजाय नाम ठीक करें।

तीसरे, देखें कि अब नामों का जवाब कौन देता है

कॉर्पोरेट रिज़ॉल्वर इंट्रानेट जानता है और आम तौर पर NAS होस्टनेम, प्रिंटर के Bonjour नाम या राउटर के लोकल उपनाम के बारे में कुछ नहीं जानता। जब VPN अपने DNS सर्वर धकेलता है, तब वे नाम रिज़ॉल्व होना बंद कर देते हैं, भले ही उनके पते अब भी पहुँच में हों। नाम सीधे पूछें और जवाब की तुलना उस पते से करें जो आप जानते हैं कि डिवाइस के पास है।

Linux पर, resolvectl query nas.local दिखाता है कि किस रिज़ॉल्वर ने जवाब दिया। Windows पर, nslookup nas.local सर्वर का नाम बताता है, और ipconfig /all रिज़ॉल्वर का क्रम दिखाता है। अगर लोकल सफ़िक्स अब कॉर्पोरेट रिज़ॉल्वर संभालता है, तो उस सफ़िक्स को लोकल रिज़ॉल्वर पर वापस भेजें या डिवाइस के लिए IP पता इस्तेमाल करें।

खोज एक अलग परत है। mDNS और ब्रॉडकास्ट रूटेड टनल को पार नहीं करते, इसलिए डिवाइस पते से पहुँच में हो सकता है जबकि उसका नाम अदृश्य रहे। रिफ़्लेक्टर या लोकल DNS एंट्री इसे हल करती है; रूट नहीं।

चौथे, जाँचें कि क्या दूसरी मशीन भी VPN पर है

जब वह मशीन जिस तक आप पहुँचना चाहते हैं, खुद भी VPN क्लाइंट चलाती है, तब आपका सत्र पहुँच सकता है जबकि उसका जवाब दूसरी टनल से निकलता है। इससे ऐसा कनेक्शन बनता है जो स्थापित होकर अटक जाता है, या RDP और SSH का प्रयास आपकी ओर बिना किसी त्रुटि के समय पूरा कर देता है। अपने क्लाइंट को दोष देने से पहले दूसरे होस्ट की रूट तालिका और उसका डिफ़ॉल्ट रास्ता जाँचें।

सेवा जिस पते पर सुनती है वह भी जाँचें। सिर्फ़ टनल पते से बँधा लिसनर VPN से कनेक्शन स्वीकार करता है और लोकल नेटवर्क से उन्हें अस्वीकार करता है, तब भी जब रूटिंग बेहतरीन हो। यह सेवा कॉन्फ़िगरेशन है, नेटवर्क रास्ता नहीं, और VPN पते पर ताला लगे मैनेजमेंट इंटरफ़ेस पर यह आम है।

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

जो जाँच विफल हुई उससे मेल खाता सुधार लागू करें

अगर रूट तालिका ने आधा-डिफ़ॉल्ट कब्ज़ा दिखाया, तो नीति अनुमति दे तो स्प्लिट टनल और न दे तो पिन किया लोकल रूट चुनें। अगर पता सार्वजनिक निकला, तो परीक्षण और नाम को निजी पते पर बदलें। अगर रिज़ॉल्वर हाथ बदल गया, तो लोकल सफ़िक्स सीमित करें या पता इस्तेमाल करें। अगर दूसरा होस्ट टनल में है, तो उसका वापसी रास्ता या लिसनर बाइंडिंग ठीक करें।

एक चीज़ बदलें, फिर वही जाँच दोहराएँ। गलत सबनेट के लिए जोड़ा गया रूट, वर्तनी की गलती वाला रिज़ॉल्वर सफ़िक्स और फिर से नंबर लेने वाले इंटरफ़ेस पर पिन किया रूट—सब मूल खराबी जैसे दिखते हैं। दोहराव ही सुधार को संयोग से अलग करता है।

VPN जुड़ा होने पर जो रूट, पता और रिज़ॉल्वर काम करते थे, उन्हें लिख लें। अगला पुनःकनेक्शन उनमें से कम से कम एक बदलेगा, और यह नोट अगली गड़बड़ी को नई जाँच के बजाय छोटी तुलना बना देगा।