VPN जोडिएको बेला स्थानीय नेटवर्क पुग्न नसकिने? चार जाँच

टनेल उठ्छ, इन्ट्रानेट देखिन्छ, तर प्रिन्टरले जवाफ दिन छोड्छ। LAN मा केही बिग्रिएको छैन; क्लाइन्टले अब स्थानीय नमान्ने ठेगानाहरूका लागि कुन बाटो प्रयोग गर्ने भन्ने बदलेको छ। तलका चार जाँच क्रमैसँग गर्नुहोस् र कुनै एउटाले ठोस बेमेल देखाएपछि रोक्नुहोस्, किनकि एउटै लक्षणका चार सामान्य कारण हुन्छन् र तीमध्ये एउटा मात्र 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 होइन, यन्त्र, स्विच वा क्लाइन्टको फायरवाल हेर्नुहोस्।

मानिसलाई भ्रममा पार्ने अवस्था स्थानीय सर्भरका लागि सार्वजनिक ठेगाना हुनु हो। LAN भित्रबाट राउटरको 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 बाट आउने जडान स्वीकार्छ र LAN बाट आउने अस्वीकार्छ, रुटिङ उत्तम भए पनि। त्यो सेवाको कन्फिगरेसन हो, नेटवर्क बाटो होइन, र VPN ठेगानामा थुनिएका व्यवस्थापन इन्टरफेसमा यो सामान्य छ।

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

असफल भएको जाँचसँग मिल्ने उपचार लागू गर्नुहोस्

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

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

VPN जोडिएको बेला चलेको रुट, ठेगाना र रिजोल्भर लेखेर राख्नुहोस्। अर्को पुनःजडानले तीमध्ये कम्तीमा एउटा बदल्नेछ, र त्यो टिप्पणीले अर्को अवरोधलाई नयाँ अनुसन्धानको सट्टा छोटो तुलना बनाउनेछ।