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: सक्तीचे आणि स्प्लिट बोगदे हा आउटपुट वाचताना मी उघडा ठेवतो तो संदर्भ आहे.