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 кошуу жана кеңири мүмкүнчүлүктөрдү берүү дегенди билдирет, бул хосттун тармактык администрациялоосунун көбүн контейнерге берет.

Чынында кум салынган кутуча керек болгондо, виртуалдык машина таза чек: кардар өзү өзгөртө алган ядро алат, ал эми хост өзүнүн маршрут таблицасын сактайт. Бергениңизге өкүнө турган мүмкүнчүлүктөргө түштөн кийинки убакытты жумшаардан мурун ошону тандаңыз.

Тектеш макалалар