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 पूलमा सीमित गर्नुहोस्, र सर्भरलाई त्यो जानकारी साँच्चै आवश्यक नभएमा मात्र अनुवादित मार्ग स्वीकार गर्नुहोस्। छनोट गरिएको स्रोत दायरा नियमको छेउमा लेख्नुहोस्, किनकि यसलाई डिबग गर्ने अर्को व्यक्तिले पहिले ठेगाना तालिका हेर्नेछ।