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

सम्बन्धित लेखहरू