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 सार्वजनिक प्रोफ़ाइल पर नहीं है।
• परीक्षण पास कराने के लिए कुछ भी बंद नहीं किया गया, और हर श्रेणी परिवर्तन दर्ज करता है कि किसने उसे मंज़ूरी दी।