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 प्रयोग गरी सक्रिय गर्नु सबैभन्दा छिटो परीक्षण हो, किनकि कहिल्यै नआउने प्रम्प्टले एजेन्टसँग पहिले नै दिने कुरा केही नभएको बताउँछ।

सुरुङ, मार्ग र रिजोल्भर अलग-अलग जाँच्नुहोस्

जडान भएको सूचकले लिङ्क माथि आयो भन्ने मात्र दाबी गर्छ। तपाईंलाई साँच्चै चाहिने गन्तव्य, त्यसलाई बोक्ने मार्ग र प्रयोगमा रहेको रिजोल्भर एक-एक गरी जाँच्नुहोस्; प्रत्येक गलत हुन सक्छ जब बाँकी दुई ठीक हुन्छन्।

असफल प्रयासका लागि प्रत्येक कम्पोनेन्टको संस्करण र सफा गरिएको त्रुटि पाठ रेकर्ड गर्नुहोस्। ती साझा गर्नुहोस्, पूरा प्रोफाइल होइन, किनकि प्रोफाइलमा पहिले साझा गरिएको गोप्य कुरा र तपाईंका भण्डारण गरिएका प्रमाणहरू हुन सक्छन्।

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