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 काम नहीं करता” से शुरू करने के बजाय।