SNX په Linux کې: 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 مونټ کړئ او پراخې وړتیاوې ورکړئ، چې د کوربه د شبکې اداره ډېره برخه کانټینر ته سپاري۔

کله چې واقعاً سندباکس ته اړتیا وي، مجازي ماشین پاکه پوله ده: کلاینټ هغه کرنل ترلاسه کوي چې بدلولی شي، او کوربه خپل د لارې جدول ساتي۔ دا غوره کړئ مخکې له دې چې د هغو وړتیاوو لپاره ماسپښین تیر کړئ چې ورکول به یې پښېمانه یاست۔