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 कडे पाठवा। मग क्लायंट कोणत्याही पोर्टशिवाय डीफॉल्ट प्रोफाइल वापरतो, जे सहसा व्यवस्थापित ताफ्यासाठी सर्वात स्वच्छ व्यवस्था असते आणि अनुकूलित पोर्ट अंतर्गत तपशील राहतो।

संबंधित लेख