ARM बिल्ड तपाईंको Raspberry Pi का लागि FortiClient समर्थन होइन

Raspberry Pi मा VPN क्लाइन्ट चलाउनु त्यसमा FortiClient समर्थित हुनुसँग एउटै कुरा होइन। यो कुराकानीमा तीन दाबी मिसिन्छन्: विक्रेताले प्लेटफर्मलाई योग्य ठहराउँछ, कसैले प्रोसेसरका लागि बाइनरी बनाउँछ, र गेटवेले त्यो क्लाइन्टको प्रोटोकल र दर्ता अनुमति दिन्छ। तीनमध्ये एउटा भेट्टाउँदा अरू दुईबारे केही थाहा हुँदैन। यिनलाई यही क्रममा गर्नुहोस् र एउटा असफल भएपछि रोक्नुहोस्, किनकि त्यही तपाईंले समाधान गर्नुपर्ने हो।

पहिलो चरण: तपाईंको ठ्याक्कै प्याकेजको रिलिज नोट पङ्क्ति पढ्नुहोस्

समर्थनका कथन संस्करणसँग बाँधिएका हुन्छन्, त्यसैले तपाईंको संस्थाले स्वीकृत गर्ने प्याकेजको रिलिज नोटबाट सुरु गर्नुहोस्। ठोस उदाहरणका लागि, FortiClient Standalone 7.4.7 को तालिकाले GNOME सहित Ubuntu 22.04 र 24.04, Red Hat 9 र CentOS Stream 9 सूचीबद्ध गर्छ। यसको Linux प्रोसेसर आवश्यकता Intel वा समकक्ष भनी लेखिएको छ।

Raspberry Pi OS ती सूचीबद्ध Linux वातावरणमध्ये एक होइन। यो हरेक FortiClient संस्करणबारे फैसला वा पछिका रिलिजबारे भविष्यवाणी होइन; यो त्यो कागजातको त्यो पङ्क्तिबारे कथन हो। तपाईंले साँच्चै तैनाथ गर्न चाहेको संस्करणको म्याट्रिक्स पढ्नुहोस्।

Windows वा macOS पङ्क्तिका प्रोसेसर नोट Linux पङ्क्तिमा नसार्नुहोस्। विक्रेताहरूले प्लेटफर्मलाई प्रत्येक संस्करण र प्रत्येक रिलिजअनुसार अभिलेख गर्छन्, र एउटा पङ्क्तिमा लागू हुने नोट अर्कोका लागि प्रमाण होइन।

दोस्रो चरण: Pi ले के चलाइरहेको छ भनी पुष्टि गर्नुहोस्

कुनै पनि डाउनलोडअघि तीन आदेशले स्थानीय तथ्यहरू टुंगो लगाउँछन्:

uname -m
cat /etc/os-release
dpkg --print-architecture

पहिलोले कर्नेल आर्किटेक्चर बताउँछ, दोस्रोले वितरण र रिलिज, र तेस्रोले प्याकेज बनाइने प्रयोगकर्ता-स्थान आर्किटेक्चर। 64-बिट कर्नेलसँग 32-बिट प्रयोगकर्ता-स्थान सम्भव छ, र यसले तपाईंलाई कुन प्याकेज चाहिने बदल्छ।

त्यसपछि त्यो प्लेटफर्मका लागि साँच्चै के उपलब्ध छ जाँच्नुहोस्। Debian trixie को प्रकाशित प्याकेज तालिकामा openfortivpn का arm64 र armhf बिल्ड छन्। यसले त्यो वितरणमा आर्किटेक्चरको उपलब्धता स्थापित गर्छ। यसले Fortinet ले कुनै व्युत्पन्नमा FortiClient योग्य ठहराउँछ भनी वा तपाईंको संस्थाको गेटवेले क्लाइन्ट स्वीकार्छ भनी स्थापित गर्दैन।

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

तेस्रो चरण: क्लाइन्टलाई दोष दिनुअघि गेटवे जाँच्नुहोस्

Upstream ले openfortivpn लाई pppd सुरु गर्ने PPP र TLS क्लाइन्ट भनी वर्णन गर्छ। त्यो विशिष्ट कार्यान्वयन हो, र यसलाई गेटवेले मिल्दो मोड दिनु आवश्यक छ। सर्भरको ब्रान्ड नाम प्रोटोकल सम्झौता होइन।

गेटवेको रिलिज र सक्रिय गरिएको पहुँच विधि, स्वीकृत होस्टनाम र यसको विश्वास सामग्री, र सेवाले माग्ने पहिचान कार्यप्रवाह सङ्कलन गर्नुहोस्, जसमा कुनै पनि दोस्रो कारक र यन्त्र स्थिति जाँच समावेश छ। व्यवस्थापित तैनाथीलाई तेस्रो-पक्ष क्लाइन्टले गर्ने उपाय नभएका दर्ता चरणहरू आवश्यक पर्न सक्छ।

तपाईंलाई जारी गरिएको खाताबाट जडान प्रयास गर्नुहोस्, प्रशासकको खाताबाट होइन, किनकि दर्ता र नीति सामान्यतया प्रयोगकर्तासँग जोडिन्छन्:

sudo openfortivpn vpn.example.com:443 -u <username>

केवल एक्जिट कोड होइन, असफलता पढ्नुहोस्। प्रमाणपत्र त्रुटि, PPP टाइमआउट र नीति अस्वीकृति तीन फरक समस्या हुन्, र तीमध्ये एउटा मात्र ARM बारे हो।

चौथो चरण: सम्झौताभित्रै यन्त्रमा स्वीकार गर्नुहोस्

वास्तविक निजी स्रोत, सुरुङमार्फत DNS समाधान, र सञ्जाल टुटेपछि पुनः जडानसहित सेटअप स्वीकार गर्नुहोस्। त्यसपछि अगम्य रहनुपर्ने गन्तव्य अझै असफल हुन्छ भनी पुष्टि गर्नुहोस्, किनकि पुग्न सक्नु मात्र नीति सही भएको प्रमाण होइन।

चार तथ्य एकैसाथ लेख्नुहोस्: OS रिलिज, प्रयोगकर्ता-स्थान आर्किटेक्चर, क्लाइन्ट प्याकेज संस्करण, र गेटवे मोड। चारै नभएपछि अर्को व्यक्तिले सेटअप समर्थित हो वा मात्र चलिरहेको हो भन्न सक्दैन।

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