क्या फ़ायरवॉल 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

जब तुलना नेटवर्क काम करता है, मूल नेटवर्क फिर भी विफल रहता है और ईवेंट खाली रहते हैं, तो बचा हुआ संदिग्ध पथ है, होस्ट नहीं। दोनों तुलना परिणाम संलग्न करके इसे नेटवर्क मालिक को ठोस कथन के रूप में दें। बंद किए गए फ़ायरवॉल प्रोफ़ाइल की तुलना में यहाँ रुकना बेहतर है।