Fortinet Linux क्लाइन्ट: मर्मत गर्नुअघि गेटवे जाँच गर्नुहोस्
अभिलेखित Linux मार्गदर्शनले पुस्तकालयहरू मर्मत गर्छ; गेटवेले हटाएको टनेल मोड यसले फिर्ता ल्याउन सक्दैन। रिलिजको सीमा, क्लाइन्ट, त्यसपछि स्थानीय चरण जाँच गर्नुहोस्।
अभिलेखित मार्गदर्शनले 32-बिट पुस्तकालय स्थापना गर्न, GTK थिम प्याच गर्न र टर्मिनलबाट इन्स्टलर चलाउन भन्छ। त्यो सल्लाको केही भाग निश्चित क्लाइन्ट रिलिजका लागि सही थियो, र त्यसमध्ये केहीले पनि गेटवेले अब नदिने टनेल मोड फिर्ता ल्याउन सक्दैन। प्याकेज बदल्नुअघि असफल भएको पहिलो चरण खोज्नुहोस्। यो गेटवेबाट भित्रतिर जान्छ, किनकि त्यहाँ उत्तरहरू सस्तो हुन्छन् र गलत स्थानीय सुधारले सबैभन्दा बढी समय लिन्छ।
जाँच 1: असफल भएको चरणको नाम दिनुहोस्
तीन चरण फरक तरिकाले असफल हुन्छन्। कार्यक्रम सुरु हुँदैन, सुरु भएर सर्भरको पहिचान अस्वीकार गर्छ, वा जोडिन्छ र गेटवेमा तपाईंलाई चाहिने प्रकारको सेवा हुँदैन। हरेक असफलताले आफ्नै प्रमाण छोड्छ: लोडर त्रुटि, प्रमाणपत्र सन्देश, उपलब्ध नभएको मोडको नाम दिने गेटवेको जवाफ।
केही छुनुअघि यो लेख्नुहोस्। यो बिन्दुपछिको सबै तपाईंले कुन चरणको नाम दिनुभयो त्यसमा निर्भर छ, र तीन सुधारमा केही समान छैन।
जाँच 2: गेटवेको रिलिज र टनेल मोड
हालका गेटवेहरूमा टनेल मोड गइसक्यो, र FortiClient 7.4.4 को Linux एकीकरण तालिका त्यो लेखिएको ठाउँ हो: FortiOS 7.6.3 र त्यसपछिका संस्करणहरूले अब SSL VPN टनेल मोड दिँदैनन् र प्रशासकहरूलाई IPsec तिर पठाउँछन्। त्यो वाक्य दोहोर्याउँदा उत्पादन, रिलिज र मोड त्यसमै जोडेर राख्नुहोस्। यसले हरेक Fortinet उत्पादनबारे केही भन्दैन, र अझै रहेका वेब-पहुँच सुविधाबारे पनि केही भन्दैन। सामान्य संस्करण अनुकूलता र एउटा टनेल मोडको उपलब्धता छुट्टाछुट्टै जाँच हुन्।
गेटवेको मालिकलाई दुई कुरा सोध्नुहोस्: गेटवे कुन रिलिज चलाउँछ, र आज कुन पहुँच विधि सक्षम छन्। जवाफ लिखित रूपमा माग्नुहोस्, रिलिज स्ट्रिङ र त्यो आएको सेटिङ पृष्ठ वा कन्फिगरेसन लाइनसहित, किनकि मौखिक आश्वासनले नै मानिसहरूलाई अभिलेखित मार्गदर्शनतिर फर्काउँछ। त्यसपछि त्यो जवाफलाई ठ्याक्कै त्यही रिलिजका लागि गेटवेका टिप्पणी वा विक्रेताको म्याट्रिक्ससँग जाँच्नुहोस्। वेब पोर्टल देखाउने ब्राउजरले पोर्टल प्रतिक्रिया दिन्छ भन्ने प्रमाण दिन्छ, त्यसभन्दा बढी केही होइन।
जाँच 3: मालिकले स्वीकृत गर्ने क्लाइन्ट संस्करण
स्वीकृत Linux क्लाइन्ट संस्करण र भर्सन लिनुहोस्, त्यसपछि यसले समर्थन गर्ने अपरेटिङ सिस्टम, आर्किटेक्चर, डेस्कटप र प्रमाणीकरण प्रवाह जाँच्नुहोस्। 7.4.4 म्याट्रिक्स संस्करणसँग बाँधिएको उदाहरण हो, नयाँ क्लाइन्टका लागि सिफारिस होइन र हरेक व्युत्पन्नका लागि वाचा पनि होइन। मालिकले वास्तवमा कुन क्लाइन्ट समर्थन गर्नेछ भनी सोध्नुहोस्, किनकि त्यो जवाफ स्थानान्तरणको भाग हो, पछिको विचार होइन। आफ्नो पहिलो प्याकेट गेटवेमा पुग्नुअघि मर्ने क्लाइन्टले ल्यापटपबारे केही प्रमाण दिन्छ, सेवाबारे होइन।
32-बिट पुस्तकालय र प्याच गरिएको थिमले बाइनरीले के लोड गर्न सक्छ भन्ने बदल्छ; विक्रेताले के समर्थन गर्छ भन्ने बदल्दैन। यदि अपरेटिङ सिस्टम वा प्रमाणीकरण प्रवाह म्याट्रिक्सबाहिर छ भने, योग्यताको प्रश्न पहिले नै उत्तरित छ।
जाँच 4: प्रतिस्थापन प्रोफाइल माग्नुहोस्
यदि संस्था SSL VPN टनेल मोडबाट IPsec तिर सरेको छ भने, नयाँ प्रोफाइल र दर्ता प्रक्रिया त्यही कुराकानीमा माग्नुहोस्। SSL कन्फिगरेसनको नाम फेरेर फिल्डहरू सर्छन् भनी नमान्नुहोस्: IPsec प्रोफाइलले IKE संस्करण, टाढाको गेटवे र त्यसको पहिचान, प्रमाणीकरण विधि, र हरेक पक्षले स्वीकार गर्ने ट्राफिक चयनकर्ता बताउँछ। खाता र यन्त्र नीति पनि फरक तरिकाले लागू हुन सक्छ। नाम फेर्दा कन्फिगर गरिएको देखिने तर केही पनि वार्ता नगर्ने क्लाइन्ट बन्छ।
प्रोफाइलमा विश्वास गर्नुअघि पढ्नुहोस्। यसमा IKE संस्करण र प्रस्तावहरू, प्रमाणीकरणले प्रमाणपत्र वा पहिले साझा गरिएको कुञ्जी प्रयोग गर्छ कि, कुन स्थानीय र टाढाका सबनेट छानिएका छन्, र गेटवेले आफ्नो पहिचानका रूपमा के अपेक्षा गर्छ भन्ने हुनुपर्छ। स्वीकृत Linux क्लाइन्टले त्यो व्यवस्था समर्थन गर्छ भनी पुष्टि गर्नुहोस्, किनकि स्थानान्तरण कागजात हरेक क्लाइन्ट रिलिजका लागि सुविधा समानताको घोषणा होइन। openfortivpn जस्तो स्वतन्त्र क्लाइन्ट OpenVPN को अनुवादक होइन, त्यसैले नाममा SSL भएको अरू जुनसुकैलाई मालिकले यो मोड, यो लगइन प्रवाह र यो यन्त्र नीतिका लागि अरू नभनुन्जेल अस्वीकृत मान्नुहोस्।
जाँच 5: स्थानीय निर्भरता, त्यसपछि प्रमाणित गरी अभिलेख गर्नुहोस्
गेटवे र क्लाइन्ट टुंगिएपछि, सुरु नहुनु प्याकेजिङ समस्या हो, र मर्मत गरिएको प्याकेजका आफ्नै निर्देशनहरू नै पालना गर्नुपर्ने सन्दर्भ हुन्। TLS पहिचान असफलता अपरेटरको हो: विश्वास एङ्कर र अपेक्षित नाम उसको कन्फिगरेसन हो, स्थानीय रूपमा छल्ने कुरा होइन। अभिलेखित मार्गदर्शन कहिल्यै उपयोगी भएका दुई चरण यिनै हुन्।
अज्ञात प्रमाणपत्र स्वीकार गरेर वा यन्त्र स्थिति जाँच बन्द गरेर दुवैमध्ये कुनै पनि समाधान हुँदैन। MFA र यन्त्र जाँच ठाउँमै राख्नुहोस्, किनकि तिनलाई कमजोर बनाएर जडान फर्काउनु अवरोधको सट्टा घटना किन्नु हो। मोड गइसक्यो भने, कुनै स्थानीय फ्ल्यागले त्यो फर्काउँदैन।
स्वीकृत परिवर्तनपछि इच्छित निजी स्रोतमा पुग्नुहोस्, DNS समाधान पुष्टि गर्नुहोस् र एकपटक फेरि जोडिनुहोस्। क्लाइन्ट, प्लेटफर्म, गेटवे रिलिज र टनेल मोड सँगै अभिलेख गर्नुहोस्, किनकि अर्को व्यक्तिलाई चारै चाहिन्छ। सफलतापूर्वक खुल्ने कार्यक्रमले स्थानीय सुरुवाती चरण पार गरेको हो, त्यसभन्दा बढी केही होइन।