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 पूल तक सीमित करें, और अनुवादित पथ को केवल तब स्वीकारें जब सर्वर को वह जानकारी वास्तव में न चाहिए। चुना गया स्रोत रेंज नियम के बगल में दर्ज करें, क्योंकि इसे डीबग करने वाला अगला व्यक्ति पहले पता तालिका देखेगा।