SMB फायरवॉल नियमातील LocalSubnet VPN क्लायंटना व्यापणार नाही
LocalSubnet परवानगी नियम सर्व्हरच्या स्वतःच्या सबनेटवर लागू होतो, मार्गस्थ केलेल्या VPN पूलवर नाही। व्याप्ती वाढवण्यापूर्वी सर्व्हर पाहतो त्या स्रोत पत्त्याची तुलना करा।
ऑफिसचे डेस्कटॉप शेअरपर्यंत पोहोचतात, VPN वापरकर्त्यांची वेळ संपते, आणि तेच खाते मोबाइल हॉटस्पॉटवरून चालते। शेअर परवानग्या क्वचितच फरक असतात; फाइल सर्व्हरपर्यंत पोहोचणारा पत्ता सामान्यतः फरक असतो। LocalSubnet पर्यंत मर्यादित नियम सर्व्हरच्या स्वतःच्या जोडलेल्या सबनेटना प्रवेश देतो, आणि स्वतंत्रपणे मार्गस्थ केलेला VPN पूल त्यापैकी एक नाही। दोन रचना ही तफावत भरतात, आणि त्या खूप वेगळ्या नोंदी मागे ठेवतात।
दोन रचना, एक लक्षण
पहिली रचना नियमाच्या दूरस्थ पत्ता अटीमध्ये VPN पूल जोडते। मग सर्व्हर प्रत्येक क्लायंटचा टनेल पत्ता पाहतो, त्यामुळे त्याचे लॉग एक दूरस्थ वापरकर्ता दुसऱ्यापासून वेगळा करू शकतात। दुसरी रचना VPN रहदारी सर्व्हर पाहण्यापूर्वी LAN पत्त्यात भाषांतरित करणाऱ्या गेटवेमधून मार्गस्थ करते। त्यामुळे कनेक्टिव्हिटी पुन्हा मिळते आणि त्याच टप्प्यात फरक नाहीसा होतो।
तक्ता पत्त्यांऐवजी भूमिका वर्णन करतो, आणि कोणती ओळ लागू होते हे तुमचे स्वतःचे प्रीफिक्स ठरवतात। ब्लॉग पोस्टमधील उदाहरण कॉपी करण्याऐवजी सर्व्हरची खरी मूल्ये छापा:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthतक्ता निर्णयासाठी मदतनीस आहे, प्रत्येक तैनातीबद्दलचे विधान नाही। अतिरिक्त इंटरफेस, दुसरा साइट लिंक किंवा वेगळा मास्क असलेल्या होस्टचा स्थानिक संच वेगळा असतो।
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft चे New-NetFirewallRule संदर्भ दूरस्थ पत्ता अटी आणि LocalSubnet कीवर्डचे दस्तऐवजीकरण करते। कीवर्डचा अर्थ सर्व खाजगी पत्ते असा ठरवण्यापूर्वी ते वाचा, कारण तसे नाही।
सर्व्हर प्रत्यक्षात काय प्राप्त करतो याची तुलना करा
कोणी बनवले असे आठवत असलेल्या नियमाऐवजी प्रभावी नियम वाचा। तो सक्षम आहे, सक्रिय प्रोफाइलवर लागू होतो, आणि त्याची दूरस्थ पत्ता अट सर्व्हर पाहतो त्या स्रोताशी जुळते याची तपासणी करा। फक्त Domain प्रोफाइलवर सक्षम नियम नेटवर्क बदलानंतर अॅडॉप्टर Public वर गेल्यावर काहीही करत नाही।
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionपहिला आदेश फाइल शेअरिंग नियमांशी जोडलेले पत्ता फिल्टर छापतो, आणि दुसरा कोणती प्रोफाइल सक्रिय आहेत आणि न जुळणाऱ्या इनबाउंड रहदारीला कसे वागवले जाते हे दाखवतो। ब्लॉकिंग नियम आणि केंद्रीयरीत्या व्यवस्थापित धोरणही पाहा। ब्लॉक नियम परवानगी नियमांवर प्राधान्य घेतात, आणि स्थानिक नियम विलीनीकरण बंद करणारे धोरण नवीन स्थानिक अपवाद निष्क्रिय करू शकते।
नियम कन्सोलमध्ये बरोबर दिसतो आणि रहदारीवर कोणताही परिणाम होत नाही असा हा प्रसंग आहे। त्याच वेळी प्रोफाइल नेमणूक तपासा, कारण दुसऱ्या नेटवर्कमध्ये सामील झालेला लॅपटॉप कोणीही फायरवॉलला स्पर्श न करता Public प्रोफाइलवर जाऊ शकतो।
लॉगिनपूर्वी ट्रान्सपोर्ट तपासा
पोहोच आणि प्रमाणीकरण वेगळे करा। TCP 445 वरील लिसनर सेवा पोर्टशी बांधलेली आहे हे सिद्ध करतो; दूरस्थ पॅकेट तिथवर पोहोचू शकते हे सिद्ध करत नाही। पूर्ण झालेले TCP कनेक्शन, त्या बदल्यात, SMB सत्र सेटअप किंवा शेअर परवानग्यांबद्दल अजून काहीही सांगत नाही। नियम संपादित करण्यापूर्वी दोन्ही बाजूंनी हातमिळवणी तपासा।
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedपहिला आदेश तुम्ही तो चालवता त्या मशीनवरून TCP हातमिळवणी यशस्वी होते का ते नोंदवतो, आणि दुसरा निराकरण केलेला पत्ता व इंटरफेस तपशील जोडतो। तो VPN क्लायंटवरून आणि ऑफिस डेस्कटॉपवरून चालवा, मग तुलना करा। Ping दोन्ही प्रश्नांचे उत्तर देत नाही, कारण SMB उघडे असताना ICMP अवरोधित असू शकते, किंवा फायरवॉल 445 टाकून देत असताना परवानगी असू शकते।
हातमिळवणी फक्त VPN वरून अयशस्वी झाल्यास, स्रोत व्याप्ती हा मुख्य संशयित आहे। ती यशस्वी होते आणि शेअर तरीही नकार देत असल्यास, फायरवॉल नियम संपादित करण्याऐवजी SMB सत्र व परवानगी निदानाकडे जा।
जेव्हा स्रोत NAT फरक काढून टाकते
मार्गात भाषांतर असल्यास, सर्व्हर वैयक्तिक VPN क्लायंटना पत्त्याने वेगळे करू शकत नाही। प्रत्येक दूरस्थ वापरकर्ता गेटवे म्हणून येतो। त्यांना वेगळे करण्यावर अवलंबून असलेले कोणतेही अधिकृतता तिथे लागू करावे लागते जिथे त्यांच्या ओळखी अजून दिसतात, म्हणजे सामान्यतः VPN कॉन्सेंट्रेटर किंवा प्रमाणीकरण करणारा प्रॉक्सी। फायरवॉल नियम रहदारीला प्रवेश देऊ शकतो; भाषांतराने काढून टाकलेला फरक तो पुन्हा आणू शकत नाही।
ते गेटवे पत्ता परवानगी दिल्यावर, प्रत्येक दूरस्थ वापरकर्ता एकाच पत्त्याखाली नोंदवला जातो, त्यामुळे नियम गेटवेपर्यंत पोहोचू शकणाऱ्या प्रत्येकाला संपूर्ण पूल देतो। प्रति-वापरकर्ता निर्णय महत्त्वाचा असल्यास, मूळ पत्ते दृश्यमान ठेवा किंवा निर्णय अशा स्तरावर हलवा जो अजूनही वापरकर्त्याला ओळखतो। अन्यथा प्रत्येक दूरस्थ वापरकर्ता सर्व्हर पाहू शकतो त्या एकाच पत्त्याच्या परवानग्या वारसाहक्काने घेतो, आणि ऑडिट ट्रेल नंतर त्यांना वेगळे करू शकत नाही। हा रचनेचा निर्णय आहे, फायरवॉलचा तपशील नाही।
दोन रचनांमधून जाणीवपूर्वक निवडा। सर्व्हरला कोण जोडले गेले हे पाहायचे असल्यास नियम खऱ्या VPN पूलपर्यंत मर्यादित करा, आणि सर्व्हरला ती माहिती खरोखर आवश्यक नसल्यासच भाषांतरित मार्ग स्वीकारा। निवडलेली स्रोत श्रेणी नियमाच्या शेजारी नोंदवा, कारण हे डीबग करणारी पुढील व्यक्ती प्रथम पत्ता तक्ता पाहील।