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-ը և տրամադրել լայն հնարավորություններ, ինչը կոնտեյներին է հանձնում հոսթի ցանցային կառավարման մեծ մասը։

Երբ ավազարկղն իսկապես անհրաժեշտ է, վիրտուալ մեքենան ավելի մաքուր սահման է. հաճախորդը ստանում է միջուկ, որը կարող է փոփոխել, իսկ հոսթը պահում է իր երթուղիների աղյուսակը։ Ընտրեք դա նախքան կեսօր ծախսելը հնարավորությունների վրա, որոնք կզղջաք, որ տվել եք։