Linux पर लॉगिन से पहले SSTP विफल? रनटाइम हिस्सों की जाँच करें

आप SSTP प्लगइन इंस्टॉल करते हैं, नेटवर्क संपादक में रेडियो बटन दिखता है, आप गेटवे और उपयोगकर्ता नाम भरते हैं, और प्रोफ़ाइल पासवर्ड माँगने से पहले ही सामान्य त्रुटि के साथ विफल हो जाती है। इस क्रम में कुछ भी असामान्य नहीं है, और इसमें कुछ भी यह साबित नहीं करता कि सुरंग सॉफ़्टवेयर इंस्टॉल है। SSTP कनेक्शन अलग-अलग भेजे जाने वाले हिस्सों से जोड़ा जाता है: एक VPN प्लगइन जिसे NetworkManager शुरू कर सकता है, वह SSTP क्लाइंट प्रोग्राम जो TLS और PPP सत्र रखता है, उसके नीचे 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 के साथ सक्रिय करना सबसे तेज़ परीक्षण है, क्योंकि जो संकेत कभी नहीं आता वह बताता है कि एजेंट के पास पहले से देने को कुछ नहीं था।

सुरंग, रूट और रिज़ॉल्वर अलग-अलग जाँचें

कनेक्टेड संकेतक केवल यह दावा करता है कि लिंक ऊपर आया। आपको वास्तव में जो गंतव्य चाहिए, उसे ले जाने वाला रूट, और उपयोग में रिज़ॉल्वर एक-एक करके जाँचें; हर एक गलत हो सकता है जबकि बाकी दो ठीक हों।

विफल प्रयास के लिए हर घटक का संस्करण और साफ़ किया गया त्रुटि पाठ दर्ज करें। वही साझा करें, पूरी प्रोफ़ाइल नहीं, क्योंकि प्रोफ़ाइल में पूर्व-साझा रहस्य और आपके संग्रहित क्रेडेंशियल हो सकते हैं।

अंत में, डिस्कनेक्ट करें और फिर से कनेक्ट करें, फिर एक बार रीबूट करें। अगर प्रोफ़ाइल केवल पहले प्रयास में काम करती है, तो समस्या रहस्य प्रबंधन में या रूट स्वामित्व में है, और दोनों को अब ठीक करना कार्यदिवस के बीच में करने से सस्ता है।