Windows चा अंगभूत VPN विक्रेत्याच्या SSL गेटवेपर्यंत का पोहोचत नाही

Windows सोबत चार प्रकारचे टनेल येतात, आणि विक्रेत्याचे SSL गेटवे त्यांपैकी एक नाही। तरीही अंगभूत प्रोफाइल अशा गेटवेकडे वळवले तर क्रेडेन्शियल्स मागण्यापूर्वीच कनेक्शन अयशस्वी होते, सहसा स्थानिक प्रणालीने कनेक्शन थांबवले असा संदेश येतो। तो मजकूर जुळणी नसल्याचा संकेत आहे, निदान नाही। प्रोफाइलचा प्रकार आणि प्रोटोकॉलचा मालक क्लायंट यांची जुळणी असावी लागते, आणि त्यांपैकी एक गायब आहे।

चार प्रकार आणि एक संवाद

प्रत्येक साठवलेल्या प्रोफाइलमध्ये टनेलचा प्रकार असतो। अंगभूत क्लायंट PPTP, L2TP, IKEv2 आणि SSTP स्वीकारतो, शिवाय त्यांना क्रमाने वापरून पाहणारा स्वयंचलित मोड। सामान्य SSL VPN नोंद नाही, आणि संवादातून एक जोडण्याचा मार्गही नाही। विक्रेत्याचे गेटवे TLS वर स्वतःचे अनुप्रयोग प्रोटोकॉल बोलते, जे केवळ त्या विक्रेत्याचा क्लायंट अंमलात आणतो।

यादी एका आदेशावर आहे, आणि इतर कोणत्याही समस्या-निवारणापूर्वी ती चालवणे योग्य आहे, कारण तिला एक सेकंद लागतो आणि चुकीच्या गृहीतकांचा संपूर्ण वर्ग दूर होतो:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

प्रोफाइल SSTP म्हणत असेल आणि गेटवे RRAS सर्व्हर नसेल, तर जुळणी नसल्याचे आधीच सिद्ध झाले आहे। प्रमाणपत्र किंवा फायरवॉलचे कोणतेही काम ते बदलत नाही।

SSTP आणि विक्रेत्याचे TLS पोर्ट 443 वर सारखेच दिसतात

SSTP एक PPP सत्र TLS मध्ये गुंडाळून TCP 443 वर चालते। Microsoft स्टॅकमध्ये ते RRAS संपवते, जे क्लायंट पडताळणारे सर्व्हर प्रमाणपत्र सादर करते। Fortinet, Citrix किंवा Pulse उपकरणही 443 वर TLS संपवते, आणि त्याचे पोर्टल कोणत्याही ब्राउझरमध्ये तक्रारीशिवाय उघडते।

ती ब्राउझर चाचणी पोहोच सिद्ध करते, सुसंगतता नाही। पोर्टलमागील सत्र प्रोटोकॉल विक्रेत्याचा आहे, आणि अंगभूत क्लायंटकडे त्याची कोणतीही अंमलबजावणी नाही। विक्रेता स्वतःचा क्लायंट पुरवतो का, यावरून तुम्ही जुळणी नसल्याच्या कोणत्या अर्ध्याशी व्यवहार करत आहात ते कळते।

उलटा गोंधळही होतो। खऱ्या RRAS सर्व्हरसमोर SSTP म्हणून संरचित प्रोफाइल प्रमाणपत्र पडताळणीत अयशस्वी होऊ शकते, तर पोर्टल ठीक असते, आणि ती प्रमाणपत्राची समस्या आहे, प्रोटोकॉलची नाही।

टनेल तयार होण्यापूर्वी दिसणाऱ्या त्रुटी

800 मालिकेतील कोड कोणतेही टनेल प्रस्थापित होण्यापूर्वी नोंदवले जातात, म्हणूनच फायरवॉल नियम त्यांना क्वचित हलवतात। त्रुटी 812 हे सर्व्हर-बाजूचे धोरण आहे जे क्लायंटने दिलेली प्रमाणीकरण पद्धत नाकारते। या श्रेणीतील इतर स्थानिक कनेक्शन व्यवस्थापकाकडून येतात, नेटवर्ककडून नाही।

काहीही पुन्हा बांधण्यापूर्वी ट्रेसिंग सुरू करा। ट्रेसिंग अयशस्वी होणाऱ्या टप्प्याचे नाव सांगते, आणि टप्प्याचे नाव संवादातील मजकुरापेक्षा अधिक मोलाचे आहे:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

ट्रेस ट्रेसिंग डिरेक्टरीखाली साठतात आणि तुम्ही ते साफ करेपर्यंत तिथेच राहतात, म्हणून नंतर ट्रेसिंग बंद करा, आठवडेभर सुरू ठेवू नका।

जोडलेले प्रोफाइलही सर्व काही तोडू शकते

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

दोन नियंत्रके हे ठरवतात। एक म्हणजे प्रोफाइलवरील स्प्लिट-टनेलिंग गुणधर्म। दुसरे म्हणजे दूरस्थ नेटवर्कवर डीफॉल्ट गेटवे वापरण्याचा प्रत्येक अडॅप्टरचा पर्याय, जो IPv4 च्या प्रगत सेटिंग्जखाली आहे।

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

मार्ग न जोडता स्प्लिट टनेलिंग सुरू केल्यास जोडते पण कुठेही पोहोचत नाही असे टनेल तयार होते। DNS न तपासता ते बंद केल्यास अंतर्गत नावे सार्वजनिक उत्तरांमध्ये रूपांतरित होतात, कारण अडॅप्टरचा स्वतःचा प्रत्यय आणि सर्व्हर वापरले जात नाहीत।

प्रथम प्लंबिंग तपासा, नंतर प्रकार

या क्रमाने काम करा, आणि सर्व काही एकाच वेळी सुधारण्याऐवजी एखादा टप्पा अयशस्वी झाल्यास थांबा:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

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

तिकिटात टनेलचा प्रकार, गेटवेचे उत्पादन आणि नेमकी त्रुटी नोंदवा। मग पुढच्या व्यक्तीला एका मिनिटात कळते की ही प्रोटोकॉल जुळणी नसणे, प्रमाणपत्राची अयशस्वीता की मार्गनिर्देशनाचा निर्णय आहे, “VPN चालत नाही” पासून सुरुवात करण्याऐवजी।