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