Windows च्या सार्वजनिक फायरवॉल प्रोफाइलमुळे VPN क्लायंट अडवले जातात

तुमचा टनेल सुरू आहे, गेटवे ping ला उत्तर देतो, आणि फाइल शेअरिंग तरीही टाइमआउट होते। हे संयोजन क्वचितच राउटिंगची समस्या असते: Windows ने VPN अडॅप्टरचे सबनेट सार्वजनिक प्रोफाइलमध्ये ठेवले आहे, आणि खाजगी किंवा डोमेनसाठी लिहिलेला प्रत्येक परवानगी नियम कधीही लागू झाला नाही। मी हे अशा लॅपटॉपवर पाहिले आहे जे कार्यालयात व्यवस्थित पोहोचतात आणि अशा RRAS सर्व्हरवरही जे बाकीच्या सर्व क्लायंटची सेवा करतात, आणि संबंधित प्रोफाइलचे नाव घेताच दुरुस्ती लहान होते। हा माझा कामाचा क्रम आहे, शिवाय ती तपासणी जी सांगते की पुढच्या पायरीपूर्वी कधी थांबायचे।

ट्रॅफिक प्रत्यक्षात कोणत्या प्रोफाइलवर येते ते शोधा

Windows फायरवॉलला एकही जागतिक मोड नाही। प्रत्येक जोडलेला इंटरफेस एक श्रेणी धारण करतो, आणि इनबाउंड पॅकेट ज्या इंटरफेसवर येतात त्याच्या श्रेणीनुसार फिल्टर होतात, त्यामुळे टनेलमधील क्लायंट कशापर्यंत पोहोचू शकतो हे VPN अडॅप्टरचे प्रोफाइल ठरवते, शेजारचे Wi-Fi किंवा इथरनेट अडॅप्टर नाही। काहीही बदलण्यापूर्वी दोन्ही तथ्ये वाचा:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

नेहमीच्या OpenVPN किंवा WireGuard इंस्टॉलेशनमध्ये VPN अडॅप्टर अनोळखी नेटवर्क म्हणून दिसतो आणि सार्वजनिक प्रोफाइलमध्ये जातो, जे Windows वर्गीकृत करू शकत नाही अशा प्रत्येक नेटवर्कसाठी डीफॉल्ट आहे: त्यावर कोणत्याही डोमेन कंट्रोलरने उत्तर दिले नाही आणि कोणतेही गेटवे प्रोफाइल जुळले नाही। इंटरफेसचे नाव इथे महत्त्वाचे नाही, त्यामुळे अडॅप्टरला "VPN" किंवा "Corp" म्हणण्याने काहीही बदलत नाही। DomainAuthenticated साठी डोमेनशी जोडलेले मशीन आवश्यक आहे , जे त्या इंटरफेसवरून खरोखर डोमेन कंट्रोलरपर्यंत पोहोचू शकेल; फक्त एक सबनेट वाहून नेणारा स्प्लिट टनेल ही अट पूर्ण करणार नाही।

तुम्हाला हवा असलेला नियम आधीच VPN पूलपर्यंत मर्यादित असेल आणि तुम्ही नुकत्याच वाचलेल्या श्रेणीवर आधीच लागू असेल, तर इथेच थांबा: फिल्टरिंग तुमचा स्तर नाही, आणि पाहण्याची पुढची जागा सेवा कॉन्फिगरेशन आहे। ही तपासणी दहा सेकंद घेते आणि एका तासाचे नियम संपादन वाचवते। श्रेणींची नावे आणि प्रत्येक काय व्यापते ते Get-NetConnectionProfile संदर्भ मध्ये नोंदवलेले आहे।

नियम संपादित करण्यापूर्वी हे फिल्टरिंग आहे, राउटिंग नाही याची खात्री करा

Ping ही कमकुवत चाचणी आहे। सेवा पोर्ट सोडला जात असताना ICMP जाऊ शकतो, आणि होस्ट LAN मधून उत्तर देऊ शकतो पण तीच विनंती टनेलमधून नाकारू शकतो। क्लायंटला आवश्यक असलेला पोर्ट क्लायंटकडून तपासा:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

पोर्ट चाचणी अयशस्वी झाल्यास दोन स्तर वेगळे करा। टनेल किंवा मार्गाची बिघाड सहसा गेटवे पत्त्यावरून कोणतेही उत्तर न येणे अशी दिसते, तर फायरवॉलकडून नाकारणे उत्तर देणारा गेटवे आणि उत्तर न देणारा सेवा पोर्ट दर्शवते। RRAS द्वारे पूल प्रकाशित करणाऱ्या Windows सर्व्हरवर तीच चाचणी क्लायंटकडून चालवा आणि सर्व्हरचे स्वतःचे प्रोफाइल वाचा: RAS इंटरफेस अशा श्रेणीत असू शकतो ज्याचे इनबाउंड नियम क्लायंट श्रेणीचा कधीही उल्लेख करत नाहीत, आणि म्हणूनच ते मशीन स्वतःच्या LAN ला सेवा देते आणि टनेलमधील प्रत्येक क्लायंटला नाकारते।

निकाल अजूनही अस्पष्ट असल्यास संबंधित प्रोफाइलचे ड्रॉप नोंदवा आणि ते वाचा:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

क्लायंटचा पत्ता आणि पोर्ट DROP सह नमूद करणाऱ्या नोंदी निर्णायक आहेत, आणि कोणता नियम गहाळ होता तेही सांगतात। काहीही नसलेला लॉग, क्लायंटचा SYN कधीही न दिसल्यास, होस्टच्या वरच्या बाजूस निर्देश करतो, म्हणून दुसऱ्या फायरवॉल ऑब्जेक्टला स्पर्श करण्यापूर्वी टनेल, NAT नियम किंवा पूल मार्गाकडे परत जा।

एक इनबाउंड नियम क्लायंट पूलपर्यंत मर्यादित करा

दुरुस्ती म्हणजे दूरचा पत्ता जग नसून पूल असलेला एकच इनबाउंड परवानगी नियम। उन्नत सत्रातून:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

सेवा एकच बायनरी फाइल असल्यास पोर्ट यादीऐवजी -Program पॅरामीटरसह प्रोग्राम-मर्यादित नियमाला प्राधान्य द्या; यामुळे अपवाद प्रक्रिया आणि स्रोत श्रेणी दोन्हींपर्यंत मर्यादित राहतो।

प्रोफाइलची निवड हीच जागा आहे जिथे तीच चूक उलट दिशेने होते। -Profile Public अडॅप्टर सार्वजनिक असेल आणि सार्वजनिकच राहिले तर पुरेसे आहे। -Profile Any Windows अडॅप्टरचे वर्गीकरण कसेही करो, सेवेला काम करावे लागत असेल तेव्हा न्याय्य आहे, पण दूरचा व्याप्ती टिकेपर्यंतच। जे कधीही न्याय्य नाही ते -RemoteAddress Any सार्वजनिक प्रोफाइलवर: तो नियम लॅपटॉपसोबत तो जोडला जाणाऱ्या प्रत्येक कॅफे आणि हॉटेल नेटवर्कमध्ये जातो आणि ते सबनेट सामायिक करणाऱ्या प्रत्येकासाठी पोर्ट उघडतो।

पूल नियमाच्या शेजारी नोंदवा। -RemoteAddress 10.8.0.0/24 VPN पूल पुनर्क्रमांकित होणाऱ्या दिवशी शांतपणे जुळणे थांबवते, आणि बिघाड मूळ बगसारखाच दिसतो, म्हणूनच तो दुसरा दुपार खातो। नियमांना सेवा आणि स्रोत श्रेणीचे नाव द्या, ते -Group सोबत ठेवा, आणि पूलची व्याख्या बदलल्यावर त्यांना पुन्हा वाचा। एका स्क्रीनवर तपासता येणारी नियम यादी कोणालाही न सापडणाऱ्या बरोबर नियमापेक्षा चांगली आहे।

श्रेणी स्वतःच निर्णय असेल तेव्हाच श्रेणी बदला

इंटरफेस खाजगीत बदलणेही काम करते, आणि ते चुकीचे डीफॉल्ट आहे। खाजगी प्रोफाइलमध्ये अनेक अंगभूत परवानगी नियम असतात, जे फाइल आणि प्रिंटर सामायिकरण, नेटवर्क शोध, रिमोट डेस्कटॉप आणि आधाररेषेनुसार अधिक व्यापतात, त्यामुळे VPN अडॅप्टरचे पुनर्वर्गीकरण केल्यास ते सर्व टनेलमधील प्रत्येक क्लायंटसाठी एकत्र सक्रिय होतात। एक मर्यादित नियम एक सेवा एका श्रेणीला देतो। अविश्वासू नेटवर्कमध्येही जोडणाऱ्या लॅपटॉपवर हा फरक वरवरचा नाही।

असे प्रसंग आहेत जिथे वर्गीकरण खरोखर चुकीचे आहे: कार्यालयीन सबनेट वाहून नेणारा नेहमी-सुरू किंवा साइट-टू-साइट टनेल विश्वासार्ह पायाभूत सुविधा आहे, आणि त्या अडॅप्टरला खाजगी म्हणून चिन्हांकित करणे हे एकदा धोरणाने घेतलेला कायदेशीर रचना निर्णय आहे, प्रत्येक तिकिटावर नाही। जेव्हा कराल, स्पष्टपणे करा:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

व्यवस्थापित उपकरणावर आधी तपासा की सेटिंग ग्रुप पॉलिसीच्या किंवा MDM आधाररेषेच्या मालकीची आहे का। असेल तर स्थानिक बदल पुढील रिफ्रेशवर मागे घेतला जातो, आणि gpresult /h तिच्याकडे असलेल्या धोरणाचे नाव सांगेल; तिथेच दुरुस्त करा, एंडपॉइंटवर नाही।

दोन्ही टोकांकडून सत्यापित करा आणि खूण सोडा

बदलानंतर वापरकर्त्याने नोंदवलेला प्रवाह क्लायंटकडून सत्यापित करा:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

मग पुढच्या आठवड्यात तुटणाऱ्या गोष्टींवर चक्र बंद करा। होस्ट पुन्हा सुरू करा आणि पुन्हा चाचणी करा, कारण चुकीच्या प्रोफाइलपर्यंत मर्यादित नियम अडॅप्टर दुसऱ्या श्रेणीत परत येईपर्यंत काम करत राहतो। दुसऱ्या क्लायंटकडून चाचणी करा, कारण जुन्या लीजचा एक क्लायंट पूलची विसंगती लपवू शकतो। जोडलेल्या नियमांची वजा केलेल्या नियमांशी तुलना करा, कारण आच्छादित अपवाद हाच तो मार्ग आहे ज्यामुळे दोन ओळींची दुरुस्ती अशा फिल्टरिंग धोरणात बदलते ज्याचे कोणीही पुनरावलोकन करू शकत नाही।

हे पूर्ण म्हणण्यापूर्वी:

• नियमात नमूद केलेले प्रोफाइल म्हणजे ट्रॅफिक येते त्या इंटरफेसचे प्रोफाइल।
• दूरचा व्याप्ती VPN पूल आहे, आणि तो पूल सर्व्हर प्रत्यक्षात देत असलेल्याशी जुळतो।
• तुम्ही जोडलेल्या कोणत्याही नियमात -RemoteAddress Any सार्वजनिक प्रोफाइलवर वापरले जात नाही।
• चाचणी उत्तीर्ण करण्यासाठी काहीही बंद केलेले नाही, आणि प्रत्येक श्रेणी बदल कोणी मंजूर केला हे नोंदवतो।