Windows को सार्वजनिक फायरवाल प्रोफाइलले VPN क्लाइन्टहरू अवरुद्ध गर्छ

Windows ले VPN एडाप्टरलाई सार्वजनिक रूपमा वर्गीकृत गर्छ, त्यसैले तपाईंका LAN नियमहरू कहिल्यै लागू हुँदैनन्। प्रोफाइल जाँच गर्नुहोस्, एउटा इनबाउन्ड नियमलाई पूलसम्म सीमित गर्नुहोस्, त्यसपछि पोर्ट प्रमाणित गर्नुहोस्।

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

सम्बन्धित लेखहरू