Linux मा Check Point VPN: SNX डाउनलोड गरेर इन्स्टल गर्ने कुरा होइन

तपाईं Check Point को Linux क्लाइन्ट खोज्नुहुन्छ र इन्स्टलर भएको कुनै डाउनलोड पृष्ठ भेट्नुहुन्न। त्यो अनुपस्थिति प्याकेजिङको खाडल होइन। Check Point को Linux रिमोट-एक्सेस क्लाइन्ट SSL Network Extender, अर्थात् SNX हो, र ब्राउजरमा तपाईंको पहिचान प्रमाणित भएपछि गेटवेले त्यो तपाईंलाई दिन्छ। यो कुरा मिलेपछि बाँकी अलमलको पनि अर्थ हुन्छ, यसबारे लगभग हरेक लेख वर्षौं पुरानो किन हुन्छ भन्ने पनि।

भ्रम: डाउनलोड गरेर इन्स्टल गर्ने क्लाइन्ट हुन्छ

यो अपेक्षा अरू हरेक विक्रेताबाट आउँछ। OpenVPN, WireGuard र अधिकांश व्यावसायिक क्लाइन्टले प्याकेज वा रिपोजिटरी प्रकाशित गर्छन्, र एउटा इन्स्टल गर्नु तपाईं एक्लैले लिने स्थानीय निर्णय हो। Linux मा Check Point त्यसरी काम गर्दैन। हालका गेटवे संस्करणका आधिकारिक डाउनलोडमा छुट्टै इन्स्टलर छैन, त्यसैले त्यो खोज्दा पुराना फोरम थ्रेड र तेस्रो-पक्षका मिरर मात्र भेटिन्छन्।

ती मिरर निरर्थकभन्दा पनि नराम्रा हुन्, किनकि बिल्ड त्यसलाई सेवा गर्ने गेटवेसँग मिल्नुपर्छ।

SNX वास्तवमा के हो, र कहाँबाट आउँछ

SNX एउटा कमाण्ड-लाइन क्लाइन्ट हो जसको बाइनरी snx हो, र यो ब्राउजरमा गेटवेविरुद्ध तपाईंले सुरु गर्ने सत्रमार्फत इन्स्टल हुन्छ। ऐतिहासिक रूपमा Java एप्लेटले तपाईंले सूचना स्वीकार गरेपछि त्यसलाई डाउनलोड र इन्स्टल गर्थ्यो। वर्षौंमा विधि बदलियो, स्रोत बदलिएन। गेटवे आफैंसँग मिल्ने बिल्ड नै दिन्छ, त्यसैले क्लाइन्ट र गेटवेका संस्करण सँगै जान्छन्, र त्यसैले पुरानो प्याकेजबाट कपी गरिएको क्लाइन्ट गेटवे त्यससँग बोल्दासम्म मात्र चल्छ।

यसको अर्थ क्लाइन्टमा गरिने कुनै पनि कामको अर्थ हुनुअघि गेटवे तयार हुनुपर्छ। Mobile Access Software Blade लाई इजाजतपत्र र कन्फिगरेसन चाहिन्छ, किनकि त्यो बिना इन्स्टल गर्ने पोर्टल हुँदैन। पोर्टल नदिने गेटवेविरुद्ध क्लाइन्ट पक्षको कुनै पनि प्रयासले सत्र बनाउँदैन।

तपाईंको प्रयोगकर्तासहित क्लाइन्टलाई गेटवेतिर फर्काउनुहोस्, र यसले के रिपोर्ट गर्छ पढ्नुहोस्:

snx -s vpn.example.com -u your.name

सीमा इन्स्टलर होइन, डिस्ट्रिब्युसन समर्थन हो

SNX का लागि विक्रेताको समर्थित डिस्ट्रिब्युसनको सूची छोटो र पुरानो छ। प्रकाशित लेखमा यो करिब Ubuntu 17.04 मा रोकिन्छ, त्यही युगका केही openSUSE, Fedora र RHEL संस्करणसँगै, र अझै पनि Ubuntu 12.10 सूचीबद्ध गर्छ। यसले सूची कसरी पुरानो हुन्छ भन्ने बताउँछ, तपाईंको मेसिनलाई के चाहिन्छ भन्ने होइन। हालको डिस्ट्रिब्युसन त्यसमा छँदै छैन।

चल्ने टनेलको अपेक्षा गर्नुअघि लाइब्रेरी अमिलको अपेक्षा गर्नुहोस्। सामान्य तीन भनेको 64 बिट प्रणालीमा हराएका 32 बिट लाइब्रेरी, बाइनरी कहिल्यै लिङ्क नभएको OpenSSL संस्करण, र क्लाइन्टले बनाउन खोज्ने कर्नेल मोड्युल हुन्। प्याकेज अनुमान गर्नुको सट्टा हराएका प्रतीक पढ्नुहोस्:

ldd $(command -v snx) | grep "not found"

त्यसपछि तपाईं वास्तवमै जोडिने गेटवे संस्करणको समर्थन लेख हेर्नुहोस्। ब्लगको सूची अनुकूलताको वक्तव्य होइन, र नयाँ डिस्ट्रिब्युसनको अर्थ नयाँ क्लाइन्ट होइन।

स्क्रिन बिना काम सम्भव बनाउने X11 विवरण

SNX लाई X11 लाइब्रेरी चाहिन्छ, तर चलिरहेको X सर्भर चाहिँदैन। त्यो भिन्नता नै हेडलेस होस्टमा SSH मार्फत चल्ने क्लाइन्ट र कुनै आउटपुट बिना अड्किएजस्तो देखिने क्लाइन्टबीचको सम्पूर्ण फरक हो। अर्को संस्करणबाट कपी गरिएको बन्डल होइन, तपाईंको डिस्ट्रिब्युसनले दिने लाइब्रेरी प्याकेज इन्स्टल गर्नुहोस्, र टनेल चाहिने सत्रबाटै क्लाइन्ट चलाउनुहोस्।

जोडिएपछि,इन्टरफेस र रुट दुवैमा विश्वास गर्नुअघि ती पढ्नुहोस्:

ip -brief addr show
ip route show

SNX ले टनेल इन्टरफेस बनाउँछ र पोर्टलले तोकेका रुट इन्स्टल गर्छ। ती रुट तपाईंका होइनन्, गेटवेको निर्णय हुन्, त्यसैले हराएको प्रिफिक्स क्लाइन्टको बग होइन, गेटवे पक्षको प्रोफाइल समस्या हो। सँगै DNS जाँच्नुहोस्, किनकि split-tunnel प्रोफाइलले प्रायः तपाईंले नसोचेको रिजोल्भर धकेल्छ।

जब SNX पूर्ण रूपमा गलत उत्तर हुन्छ

Check Point गेटवेले IPsec रL2TPक्लाइन्ट-देखि-साइट जडान पनि अन्त्य गर्न सक्छन्, र ती strongSwan, Libreswan वा NetworkManager को L2TP प्लगइनसँग चल्छन्। त्यो गेटवे कन्फिगरेसन हो, क्लाइन्टको चाल होइन। यदि गेटवेले मात्र Mobile Access पोर्टल प्रकाशित गर्छ भने,IPsec क्लाइन्टसँग वार्ता गर्न केही हुँदैन, र लगमा प्रमाणीकरण असफलताको सट्टा टाइमआउट देखिन्छ। अरू केही इन्स्टल गर्नुअघि कुन रिमोट-एक्सेस ब्लेड सक्षम छन् सोध्नुहोस्।

यहाँको हरेक सीमा गेटवे पक्षमा बस्छ: ब्लेड, इजाजतपत्र, क्लाइन्ट बिल्ड र रुट प्रोफाइल। CLI वर्षौंदेखि चलिरहेको छ। जे भाँचिन्छ त्यो Linux समर्थनको अर्थ तपाईंको स्वामित्व र नियन्त्रणको प्याकेज हो भन्ने धारणा हो।