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 शेअर किंवा प्रिंटरपर्यंत पोहोचण्याचे असेल, तर श्रेणी बदलण्याचे तेच खरे कारण आहे. जर काम एका वेब अनुप्रयोगासाठी बाहेर जाणारा प्रवेश असेल, तर श्रेणी अप्रस्तुत आहे: बाहेर जाणारा नियम लिहा, सार्वजनिक ठेवा आणि तिथेच थांबा.

ScenarioCategoryWhy
Corporate tunnel to a file server or printerPrivatePrivate rules carry the sharing you need
Commercial VPN for privacyPublicThe exit subnet is shared with strangers
Split tunnel with a single host routePublicNo trusted subnet and an unstable signature
Site-to-site tunnel to a branch LANPrivateThe far subnet is managed like the local one
Lab adapter you control end to endPrivateDiscovery 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 वर उत्तर देते याची खात्री करा. पहिल्या तीनपैकी कोणतेही चूक असल्यास ॲडॉप्टर सार्वजनिक ठेवा आणि मर्यादित नियमाने प्रवेश समस्या सोडवा.

संबंधित लेख