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 जो इंटरफ़ेस और स्रोत पता लौटाता है, नोट करें। किसी भी नीति बदलाव के बाद फिर कनेक्ट करें और वही चार जाँचें दोहराएँ; पुनः कनेक्शन के बाद की रूट टेबल ही एकमात्र सबूत है कि नई प्रोफ़ाइल प्रभावी हुई।
फिर रूटिंग को प्रवर्तन से अलग करें। फ़ोर्स टनलिंग कवर किए गए ट्रैफ़िक के लिए टनल के चालू रहने तक उसे प्राथमिकता देती है। यह किल स्विच नहीं है। अगर आवश्यकता यह है कि टनल गिरने पर मशीन से कुछ बाहर न जाए, तो वह अवरोधक डिज़ाइन से आना चाहिए: टनल स्थिति से बंधी फ़ायरवॉल प्रोफ़ाइल, ट्रैफ़िक फ़िल्टर वाली हमेशा-चालू प्रोफ़ाइल, या विक्रेता क्लाइंट का अपना फ़ेल-क्लोज़्ड विकल्प। फ़ोर्स टनलिंग को VPN सर्वर का अपना पता भी टनल के बाहर पहुँच योग्य रखना होता है, और «सब कुछ थोपने» के नाम पर उसे अवरुद्ध करना उस कनेक्शन से खुद को बाहर करने का भरोसेमंद तरीका है जिसे आप लागू करना चाहते हैं।
कुछ भी बदलने से पहले इस सूची से गुज़रें। जो भी मद विफल होती है, वह सिकोड़ती है कि असली समस्या कहाँ है।
- प्रोफ़ाइल नाम और दायरा पुष्ट, मशीन-व्यापी प्रोफ़ाइल के लिए
-AllUserConnectionउपयोग किया गया। SplitTunnelingपढ़ा गया और कवरेज का प्रमाण नहीं, कॉन्फ़िगरेशन माना गया।- टनल अडैप्टर के रूट IPv4 और IPv6 के लिए अलग-अलग सूचीबद्ध।
- एक सार्वजनिक, एक आंतरिक और एक अपवाद गंतव्य के लिए
Find-NetRouteचलाया गया। - नाम विफलता के लिए रूट को दोष देने से पहले NRPT नियम जाँचे गए।
- अवरोध आवश्यकता फिर पढ़ी गई: पसंदीदा रूटिंग लागू अवरोध के समान नहीं है।
पूरी या स्प्लिट टनल का निर्णय प्रोफ़ाइल के मालिक का है, और Microsoft के रूटिंग नोट्स वह व्यवहार बताते हैं जो Windows लागू करता है जब कोई प्रोफ़ाइल उसे सेट करती है। Microsoft: फ़ोर्स और स्प्लिट टनलिंग वह संदर्भ है जिसे आउटपुट पढ़ते समय मैं खुला रखता हूँ।