तुम्ही 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 समर्थन म्हणजे तुमच्या मालकीचे आणि नियंत्रणातले पॅकेज असते हा गैरसमज.

संबंधित लेख