Windows मा VPN ले वास्तवमा के रुट गर्छ भनेर PowerShell मा कसरी जाँच्ने
जडान भएको VPN टाइलले कभरेज प्रमाणित गर्दैन। सुरक्षित प्रोफाइल फ्ल्याग, प्रत्यक्ष रुट तालिका र NRPT नियमहरू यही क्रममा पढ्नुहोस्।
मैले Windows 11 ल्यापटपमा VPN क्लाइन्ट जोडें, टाइल Connected भयो, एउटा आन्तरिक फाइल साझेदारी खुल्यो, र एउटा सार्वजनिक साइट अझै पनि कार्यालयको Wi-Fi बाट सिधै लोड भइरहेको थियो। यो मिश्रण टुटेको सुरुङजस्तो देखिन्छ। तर यो केही ट्राफिक VPN बाट पठाउने र बाँकी भौतिक एडाप्टरमा छोड्ने प्रोफाइलको सामान्य नतिजा हो। जबरजस्ती सुरुङले Windows ले कुन पूर्वनिर्धारित मार्गलाई प्राथमिकता दिन्छ भन्ने परिवर्तन गर्छ; यसले अझ विशिष्ट मार्गहरू मेटाउँदैन र जडान टुट्दा ट्राफिक रोकिन्छ भनेर वाचा पनि गर्दैन। तलको क्रम मैले ग्राहकले कभरेज दाबी गर्दा पछ्याउने क्रम हो: क्लाइन्ट स्थिति, सुरक्षित प्रोफाइल, लागू गरिएका मार्गहरू, रिजोल्भर, त्यसपछि वास्तविक प्रवाहहरू।
क्लाइन्टबाट सुरु गर्नुहोस्, त्यसपछि त्यसमाथि विश्वास गर्न छोड्नुहोस्
क्लाइन्ट सुरु गर्ने सही ठाउँ केवल यसकारण हो कि यसले कुन प्रोफाइल सक्रिय छ भन्छ। जडान गुणहरू खोल्नुहोस् र ठ्याक्कै प्रोफाइल नाम, त्यो हालको प्रयोगकर्ताका लागि बनेको हो कि मेसिनका सबैका लागि, र जडान गरेपछि ncpa.cpl मा कुन एडाप्टर देखिन्छ टिप्नुहोस्। मेरो परीक्षण ल्यापटपमा एडाप्टरले प्रोफाइलको नाम बोकेको थियो, जसले मार्गको आउटपुट पढ्न सजिलो बनायो। अन्य मेसिनमा यो WAN Miniport प्रविष्टिका रूपमा देखिन्छ र नामले तपाईंलाई केही भन्दैन।
क्लाइन्टले भन्न नसक्ने कुरा कभरेज हो। जडान भएको टाइलले सुरुङको स्थिति वर्णन गर्छ, गन्तव्यहरूको सूची होइन। तेस्रो-पक्ष क्लाइन्टहरूले पनि आफ्नै कन्फिगरेसन राख्छन्, त्यसैले मूल Windows प्रोफाइल र त्यसबाट तपाईंले पढ्ने प्रत्येक गुण ती क्लाइन्टले स्थापना गरेकोसँग सम्बन्धित नहुन सक्छ। यदि VPN AnyConnect, OpenVPN GUI, WireGuard वा विक्रेता एजेन्टमार्फत आएको हो भने तलका PowerShell जाँचहरू प्रायः लागू हुँदैनन् र त्यसको सट्टा ती क्लाइन्टका आफ्नै स्प्लिट-टनेल र रुटिङ सेटिङहरू पढ्नुपर्छ।
सुरक्षित प्रोफाइल पढ्नुहोस्, टाइल होइन
मूल Windows प्रोफाइलका लागि (IKEv2, L2TP, SSTP वा MDM ले धकेलेको) सुरक्षित स्प्लिट-टनेल निर्णय एउटै गुण हो:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixप्रोफाइल यन्त्रका सबैका लागि बनेको भए -AllUserConnection थप्नुहोस्। त्यो बिना तपाईं हालको प्रयोगकर्ताको सूची पढ्नुहुन्छ, जुन खाली हुन सक्छ वा मिल्दो नामको अर्को प्रविष्टि राख्न सक्छ। False मान SplitTunneling मा हुनुको अर्थ प्रोफाइल पूर्ण सुरुङका रूपमा सुरक्षित भयो: Windows ले VPN एडाप्टरमार्फत पूर्वनिर्धारित मार्ग स्थापना गर्छ। True भनेको स्प्लिट सुरुङ, र कभरेज त्यसपछि पूर्ण रूपमा त्यो प्रोफाइलले धकेल्ने मार्ग र नाम-समाधान नियमहरूमा निर्भर हुन्छ।
त्यो मानलाई कन्फिगरेसनका रूपमा लिनुहोस्, अवलोकनका रूपमा होइन। यसले जडानको समयमा प्रोफाइलले के माग्यो त्यो अभिलेख गर्छ। Windows अर्को इन्टरफेसको अझ विशिष्ट मार्ग, नीति सेटिङ वा अघिल्लो जडानको बाँकी प्रविष्टिका कारण फरक लागू गरिएका मार्गहरूसँग रहन सक्छ, त्यसैले बुलियनले प्रश्न एक्लै टुंग्याउँदैन।
सुरक्षित मानलाई लागू गरिएको रुट तालिकासँग तुलना गर्नुहोस्
जडान गरेपछि पूरै तालिका स्क्रोल गर्नुको सट्टा सुरुङ एडाप्टरका मार्गहरू सूचीबद्ध गर्नुहोस्:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute उपयोगी आधा हो। क्लाइन्टले कहिल्यै नजवाफ दिने प्रश्नको जवाफ यसले दिन्छ: यो गन्तव्यका लागि Windows ले वास्तवमा कुन इन्टरफेस र कुन स्रोत ठेगाना प्रयोग गर्छ? यसलाई आन्तरिक होस्ट, सार्वजनिक होस्ट र तपाईं जानाजानी अपवाद ठान्ने सबैका लागि चलाउनुहोस्। पूर्ण सुरुङ प्रोफाइलले सार्वजनिक ठेगानाका लागि सुरुङ इन्टरफेस देखाउनुपर्छ। स्प्लिट सुरुङ प्रोफाइलले त्यहाँ सामान्यतया भौतिक एडाप्टर देखाउँछ, जबकि आन्तरिक प्रिफिक्सहरू अझै VPN मा समाधान हुन्छन्।
«यो गलत दिशामा रुट गर्छ» भन्ने अधिकांश रिपोर्ट दुई पासोले व्याख्या गर्छन्। सबैभन्दा विशिष्ट प्रिफिक्स सधैं जित्छ, त्यसैले भौतिक एडाप्टरको /24 ले सुरुङको मेट्रिक जतिसुकै कम भए पनि VPN को पूर्वनिर्धारित मार्गलाई हराउँछ। मेट्रिकले एउटै प्रिफिक्सका मार्गहरूबीचको बराबरी मात्र टुंग्याउँछ। र IPv4 र IPv6 छुट्टाछुट्टै निर्णय हुन्छन्: 0.0.0.0/0 समेट्ने प्रोफाइलले IPv6 लाई स्थानीय लिङ्कमा छोड्न सक्छ, जसले दोहोरो-स्ट्याक साइटलाई आधा सुरुङ भएको देखाउँछ। सुरुङ ठीक छ भन्ने निष्कर्षमा पुग्नुअघि Get-NetRoute -AddressFamily IPv6 जाँच्नुहोस्।
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
NRPT सँग नाम समाधान छुट्टै जाँच्नुहोस्
आन्तरिक नामहरू असफल हुँदा आन्तरिक IP ठेगानाहरू काम गर्छन् भने त्यो रुटिङतर्फ होइन, रिजोल्भर नीतितर्फ संकेत गर्छ। Windows ले प्रत्येक नामस्थानका लागि DNS नाम-समाधान नीति तालिकामार्फत निर्णय गर्छ, जुन रुट तालिकाबाट स्वतन्त्र छ:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexजब कुनै नियम *.corp.example सँग मिल्छ, त्यो नामस्थानका क्वेरीहरू सुरुङका DNS सर्भरहरूमा जान्छन्, स्प्लिट सुरुङ मोडमा ती सर्भरसम्मको डेटा मार्ग भौतिक एडाप्टरमा रहे पनि। यही नै डिजाइन हो, र त्यसैले सार्वजनिक साइट खोल्ने ब्राउजर परीक्षणले आन्तरिक नामहरूबारे केही भन्दैन। यदि एडाप्टरले अपेक्षित सर्भरहरू सूचीबद्ध गर्छ तर खोज अझै अन्तै जान्छ भने NRPT नियमहरूको क्रम तुलना गर्नुहोस् र अझ विशिष्ट नामस्थान पहिले मिल्छ कि भनेर जाँच्नुहोस्।
प्रवाहहरू प्रमाणित गर्नुहोस्, त्यसपछि तपाईंले वास्तवमा के माग्नुभयो त्यो निर्णय गर्नुहोस्
नतिजाहरू मेसिनहरूबीच तुलनीय होऊन् भनेर गन्तव्यहरू निश्चित क्रममा हेर्नुहोस्: सार्वजनिक ठेगाना, आन्तरिक ठेगाना, आन्तरिक नाम र स्थानीय प्रिन्टर वा भिडियो कलजस्तो एउटा जानाजानी अपवाद। प्रत्येकका लागि Find-NetRoute ले फर्काउने इन्टरफेस र स्रोत ठेगाना टिप्नुहोस्। कुनै पनि नीति परिवर्तनपछि फेरि जडान गर्नुहोस् र ती चारै जाँच दोहोर्याउनुहोस्; पुनःजडानपछिको रुट तालिका नै नयाँ प्रोफाइल लागू भएको एकमात्र प्रमाण हो।
त्यसपछि रुटिङलाई प्रवर्तनबाट अलग गर्नुहोस्। जबरजस्ती सुरुङले सुरुङ उठेको बेला समेटिएको ट्राफिकका लागि सुरुङलाई प्राथमिकता दिन्छ। यो kill switch होइन। यदि सुरुङ खस्दा मेसिनबाट केही पनि नजाओस् भन्ने आवश्यकता हो भने त्यो अवरोधक डिजाइनबाट आउनुपर्छ: सुरुङको स्थितिसँग बाँधिएको firewall प्रोफाइल, ट्राफिक फिल्टरसहितको सधैं-चालु प्रोफाइल वा विक्रेता क्लाइन्टको आफ्नै असफलतामा बन्द हुने विकल्प। जबरजस्ती सुरुङले VPN सर्भरको आफ्नै ठेगाना पनि सुरुङबाहिर पुग्नयोग्य राख्नुपर्छ, र «सबै जबरजस्ती गर्ने» का नाममा त्यसलाई अवरुद्ध गर्नु भनेको तपाईं लागू गर्न खोजिरहनुभएको जडानबाट आफैंलाई बाहिर ताल्चा लगाउने भरपर्दो उपाय हो।
केही परिवर्तन गर्नुअघि यो सूची हेर्नुहोस्। असफल हुने प्रत्येक वस्तुले वास्तविक समस्या कहाँ छ भन्ने साँघुरो गर्छ।
- प्रोफाइल नाम र दायरा पुष्टि भयो, मेसिन-व्यापी प्रोफाइलका लागि
-AllUserConnectionप्रयोग गरियो। SplitTunnelingपढियो र कभरेजको प्रमाण होइन, कन्फिगरेसनका रूपमा लिइयो।- सुरुङ एडाप्टरका मार्गहरू IPv4 र IPv6 का लागि छुट्टाछुट्टै सूचीबद्ध गरियो।
- एक सार्वजनिक, एक आन्तरिक र एक अपवाद गन्तव्यका लागि
Find-NetRouteचलाइयो। - नाम असफलताका लागि मार्गहरूलाई दोष दिनुअघि NRPT नियमहरू जाँचियो।
- अवरोध आवश्यकता फेरि पढियो: प्राथमिकता रुटिङ भनेको लागू गरिएको अवरोध होइन।
पूर्ण वा स्प्लिट सुरुङको निर्णय प्रोफाइलको मालिकको हो, र Microsoft का रुटिङ नोटहरूले प्रोफाइलले सेट गर्दा Windows ले कार्यान्वयन गर्ने व्यवहार वर्णन गर्छन्। Microsoft: जबरजस्ती र स्प्लिट सुरुङ आउटपुट पढ्दा मैले खुला राख्ने सन्दर्भ हो।