SSTP समय सकिनु वा प्रमाणपत्र त्रुटि: दुईलाई कसरी छुट्याउने

SSTP जडान प्रयोगकर्ताको कुर्सीबाट एउटै देखिने दुई तरिकाले असफल हुन्छ, र प्रत्येकको मर्मत फरक तहमा हुन्छ। समय सकिनु भन्नाले आवश्यक आदानप्रदान कहिल्यै सकिएन; प्रमाणपत्र त्रुटि भन्नाले पहिचानको सामग्री आयो र अस्वीकार गरियो। दोस्रोलाई पहिलोजस्तै लिनुभयो भने कहिल्यै समस्या नभएका फायरवाल र पासवर्डतिर जानुहुन्छ। फरक देखाउने प्रमाण क्लाइन्टकै लगमा छ, केही बदल्नु अघि त्यो पढ्नुभयो भने।

दुई असफलता, दुई फरक आदानप्रदान

SSTP ले HTTPS आकारको सत्रभित्र सुरुङ बोक्छ, त्यसैले 443 बाहेक केही नदिने सञ्जालमा पनि टिक्छ। क्लाइन्टले TLS ह्यान्डशेक सक्छ, प्रोटोकल-विशिष्ट विधिबाट HTTP अनुरोध पठाउँछ, अनि सुरुङ त्यही स्ट्रिमभित्र चल्छ। ती चरणमध्ये कुनैमा असफलता जडान रोक्छ, र केवल पछिल्ला चरणहरू मात्र लगइन जानकारीसँग सम्बन्धित छन्।

त्यही क्रम निदान हो। TLS ह्यान्डशेक कहिल्यै नसकिएमा कुनै लगइन जानकारी पठाइएको थिएन, त्यसैले पासवर्ड रिसेटले सहयोग गर्न सक्दैन। ह्यान्डशेक सकिएर त्यसपछि अड्कियो भने पहिचान स्वीकार गरियो र अनुरोधको बाटोमा केहीले त्यसलाई अस्वीकार गर्यो। ह्यान्डशेक प्रमाणीकरण सन्देशसँग असफल भयो भने सर्भरले जवाफ दियो र क्लाइन्टलाई सुनेको कुरा मन परेन। तीन नतिजा, तीन तह।

लगको लाइनले सामान्यतया तपाईं तीनमध्ये कुनमा हुनुहुन्छ भनी बताउँछ, त्यसैले पहिलो परिवर्तनअघि त्यो टिप्नु उपयुक्त हुन्छ।

समय सकिनु भन्नाले एउटा चरण कहिल्यै सकिएन

नाम समाधान र TCP पहुँचबाट सुरु गर्नुहोस्, किनकि त्यहाँको समय सकिनु पछिको समय सकिनेजस्तै देखिन्छ। 443 खुला छ भनी रिपोर्ट गर्ने पोर्ट जाँचकर्ताले श्रोताले जडान स्वीकार गरेको मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन।

अर्को शंकास्पद होस्ट होइन, मार्ग हो। प्रोक्सी र एप्लिकेसन बुझ्ने फायरवालले कहिलेकाहीँ SSTP प्रयोग गर्ने अनुरोध विधि अस्वीकार गर्छन्, वा घण्टौं खुला रहने स्ट्रिम खसाल्छन्, र दुवै व्यवहार क्लाइन्टबाट समय सकिएजस्तै देखिन्छ। एउटै होस्टले दिने साधारण HTTPS पृष्ठ सुरुङ विधि अस्वीकार हुँदा पनि राम्ररी लोड हुन्छ, त्यसैले अन्तिम बिन्दुतिर ब्राउज गर्नु धेरै थोरै प्रमाणित गर्छ। ती दुई अवस्था छुट्याउन प्रोक्सी नभएको सञ्जालबाट परीक्षण गर्नुहोस्।

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

साथीको कुनै पनि प्रतिक्रियाअघिको समय सकिनु खाताबारे केही बताउँदैन, र त्यो क्षणमा पासवर्ड बदल्नुले एउटा चल मात्र थप्छ।

प्रमाणपत्र त्रुटि भन्नाले पहिचान अस्वीकार गरियो

यहाँ सर्भरले साँच्चै जवाफ दियो, त्यसैले सञ्जाल चलिरहेको छ र प्रश्न पहिचानतिर सर्छ। क्लाइन्टले डायल गर्ने नाम लाई प्रमाणपत्रले साँच्चै दाबी गर्ने नामहरूसँग तुलना गर्नुहोस्, अनि वैधता मिति र जारीकर्ता शृंखला जाँच्नुहोस्।

क्लाइन्टले विश्वास नगर्ने निजी CA ले म्याद सकिएको प्रमाणपत्रकै जस्तो त्रुटि वर्ग उत्पादन गर्छ, र घण्टौं गलत चल्ने घडीले पनि त्यस्तै। कच्चा ठेगानामा डायल गर्दा नयाँ बेमेल बन्छ, किनकि प्रमाणपत्रले नामको दाबी गर्छ, ठेगानाको होइन। व्यवस्थित तैनातीमा त्रुटि पृष्ठले दिने प्रतिस्थापन मूल स्वीकार गर्नुको सट्टा त्यसको प्रशासकबाट इच्छित विश्वास कन्फिगरेसन लिनुहोस्। कारण सुधार्दा प्रमाणीकरण खुला रहन्छ।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

सफल TLS चरण पार भएपछि त्यसै गरी राख्नुहोस्, किनकि पछि त्यो उल्टाउँदा कुन परिवर्तनले सुरुङ साँच्चै सुधार्यो भन्ने लुक्छ।

दुई कहाँ गोलमोल हुन्छन्

दुवै असफलता उठ्न नसक्ने जडानको रूपमा देखिन्छन्, र दुवै प्रयोगकर्ताले असम्बन्धित केही बदलेपछि आउँछन्। त्यही संयोगले गलत मर्मतलाई केही समय विश्वसनीय देखाउँछ।

दुई बानीले तिनलाई अलग राख्छन्। कन्फिगरेसन छुनुअघि क्लाइन्ट लग टिप्नुहोस्, पहिलो अवस्था जोगिओस्। प्रत्येक प्रयासमा एउटा तह बदल्नुहोस्, अर्को नतिजा ज्ञात चलको होस्। पोर्ट जाँचकर्ता र ब्राउजर पूरा क्रम होइन, आंशिक अवलोकन हुन्, र कुनैले पनि क्लाइन्टको आफ्नै प्रतिवेदनको ठाउँ लिँदैन। दुवै बानीको खर्च छैन, र दुवैले अनुसन्धान छोटो बनाउँछन्।

प्रमाणपत्रको प्रश्न र पहुँचको प्रश्न कुनै कारणले अलग राखिएका छन्।

वास्तविक क्लाइन्टसँग फेरि परीक्षण गर्नुहोस्, अनि भित्रतिर जानुहोस्

ठ्याक्कै सुधार ठाउँमा आएपछि ब्राउजर ट्याबले होइन, वास्तविक SSTP क्लाइन्ट र साँचो प्रोफाइलले फेरि प्रयास गर्नुहोस्।

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

सत्र जोडियो तर स्रोतहरू अझै असफल भइरहे भने सुरुङ अब शंकास्पद होइन: रुटिङ, DNS र सेवा-पहुँचतिर जानुहोस्। त्यो फरक प्रमाणसहितको फरक अनुसन्धान हो। चलिरहेका TLS र प्रमाणीकरण चरण जोगाए राख्दा त्यो पहिलोको पुनरावृत्ति हुँदैन। असफल भएको चरण टिकटमा लेख्नुहोस्, नत्र अर्को व्यक्ति फेरि माथिबाट सुरु गर्नेछ।