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

Жинхэнэ элсэн хайрцаг шаардлагатай үед виртуал машин нь илүү цэвэр хил юм: клиент өөрөө өөрчилж болох цөмийг авдаг, хост өөрийн маршрутын хүснэгтийг хадгалдаг. Олгосондоо харамсах боломжуудад үдээс хойш цаг зарцуулахаас өмнө үүнийг сонгоорой.

Холбоотой нийтлэлүүд