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

तुलना जाळे चालते, मूळ जाळे अजूनही अयशस्वी होते आणि घटना रिकाम्या राहतात तेव्हा उरलेला संशयित मार्ग आहे, होस्ट नाही. दोन्ही तुलना निकाल जोडून ते जाळे मालकाला ठोस विधान म्हणून द्या. बंद केलेल्या फायरवॉल प्रोफाइलपेक्षा इथे थांबणे बरे.