Windows VPN के पते वाले फ़ील्ड में पोर्ट केवल SSTP के साथ काम करता है

सर्वर नाम फ़ील्ड host:port नहीं है। PPTP, L2TP और IKEv2 के पोर्ट स्थिर हैं; SSTP पोर्ट को केवल पूर्ण https:// URL के रूप में स्वीकार करता है, और 443 आगे भेजना अधिक साफ़ है।

एक VPN सर्वर TCP 10443 पर जवाब देता है, Windows का अंतर्निहित क्लाइंट सही क्रेडेंशियल रखता है, और कनेक्शन फिर भी DNS टाइमआउट जैसे ठहराव के बाद टूट जाता है। कारण आम तौर पर पता फ़ील्ड होता है: सर्वर नाम या पता में vpn.example.com:10443 लिखने पर Windows पूरी स्ट्रिंग को होस्टनाम के रूप में पढ़ता है, क्योंकि वह बॉक्स सामान्य host:port इनपुट नहीं है। पोर्ट वहाँ व्यक्त हो सकता है या नहीं, यह प्रोफ़ाइल के टनल प्रकार पर निर्भर करता है, और चार प्रकारों में से केवल एक ही मान को ऐसी चीज़ मानता है जिसे वह पार्स कर सके।

पता फ़ील्ड host:port बॉक्स क्यों नहीं है

उस फ़ील्ड के पीछे की प्रोफ़ाइल प्रॉपर्टी ServerAddress है, और हर टनल प्रकार तय करता है कि स्ट्रिंग के साथ क्या करना है। उनमें से तीन के पास भरने के लिए कोई पोर्ट पैरामीटर नहीं है, इसलिए कोलन और संख्या केवल ऐसे नाम के अक्षर हैं जो कभी हल नहीं होगा। चौथा HTTPS पर चलता है, जहाँ पोर्ट URL का हिस्सा होता है, इसलिए मान ऐसे रूप में लिखा जाना चाहिए जो URL के रूप में पार्स हो।

इसीलिए विफलता नाम-समाधान जैसी दिखती है, अस्वीकृत कनेक्शन जैसी नहीं। रिपोर्ट करने के लिए कोई खराब पोर्ट नहीं है, केवल एक ऐसा होस्टनाम है जो मौजूद नहीं है, और त्रुटि रिज़ॉल्वर के हार मानने के बाद आती है। सर्वर को छूने से पहले जाँचें कि प्रोफ़ाइल किस टनल प्रकार का दावा करती है।

स्थिर पोर्ट वाले तीन प्रकार

PPTP TCP 1723 से जुड़ता है और फिर टनल को GRE, IP प्रोटोकॉल 47 में ले जाता है। L2TP/IPsec टनल के लिए UDP 1701 और IPsec के लिए UDP 500 तथा 4500 का उपयोग करता है, जिसमें 4500 NAT पार करने का पोर्ट है। IKEv2 भी UDP 500 और 4500 का उपयोग करता है। इनमें से कोई भी प्रोफ़ाइल इंटरफ़ेस में कहीं भी पोर्ट फ़ील्ड नहीं दिखाती, और कोई भी गैर-मानक पोर्ट पर बातचीत नहीं करेगा।

इसलिए किसी अनुकूलित पोर्ट पर सुनने वाला सर्वर इन प्रोफ़ाइलों के लिए अगम्य है, चाहे पता कैसे भी लिखा जाए। व्यावहारिक उत्तर सीमित हैं: मानक पोर्ट को सर्वर पर प्रकाशित करें, या मानक पोर्ट को उसके आगे वाले राउटर पर अनुकूलित पोर्ट में बदलें। दोनों क्लाइंट प्रोफ़ाइल को अछूता छोड़ देते हैं, जो तब बहुत मूल्यवान होता है जब प्रोफ़ाइल नीति से तैनात हो, हाथ से लिखी न जाए।

SSTP को URL चाहिए, नाम नहीं

SSTP अपवाद है क्योंकि यह TLS सत्र के भीतर चलता है। फ़ील्ड को URL के रूप में पार्स होना चाहिए: पहले https:// स्कीम, फिर होस्ट, फिर कोलन और पोर्ट। स्कीम के बिना Windows मान को साधारण नाम ही मानता रहता है और कनेक्शन किसी भी TLS अदला-बदली से पहले विफल हो जाता है।

इस पर लोगों को आश्चर्य होने की वजह यह है कि डिफ़ॉल्ट पोर्ट नंगे होस्टनाम को स्वीकार करता है। जिस प्रोफ़ाइल को कभी अनुकूलित पोर्ट की ज़रूरत नहीं पड़ी, वह यह नियम कभी नहीं सिखाती, और जो पहला व्यक्ति एक जोड़ता है वह इसे विफलता से ही जानता है। सहेजने के बाद संवाद बॉक्स पर भरोसा करने के बजाय सहेजा गया मान फिर से पढ़ें:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress ठीक वही दिखाता है जो सहेजा गया था। अगर यह कोलन वाले नंगे होस्टनाम के रूप में पढ़ा जाए, तो प्रोफ़ाइल को कभी URL नहीं मिला और कितनी भी बार दोबारा कोशिश करने से यह ठीक नहीं होगा।

उसी बॉक्स में चिपकाया जाने वाला विक्रेता सिंटैक्स

कुछ गेटवे उस फ़ील्ड के लिए अतिरिक्त परंपराएँ दर्ज करते हैं, जैसे पोर्ट के बाद जोड़ा गया realm या ऐसे क्वेरी पैरामीटर जो प्रमाणपत्रों का व्यवहार बदलते हैं। उन्हें उस विक्रेता का सर्वर समझता है और कुछ बिल्ड्स में उसका अपना क्लाइंट भी। वे Windows प्रोफ़ाइल प्रारूप का हिस्सा नहीं हैं, और उन्हें अंतर्निहित प्रोफ़ाइल में चिपकाने से आम तौर पर वही मौन नाम विफलता होती है।

प्रमाणपत्र सत्यापन बंद करने वाले पैरामीटर को सुधार के बजाय चेतावनी मानें। अगर कोई प्रोफ़ाइल केवल उसी पैरामीटर से जुड़ती है, तो प्रमाणपत्र उस नाम से मेल नहीं खाता जो इस्तेमाल हो रहा है, और सही मरम्मत गेटवे पर है, क्लाइंट में नहीं। पोर्ट के बाद का realm भी यही गुण रखता है: वह कुछ करता है केवल तब जब दूसरी तरफ़ का सर्वर उसकी अपेक्षा करे।

पोर्ट साबित करें, फिर विफल चरण पढ़ें

प्रोफ़ाइल को दोष देने से पहले पुष्टि करें कि क्लाइंट के नेटवर्क से कोई चीज़ उस पोर्ट पर TCP स्वीकार करती है:

Test-NetConnection vpn.example.com -Port 10443

सफलता श्रोता साबित करती है, SSTP नहीं। वेब सर्वर, रिवर्स प्रॉक्सी या लोड बैलेंसर TCP हाथ मिलाना पूरा कर सकते हैं और फिर भी SSTP नहीं बोल सकते, इसलिए हरा परीक्षण और लाल VPN वास्तविक संयोजन है। प्रमाणपत्र के विषय की तुलना प्रोफ़ाइल में नाम से करें, और उन बिल्ड्स में RasClient लॉग देखें जिनमें वह शामिल है, क्योंकि वह सामान्य टाइमआउट के बजाय विफल हुआ चरण दर्ज करता है।

फिर उस विकल्प पर विचार करें जो समस्या को दर्ज करने के बजाय हटा देता है: बाहर से TCP 443 को VPN सर्वर पर 10443 की ओर भेजें। तब क्लाइंट बिना किसी पोर्ट के डिफ़ॉल्ट प्रोफ़ाइल इस्तेमाल करता है, जो आम तौर पर प्रबंधित फ़्लीट के लिए सबसे साफ़ व्यवस्था है और अनुकूलित पोर्ट को आंतरिक विवरण बना देता है।

संबंधित लेख