के Windows VPN एडाप्टर निजी वा सार्वजनिक हुनुपर्छ?
तीन परीक्षणबाट निर्णय गर्नुहोस् कि Windows VPN एडाप्टर निजी प्रोफाइलमा पर्छ कि पर्दैन: विश्वसनीय मार्ग, स्थिर वर्गीकरण र तपाईंलाई साँच्चै आवश्यक नियमहरू.
Windows VPN एडाप्टरलाई निजीमा राख्नु कर्पोरेट टनेलका लागि सही र व्यावसायिक VPN क्लाइन्टका लागि गलत हो, र यो भिन्नता देखावटी मात्र होइन। नेटवर्क वर्गले फायरवाल प्रोफाइल छान्छ, त्यसैले एउटा परिवर्तनले एकैचोटि पूरै नियमसमूहलाई अनुमति दिन्छ। लगइन स्क्रिप्टले हरेक अज्ञात एडाप्टरलाई निजी बनाएको मैले देखेको छु, जसले होटेलको वायरलेस नेटवर्कमा फाइल साझेदारी चुपचाप खुला गरिदियो। उत्तर तीन सर्तले निर्धारण गर्छन्, र सेटिङ छुनुअघि सबै सत्य हुनुपर्छ।
वर्गले वास्तवमा के निर्धारण गर्छ
Network Location Awareness ले हरेक जोडिएको नेटवर्कका लागि एडाप्टरले रिपोर्ट गर्न सक्ने कुराबाट हस्ताक्षर बनाउँछ: गेटवे ठेगाना र MAC, DNS प्रत्यय, डोमेन कन्ट्रोलरले जवाफ दिन्छ कि दिँदैन, र नेटवर्क इन्टरनेटसम्म पुग्छ कि पुग्दैन। Windows ले त्यो हस्ताक्षरमा प्रोफाइल जोड्छ, अनि फायरवालले त्यो प्रोफाइलको नियमसमूह लागू गर्छ। पहिचान असफल हुँदा सार्वजनिक विकल्प हुन्छ, त्यसैले काम गरिरहेको टनेल पनि अज्ञात नेटवर्क का रूपमा लेबल रहन सक्छ।
TUN वा TAP एडाप्टरले सामान्यतया पहिचानलाई धेरै थोरै जानकारी दिन्छ। टनेलको साथी प्रायः गेटवे नभई एउटै ठेगाना हुन्छ, DNS टनेलभित्र मात्र पठाइन सक्छ, र एडाप्टरसँग आफ्नै पूर्वनिर्धारित मार्ग हुँदैन। परिणामस्वरूप आउने लेबलले फायरवालको इनपुट वर्णन गर्छ, टनेलको स्वास्थ्य होइन, र त्यसैले VPN जोडिने क्षणमा निजी प्रोफाइलका नियम मिल्न छाड्छन्।
पहिलो सर्त: टनेल नै विश्वसनीय मार्ग हो
निजी छान्नु भनेको यो इन्टरफेसबाट पुग्न सकिने सबै कुरा कम्तीमा तपाईंको आफ्नै LAN जत्तिकै विश्वसनीय छ भन्नु हो, किनकि खोज र आगमन नियमहरूले त्यो सबनेटलाई स्थानीय मान्नेछन्। फाइल सर्भर र प्रिन्टर भएको व्यवस्थित सबनेटमा कर्पोरेट टनेलका लागि यो दाबी सामान्यतया सही हुन्छ। एडाप्टर तपाईंको संस्थाले नियन्त्रण गर्ने नेटवर्कको ढोका हो, र अर्को छेउको मेसिन तपाईंको मेसिनलाई स्वीकार गर्ने त्यही नीतिले स्वीकार गरिएको हो।
व्यावसायिक VPN निकास यो परीक्षामा उत्तीर्ण हुँदैन। अन्य ग्राहकहरूले निकास सबनेट साझा गर्छन्, र त्यसलाई निजी भनी चिन्ह लगाउँदा नेटवर्क खोज, LLMNR र NetBIOS नाम समाधान अपरिचितहरूले भरिएको खण्डमा पुग्छ। विभाजित टनेल पनि असफल हुन सक्छ: जब एडाप्टरले एउटा अनुप्रयोगका लागि एउटै होस्ट मार्ग बोक्छ, त्यहाँ कुनै विश्वसनीय सबनेट हुँदैन, र वर्ग परिवर्तनले तपाईंलाई केही दिँदैन।
दोस्रो सर्त: वर्गीकरण पुनः जडानमा टिक्छ
नयाँ गेटवे वा DNS प्रत्ययले नयाँ हस्ताक्षर बनाउँछ, र Windows ले त्यसका लागि नयाँ प्रोफाइल निर्णय गर्छ। त्यसैले एकपटकको Set-NetConnectionProfile अर्को पुनः जडानसम्म टिक्छ, सधैं होइन। प्रोफाइल पहिलो जडानपछि होइन, पुनः जडानपछि जाँच्नुहोस्, किनकि त्यही बेला सेटिङ आफैं फर्कन्छ।
यसलाई स्थायी बनाउने तीन तरिका छन्। सबैभन्दा सफा नीति हो: secpol.msc खोल्नुहोस्, Network List Manager Policies मा जानुहोस् र नेटवर्कका लागि स्थान प्रकार सेट गर्नुहोस्, अज्ञात नेटवर्क नीतिसमेत, ताकि प्रोफाइल आदेशले होइन नीतिले लागू होस्। दोस्रो तरिका प्रत्येक जडानको स्क्रिप्ट वा टनेल उठेपछि PowerShell cmdlet चलाउने तालिकाबद्ध कार्य हो। तेस्रो तरिका पुरानो मार्ग युक्ति हो, जसले पहिचानलाई जाँच्न गेटवे दिन्छ:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfile
मार्ग युक्ति एउटा उपाय हो, वर्गीकरण होइन। मेट्रिकको सम्बन्ध बदलिँदा वा VPN क्लाइन्टले पुनः जडानमा मार्गहरू पुनः लेख्दा यो भाँचिन्छ, र दोस्रो पूर्वनिर्धारित मार्गमा पर्ने हरेक कुराको मार्ग चयन चुपचाप बदल्छ।
तेस्रो सर्त: तपाईंलाई निजी नियमसमूह चाहिन्छ
निजीमा सामान्यतया फाइल र प्रिन्टर साझेदारी, नेटवर्क खोज र टाढाको प्रशासनका समूहहरू पर्छन्। यदि काम टनेलबाट SMB साझेदारी वा प्रिन्टरसम्म पुग्नु हो भने, वर्ग बदल्ने वास्तविक कारण त्यही हो। यदि काम एउटा वेब अनुप्रयोगमा बाहिर जाने पहुँच हो भने, वर्ग अप्रासंगिक छ: बाहिर जाने नियम लेख्नुहोस्, सार्वजनिक राख्नुहोस् र त्यहीँ रोकिनुहोस्।
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
तालिकालाई सुरुवाती बिन्दुका रूपमा पढ्नुहोस्, अनि तपाईंको इमेजमा कुन निजी नियमहरू साँच्चै सक्षम छन् जाँच्नुहोस्। कठोर बनाइएको इमेजले निजी प्रोफाइलबाट फाइल साझेदारी पूरै हटाएको हुन सक्छ, र त्यस अवस्थामा नियम फर्काएर नराखेसम्म वर्ग परिवर्तनले केही पनि हासिल गर्दैन। त्यो जाँचमा एउटा आदेश लाग्छ र लामो दिउँसो बच्छ।
बाँकी सबै नबढाई परिवर्तन गर्ने
वाइल्डकार्ड होइन, इन्टरफेस इन्डेक्स लक्षित गर्नुहोस्, र सूची अघि र पछि पढ्नुहोस्:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfile
भण्डारण गरिएका प्रोफाइल रजिस्ट्रीको NetworkList कुञ्जीमुनि बस्छन्, जहाँ Category मानले सार्वजनिक, निजी र डोमेन नेटवर्क छुट्याउँछ। यसलाई सम्पादन गर्न सम्भव छ र गल्ती गर्न सजिलो: एडाप्टरको हालको हस्ताक्षरसँग मिल्ने प्रविष्टि बदल्नुपर्छ, अघिल्लो ठेगानाले छोडेको पुरानो प्रविष्टि होइन। पुरानो प्रविष्टि सम्पादकमा सही देखिन्छ र पुनः जडानमा केही गर्दैन।
जे गरे पनि, हरेक अज्ञात एडाप्टरलाई निजी बनाउने स्क्रिप्ट जारी नगर्नुहोस्। त्यो असुरक्षित वायरलेसमा खोज खोल्ने एक-हरफे संस्करण हो। यदि साझेदारी टनेलको सबनेटसँग मात्र चाहिन्छ भने, प्रोफाइल सार्वजनिक राख्नुहोस् र टनेलको टाढाको ठेगाना दायरासम्म सीमित आगमन नियम थप्नुहोस्; फायरवाल नियम वर्गभन्दा साँघुरो हुन्छ।
लेबल होइन, साझेदारी जाँच्नुहोस्
परिवर्तनपछि लेबलमा भरोसा गर्नुको सट्टा स्रोत आफैं परीक्षण गर्नुहोस्:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.example
एडाप्टरले निजी देखाइरहे पनि साझेदारी असफल भइरहेको छ भने, वर्ग अब तपाईंको समस्या होइन। नाम समाधान, छुटेको मार्ग वा साझेदारी अनुमतिले त्यही लक्षण उत्पन्न गर्नेछन्, र प्रोफाइल फेरि बदल्नुले तीमध्ये एउटै पनि सुधार्न सक्दैन। एकपटक पुनः जोडिनुहोस् र सेटिङ टिकेको पुष्टि गर्न Get-NetConnectionProfile फेरि चलाउनुहोस्, त्यसपछि बाँकी असफलतालाई सामान्य SMB समस्याका रूपमा समाधान गर्नुहोस्।
जाँचसूची: टनेल व्यवस्थित मार्ग हो, प्रोफाइल पुनः जडानमा टिक्छ, आवश्यक निजी नियमहरू इमेजमा छन्, र साझेदारी समाधान भई पोर्ट 445 मा जवाफ दिन्छ भनी पुष्टि गर्नुहोस्। पहिलो तीनमध्ये कुनै पनि गलत भएमा एडाप्टर सार्वजनिक राख्नुहोस् र सीमित नियमले पहुँच समस्या समाधान गर्नुहोस्।