के फायरवालले VPN रोकिरहेको छ? चरणबद्ध जाँच
टाइमआउटले दोषीको नाम लिँदैन। श्रोता, मार्ग र सुरक्षा लग क्रमैसँग जाँच्नुहोस्, र प्रमाणले देखाएपछि मात्र एउटा नियम बदल्नुहोस्।
एउटा VPN टाइमआउटले कुनै उपयोगी उत्तर आएन भन्ने मात्र प्रमाणित गर्छ, र किन भन्नेबारे केही प्रमाणित गर्दैन। प्रोफाइलले गलत पोर्ट देखाउन सक्छ, सर्भर बन्द हुन सक्छ, वा अनुरोध काम गर्ने फर्कने मार्ग बिना आउन सक्छ। यीमध्ये प्रत्येकले फरक चिन्ह छोड्छ, र त्यही चिन्हले कुन नियम छुनुपर्ने बताउँछ। तलका चार चरण क्रमैसँग पूरा गर्नुहोस्। यीमध्ये कुनैले लक्षण व्याख्या गरेपछि तुरुन्तै रोक्नुहोस्।
चरण 1: सर्भर र ट्रान्सपोर्ट पुष्टि गर्नुहोस्
सर्भरको नाम, ट्रान्सपोर्ट र पोर्ट स्थानीय परिवर्तनबाट नभई अपरेटरको हालको प्रोफाइलबाट पढ्नुहोस्। तपाईंको ल्यापटपमा बदलिएको पोर्टले सार्वजनिक सर्भरमा श्रोता बनाउन सक्दैन, र त्यो अमिल्दोले अवरोध जस्तै टाइमआउट दिन्छ। प्रोफाइलले समर्थित वैकल्पिक ट्रान्सपोर्ट दिन्छ भने त्यसलाई समाधान नभई विकल्पका रूपमा लेख्नुहोस्। नाम समाधान गर्नुहोस् र उत्तरलाई अपरेटरले प्रकाशित गरेको ठेगानासँग तुलना गर्नुहोस्।
पुरानो DNS रेकर्डले क्लाइन्टलाई कहिल्यै जवाफ नदिएको होस्टमा पठाउँछ। यो पनि फिल्टरको नक्कल गर्ने अर्को दोष हो, र यसलाई हटाउन एक क्वेरी मात्र लाग्छ।
दुवै मान टिकटमा लेख्नुहोस्। पछिको हरेक तुलनाले तिनलाई प्रयोग गर्छ, र ती बिना टिकटले अनुसन्धान फेरि सुरु गर्छ।
चरण 2: एउटा नियन्त्रित तुलनाबाट मार्ग प्रमाणित गर्नुहोस्
उपकरण र प्रोफाइल नबदली अर्को विश्वसनीय पहुँच सञ्जाल प्रयास गर्नुहोस्। त्यहाँ टनेल उठ्यो भने फरक मूल मार्ग वा त्यसको नीति हो। मूल सञ्जालमा दोस्रो स्वीकृत उपकरण चल्यो भने फरक पहिलो उपकरण हो। यी दुई तुलनामध्ये एउटा लगभग सधैं निर्णायक हुन्छ।
पहिले कुनै पनि वैध सञ्जाल साइन-इन पूरा गर्नुहोस्, किनभने क्याप्टिभ पोर्टल पूरा नहुँदासम्म अवरोध जस्तै देखिन्छ।
तपाईंले वास्तवमा प्रयोग गर्ने पोर्ट जाँच्नुहोस्, र TCP नतिजालाई TCP बारेको जानकारी मात्र मान्नुहोस्।
Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailedपोर्ट 443 मा सफल TCP ह्यान्डशेक भन्नुको अर्थ त्यहाँ श्रोताले जवाफ दियो। यसले 51820 मा UDP श्रोताबारे केही भन्दैन, र वार्ता पूरा भयो कि भएन पनि भन्दैन।
चरण 3: असफलताको क्षणका सुरक्षा घटना पढ्नुहोस्
फायरवाल घटना उपलब्ध सबैभन्दा बलियो प्रमाण हुन्, र तिनीसँग पहिले भन्नुपर्ने एउटा सावधानी छ। धेरै पूर्वनिर्धारित प्रोफाइलमा लगिङ बन्द हुन्छ, त्यसैले खाली लगलाई निर्दोषताको प्रमाण पढ्नुअघि सम्बन्धित प्रोफाइलले ड्रप रेकर्ड गर्छ कि गर्दैन जाँच्नुहोस्। लगिङ खुला हुँदा घटनाले नियम, दिशा र ठेगाना बताउँछ, जुन नियम परिवर्तनका लागि ठ्याक्कै आवश्यक हो। अनुप्रयोग नियम र पोर्ट नियम अलग वस्तु हुन्, र व्यवस्थित नीतिले स्थानीय सेटिङलाई पछि पार्न सक्छ। कुनै नियमले वास्तवमा कुन क्लाइन्ट र कुन सेवा समेट्छ पुष्टि गर्नुहोस्।
प्रोफाइलको अवस्था र हालका घटना असफल भएको मेसिनबाटै संकलन गर्नुहोस्, छेउको होस्टबाट होइन।
घटनाको समयलाई तपाईंको परीक्षणको समयसँग मिलाउनुहोस्, किनभने फरक टाइमस्ट्याम्पसँग मिल्ने नियमको नाम संयोग हो।
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20तपाईंले व्यवस्थापन गर्ने सर्भरमा सोध्नुहोस् कि अनुरोध श्रोतासम्म पुग्यो कि पुगेन। जवाफ बिना आउने प्याकेट फर्वार्डिङ वा फर्कने मार्गको समस्या हो। कहिल्यै नदेखिने अनुरोध फिल्टरिङ वा ठेगाना तोक्ने समस्या हो।
चरण 4: टनेल उठेपछि फर्वार्डिङ जाँच्नुहोस्
फायरवालले सत्रलाई अनुमति दिएर पनि सत्रले पुग्न चाहेको सबै अस्वीकार गर्न सक्छ। फर्वार्डिङ sysctl, NAT नियम र फर्कने मार्ग सबै प्रमाणीकरणपछि हुन्छन्, र VPN पोर्टका लागि व्यापक छुटले तीमध्ये एउटै सुधार्दैन। एउटा आन्तरिक गन्तव्य र एउटा इन्टरनेट गन्तव्य छुट्टै जाँच्नुहोस्, किनभने ती सामान्यतया फरक कारणले असफल हुन्छन्। आन्तरिक नाम असफल भई ठेगाना चले भने कुनै पनि नियमअघि धकेलिएको DNS हेर्नुहोस्।
क्लाइन्ट जोडिएको र असफल अनुरोध गर्दै गरेको बेला सर्भरमा तलका तीन जाँच चलाउनुहोस्।
टनेल इन्टरफेसका काउन्टर नै मुख्य कुरा हुन्, किनभने तिनले प्याकेट भित्र आए कि आएनन् र केही बाहिर गयो कि गएन देखाउँछन्।
sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10टनेलमा प्याकेट आए तर गन्तव्यतिर केही गएन भने शंकास्पद फर्वार्डिङ वा NAT हो। केही पनि आएन भने सत्र उठेको छ तर क्लाइन्ट पठाइरहेको छैन, र हेर्ने ठाउँ क्लाइन्टको मार्ग तालिका हो।
सुधार जाँच्नुहोस् र जसले मद्दत गरेन त्यो हटाउनुहोस्
स्वीकृत सुधारपछि असफल भएको ठ्याक्कै त्यही परीक्षण दोहोर्याउनुहोस् र नतिजा उही प्रोफाइल र उपकरणसँग लेख्नुहोस्। त्यसपछि नतिजा नबदलेको कुनै पनि अस्थायी छुट हटाउनुहोस्, किनभने नचलेका छुट थुप्रिन्छन् र हरेक कसैले सम्झना नगरेको निर्णय हो। बाँकी रहेको साँघुरो राख्नुहोस्: एउटा गन्तव्य, एउटा पोर्ट, एउटा दिशा, एउटा मालिक।
तीही तीन आदेश फेरि चलाउनुहोस् र परिवर्तनअघि सुरक्षित गरेको आउटपुटसँग तुलना गर्नुहोस्।
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Actionतुलना सञ्जाल चले, मूल सञ्जाल अझै असफल भइरहे र घटना खाली रहे, बाँकी शंकास्पद मार्ग हो, होस्ट होइन। दुवै तुलना नतिजा संलग्न गरी त्यो सञ्जाल मालिकलाई ठोस भनाइका रूपमा दिनुहोस्। बन्द गरिएको फायरवाल प्रोफाइलभन्दा यहाँ रोकिनु राम्रो हो।