Linux वर लॉगिनपूर्वी SSTP अयशस्वी होतो? रनटाइम भाग तपासा

तुम्ही SSTP प्लगइन स्थापित करता, नेटवर्क संपादकात रेडिओ बटण दिसते, तुम्ही गेटवे आणि वापरकर्तानाव भरता, आणि प्रोफाइल पासवर्ड विचारण्यापूर्वीच सामान्य त्रुटीने अयशस्वी होते. या क्रमात काहीही असामान्य नाही, आणि त्यात बोगदा सॉफ्टवेअर स्थापित आहे हे सिद्ध करणारे काहीही नाही. SSTP कनेक्शन स्वतंत्रपणे पुरवल्या जाणाऱ्या भागांपासून जोडले जाते: NetworkManager सुरू करू शकणारे VPN प्लगइन, TLS आणि PPP सत्र धारण करणारा SSTP क्लायंट प्रोग्राम, त्याखालील PPP डेमन, आणि कनेक्शनला वाचण्यास परवानगी असलेली रहस्य भांडार.

मेनू नोंद काय जोडते आणि काय नाही

प्लगइन NetworkManager ला ते कसे सुरू करायचे ते सांगणारे सेवा वर्णन देतो, आणि बहुतेक वितरणांमध्ये फॉर्म काढणारा छोटा संपादकही देतो. मेनू नोंदीची संपूर्ण व्याप्ती एवढीच आहे. क्लायंट प्रोग्राम वेगळ्या स्रोत पॅकेजमधून येतो, आणि प्लगइनचे स्वतःचे README ते विभाजन सरळ सांगते: हे प्लगइन आहे, क्लायंट नाही.

मग क्लायंटला PPP लागते, कारण SSTP TLS कनेक्शनच्या आत PPP सत्र वाहते. pppd शिवाय बोगदा TLS हस्तांदोलन पूर्ण करू शकतो आणि तरीही पहिल्या नियंत्रण चौकटीवर मरू शकतो, जे क्रेडेन्शियल्सच्या समस्येसारखे दिसते पण नाही. Debian आणि Ubuntu वर भाग network-manager-sstp, sstp-client आणि ppp म्हणून येतात, आणि फक्त पहिला स्थापित करणे हे फॉर्म प्रत्येक क्षेत्र स्वीकारतो पण कनेक्शन कधीही पूर्ण होत नाही याचे सर्वात सामान्य कारण आहे.

डेस्कटॉप निवड आणखी एक विभाजन जोडते. Plasma प्रोफाइल plasma-nm द्वारे संपादित करते, ज्याला स्वतःचा SSTP घटक लागतो आणि तेच सेवा वर्णन वाचते, म्हणून SSTP नोंद नसलेला संपादक आणि प्रोफाइल चांगले तयार करणारा CLI हे तुटलेले रनटाइम नाही, तर गहाळ संपादक अर्धा आहे.

काहीही पुन्हा स्थापित करण्यापूर्वी पहिला अयशस्वी टप्पा वाचा

अयशस्वी SSTP प्रयत्न ठराविक क्रमाने टप्प्यांतून जातो, आणि जो टप्पा अयशस्वी झाला तो कोणता घटक पाहावा हे सांगतो.

प्लगइन सुरू करणे पहिले आहे, आणि तिथल्या अयशस्वीतेमुळे सर्व्हरबद्दल नाही तर VPN सेवेबद्दल संदेश मिळतो. नंतर पोर्ट 443 वर TCP कनेक्शन येते; इथे नकार किंवा कालबाह्यता ही पोहोचण्याची समस्या आहे, TLS ची नाही. नंतर TLS हस्तांदोलन आणि सर्व्हर ओळख तपासणी, नंतर PPP चर्चा आणि खाते प्रमाणीकरण, आणि शेवटी पत्ता वाटप आणि मार्ग. प्रोफाइल एकदा सक्रिय करताना journalctl -f -u NetworkManager पाहा, आणि शेवटच्या सामान्य ओळीऐवजी पहिली विशिष्ट ओळ वाचा.

हा क्रम एक सामान्य चुकीचे वाचन स्पष्ट करतो. कोणतेही क्रेडेन्शियल पाठवण्यापूर्वी प्रमाणपत्राची तक्रार नोंदवली जाते, म्हणून पासवर्ड बदलल्याने मदत होऊ शकत नाही; PPP प्रमाणीकरण नकार यशस्वी हस्तांदोलनानंतर येतो, म्हणून प्रमाणपत्र बदलल्यानेही मदत होत नाही. पहिली त्रुटी आणि तिचा टप्पा ठेवा, मग लक्षण नाही तर निदान मिळेल.

प्रमाणपत्रावरील विश्वास आणि खात्यातील लॉगिन ही दोन वेगळी दारे आहेत

हस्तांदोलन सर्व्हर हाच तो आहे जिथे तुम्हाला पोहोचायचे होते हे तुम्ही कॉन्फिगर केलेला जारीकर्ता आणि नाव वापरून तपासते. त्यानंतरच PPP स्तर तुमचे वापरकर्तानाव आणि पासवर्ड गेटवेच्या प्रमाणीकरण पद्धतीला देतो. म्हणजे दोन स्वतंत्र तपासण्या, ठराविक क्रमाने मूल्यांकन होतात, प्रत्येकासाठी वेगळी सेटिंग्ज. पासवर्ड क्षेत्रात टाइप केलेले काहीही पहिल्यावर परिणाम करू शकत नाही.

चुकीच्या जारीकर्त्यावर विश्वास ठेवणारे प्रोफाइल पहिल्या दारात ओळख त्रुटीने अयशस्वी होते. त्यावर योग्य विश्वास ठेवणारे पण जुना पासवर्ड साठवणारे प्रोफाइल दुसऱ्या दारात प्रमाणीकरण नकाराने अयशस्वी होते. दोन्ही जोडले जाणार नाहीत अशा VPN सारखी दिसतात, आणि एकही दुसऱ्याच्या उपायाने सुधारत नाही.

संपादकाच्या डीफॉल्टचा अंदाज लावण्याऐवजी गेटवे चालवणाऱ्याकडून अपेक्षित जारीकर्ता आणि सर्व्हर नाव घ्या, आणि त्यांना आवश्यक असलेली प्रमाणीकरण पद्धत नोंदवा. संस्थेला प्लगइन व्यक्त करू शकत नाही अशी पद्धत हवी असल्यास, प्रामाणिक उत्तर अशी क्लायंट आहे जी करू शकते, त्रुटी नाहीशी करण्यासाठी पडताळणी बंद केलेले प्रोफाइल नाही.

प्रोफाइल आणि रहस्यांचा मालक एकच असू द्या

प्रोफाइल तयार झाल्यावर ते NetworkManager द्वारे सक्रिय करा आणि परिणामी मार्ग आणि रिझोल्व्हर बदलांची मालकी त्या व्यवस्थापकाकडे ठेवा. NetworkManager आधीच कनेक्शन चालवत असताना दुसरा स्वतंत्र SSTP क्लायंट सुरू केल्यास तुम्हाला दोन मार्ग संच, दोन DNS कॉन्फिगरेशन आणि एकही सत्य स्रोत नसलेले डीबगिंग सत्र मिळते.

रहस्यांनाही मालक असतो. संपूर्ण सिस्टमसाठी वापर असे चिन्हांकित केलेले कनेक्शन क्रेडेन्शियल्स तुमच्या वापरकर्ता सत्रापुरत्याच मर्यादित कनेक्शनपेक्षा वेगळ्या पद्धतीने साठवते, आणि की-फाइलमध्ये हाताने तयार केलेले प्रोफाइल पासवर्ड परस्परसंवादी पद्धतीने देण्याची अपेक्षा असलेल्या रहस्य एजंटला वाचता येणार नाही. जो पासवर्ड कधीच समस्या नव्हता तो पुन्हा टाइप करण्यापूर्वी प्रोफाइल कोणत्या संदर्भाची अपेक्षा करते ते तपासा. तेच प्रोफाइल टर्मिनलवरून nmcli ने सक्रिय करणे ही सर्वात जलद चाचणी आहे, कारण कधीही न येणारा प्रॉम्प्ट सांगतो की एजंटकडे आधीच देण्यासारखे काही नव्हते.

बोगदा, मार्ग आणि रिझोल्व्हर वेगवेगळे तपासा

कनेक्टेड निर्देशक फक्त लिंक वर आली एवढेच सांगतो. तुम्हाला खरोखर आवश्यक असलेले गंतव्य, ते वाहणारा मार्ग आणि वापरातील रिझोल्व्हर एका वेळी एक तपासा; प्रत्येक चुकीचे असू शकते तर इतर दोन ठीक असतात.

अयशस्वी प्रयत्नासाठी प्रत्येक घटकाची आवृत्ती आणि स्वच्छ केलेला त्रुटी मजकूर नोंदवा. ते सामायिक करा, संपूर्ण प्रोफाइल नाही, कारण प्रोफाइलमध्ये पूर्व-सामायिक रहस्य आणि तुमची साठवलेली क्रेडेन्शियल्स असू शकतात.

शेवटी, डिस्कनेक्ट करा आणि पुन्हा कनेक्ट करा, नंतर एकदा रीबूट करा. प्रोफाइल फक्त पहिल्या प्रयत्नात काम करत असेल, तर समस्या रहस्य हाताळणीत किंवा मार्ग मालकीत आहे, आणि दोन्ही आता सुधारणे कामकाजाच्या दिवसाच्या मध्यात सुधारण्यापेक्षा स्वस्त आहे.