Linux میں SNX: 32-بٹ لائبریریاں اور خود کو ری سیٹ کرنے والا حل کنندہ
Linux میں SNX لوڈر، روٹ ٹیبل یا حل کنندہ پر ناکام ہوتا ہے، اور ہر ناکامی لاگ ان مسئلے جیسی نظر آتی ہے۔ چار علامات ترتیب سے نمٹیں۔
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 ماؤنٹ کرنا اور وسیع صلاحیتیں دینا، جو میزبان کی نیٹ ورک انتظامیہ کا بڑا حصہ کنٹینر کو دے دیتا ہے۔
جب واقعی سینڈ باکس درکار ہو تو ورچوئل مشین زیادہ صاف حد ہے: کلائنٹ کو وہ کرنل ملتا ہے جسے وہ بدل سکتا ہے، اور میزبان اپنا روٹ ٹیبل رکھتا ہے۔ جن صلاحیتوں کو دے کر پچھتائیں گے ان پر دوپہر گزارنے سے پہلے یہی چنیں۔