Linux पर SNX: 32-बिट लाइब्रेरीज़ और खुद को रीसेट करता रिज़ॉल्वर

Check Point का SSL Network Extender Linux पर चार पहचाने जाने योग्य तरीकों से विफल होता है, और उनमें से तीन को गलत तरीके से लॉगिन समस्या पढ़ा जाता है। या तो बाइनरी शुरू नहीं होती, या शुरू होकर कोई रूट नहीं छोड़ती, या जुड़ती है और नाम हल करना मर जाता है, या ब्राउज़र पोर्टल काम करता है जबकि कमांड लाइन नहीं। इन्हें उसी क्रम में करें, क्योंकि हर एक अगले के लिए प्रवेश-शर्त है।

लक्षण एक: लॉगिन से पहले लोडर मना करता है

फ़ायरवॉल से लिया गया इंस्टॉलर 32-बिट, setuid-root बाइनरी /usr/bin/snx पर छोड़ता है। 64-बिट डिस्ट्रिब्यूशन पर यह तब तक नहीं चलती जब तक i386 आर्किटेक्चर सक्षम न हो और जिन लाइब्रेरीज़ से यह लिंक होती है वे मौजूद न हों।

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

खाली not found सूची उसके बाद की हर चीज़ के लिए द्वार है। सटीक पैकेज सेट रिलीज़ के बीच बदलता है: एक काम करने वाली रिपोर्ट को libstdc++5:i386, libx11-6:i386 और libpam0g:i386 चाहिए थे, दूसरे को libstdc++6:i386 भी चाहिए था। किसी दूसरे डिस्ट्रिब्यूशन के लिए लिखे ट्यूटोरियल से पैकेज सूची कॉपी करने के बजाय ldd पढ़ें।

अगर snx बिल्कुल न मिले, तो इंस्टॉलर कभी पूरा नहीं हुआ या आपके PATH के बाहर कहीं इंस्टॉल हुआ। यह अलग विफलता है, और सिस्टम में आर्किटेक्चर जोड़ने से पहले इसे पुष्ट करना उचित है। command -v snx से जाँचें और उस डायरेक्टरी में देखें जिसकी जानकारी इंस्टॉलर ने दी। जिस मशीन में बाइनरी ही नहीं है वहाँ i386 पैकेज जोड़ने से कुछ ठीक नहीं होता।

लक्षण दो: लॉगिन सफल होता है और कुछ भी रूट नहीं होता

सफल लॉगिन tunsnx बनाता है और खुद रूटिंग टेबल संपादित करता है, इसलिए कुछ और बदलने से पहले जाँचें कि वास्तव में क्या मौजूद है।

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

तोड़ने के लिए snx -d इस्तेमाल करें। प्रोसेस मारने से इंटरफ़ेस और उसके रूट पीछे रह जाते हैं, और अगली कोशिश फिर ऐसे कारण से विफल होती है जिसका क्रेडेंशियल से कोई संबंध नहीं। पहला लॉगिन /etc/snx/ के अंतर्गत सर्वर हस्ताक्षर भी दर्ज करता है, इसीलिए एक बिना निगरानी वाली स्क्रिप्ट को काम करने से पहले एक इंटरैक्टिव रन की ज़रूरत पड़ सकती है। उस स्थिति को केवल तब हटाएँ जब आप सर्वर को फिर से स्वीकृत करना चाहते हों।

लक्षण तीन: सुरंग ऊपर आने तक नाम हल होते हैं

यही वह है जो चुपचाप टूटता है। snx धकेले गए DNS सर्वर सीधे /etc/resolv.conf में लिखता है। जहाँ वह पथ /run/systemd/resolve/ में एक प्रतीकात्मक लिंक है, वहाँ अगली रिज़ॉल्वर घटना में संपादन खो सकता है, और डिस्कनेक्ट के बाद धकेली गई प्रविष्टियाँ भी वैसे ही रह सकती हैं।

दो व्यवस्थाएँ काम करती हैं, और चुनाव पहले खोज परिणाम ने जो सुझाया वह नहीं, जानबूझकर होना चाहिए:

• फ़ाइल अपने हाथ में लें: प्रतीकात्मक लिंक को स्थिर फ़ाइल से बदलें और libnss-resolve तथा उसका i386 संस्करण इंस्टॉल करें, ताकि फ़ाइल के नीचे से फिर लिखे जाने पर भी नाम सेवा के पास विकल्प बना रहे।
• systemd-resolved को मालिक रखें और सुरंग लिंक दर्ज करें: resolvectl dns tunsnx 10.0.0.10, फिर resolvectl domain tunsnx corp.example, और resolvectl status से पुष्टि करें।

जुड़ने से पहले VPN-पूर्व नेमसर्वर लिख लें। अगर आप फ़ाइल हाथ से संपादित करते हैं, तो बाद में धकेली गई प्रविष्टियाँ हटाना प्रक्रिया का हिस्सा है, वैकल्पिक सफ़ाई नहीं, क्योंकि डिस्कनेक्ट के बाद कॉर्पोरेट DNS रखने वाला लैपटॉप और कुछ हल नहीं कर पाएगा।

लक्षण चार: पोर्टल काम करता है और CLI नहीं

हाल के फ़ायरवॉल रिलीज़ ने मिडलवेयर को ब्राउज़र से स्थानीय Java डेमॉन में स्थानांतरित कर दिया है, इसलिए पोर्टल पोर्ट 14186 पर स्थानीय एजेंट से बात करता है। उस पते को ब्राउज़र प्रमाणपत्र अपवाद और चल रही प्रोसेस चाहिए।

ps ax | grep cshell
/usr/bin/cshell/launcher

कमांड लाइन अलग मार्ग है: snx -s vpn.example.com -u user, जिसमें ~/.snxrc सर्वर, उपयोगकर्ता नाम और पुनः प्रमाणीकरण वरीयता रखता है। काम करता पोर्टल सत्र इस बारे में कुछ नहीं कहता कि CLI ठीक से इंस्टॉल है या नहीं, और सादा क्लाइंट एक बार उपयोग होने वाले कोड नहीं संभालता।

वह कंटेनर शॉर्टकट जो बचत से ज़्यादा खर्च करता है

snx tun मॉड्यूल जाँचता है, न हो तो लोड करता है, सुरंग इंटरफ़ेस बनाता है, रूट फिर से लिखता है और ट्रैफ़िक उससे गुज़ारता है। इसे कंटेनर के भीतर दोहराने का मतलब है /dev और /lib/modules माउंट करना और व्यापक क्षमताएँ देना, जो मेज़बान के नेटवर्क प्रशासन का बड़ा हिस्सा कंटेनर को सौंप देता है।

जब सैंडबॉक्स वास्तव में ज़रूरी हो, तो वर्चुअल मशीन अधिक साफ़ सीमा है: क्लाइंट को ऐसा कर्नेल मिलता है जिसे वह बदल सकता है, और मेज़बान अपनी रूट तालिका रखता है। जिन क्षमताओं को देकर आप पछताएँगे उन पर दोपहर बर्बाद करने से पहले यही चुनें।