SNX pada Linux: pustaka 32-bit dan penyelesai yang menetap semula

SNX pada Linux gagal pada pemuat, jadual laluan atau penyelesai, dan setiap kegagalan kelihatan seperti masalah log masuk. Kerjakan empat simptom itu mengikut urutan.

SSL Network Extender daripada Check Point gagal pada Linux dalam empat cara yang boleh dikenali, dan tiga daripadanya disalah baca sebagai masalah log masuk. Sama ada binari tidak bermula, atau ia bermula dan tidak meninggalkan laluan, atau ia bersambung dan penyelesaian nama mati, atau portal pelayar berfungsi manakala baris arahan tidak. Kerjakan semuanya dalam urutan itu, kerana setiap satu ialah syarat masuk bagi yang berikutnya.

Simptom satu: pemuat menolak sebelum log masuk

Pemasang yang diambil daripada tembok api meletakkan binari 32-bit dengan setuid-root di /usr/bin/snx. Pada edaran 64-bit ia tidak berjalan sehingga seni bina i386 diaktifkan dan pustaka yang dipautnya wujud.

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"

Senarai not found kosong ialah pintu bagi semua yang berikutnya. Set pakej tepat berubah antara keluaran: satu laporan yang berjaya memerlukan libstdc++5:i386, libx11-6:i386 dan libpam0g:i386, satu lagi turut memerlukan libstdc++6:i386. Baca ldd dan jangan salin senarai pakej daripada tutorial yang ditulis untuk edaran lain.

Jika snx langsung tidak dijumpai, pemasang tidak pernah selesai atau dipasang di suatu tempat di luar PATH anda. Itu kegagalan yang berbeza, dan wajar disahkan sebelum anda menambah seni bina pada sistem. Semak dengan command -v snx dan lihat dalam direktori yang dilaporkan oleh pemasang. Menambah pakej i386 pada mesin yang binarinya memang tiada tidak membaiki apa-apa.

Simptom dua: log masuk berjaya dan tiada apa yang dilalui

Log masuk yang berjaya mencipta tunsnx dan menyunting jadual laluan sendiri, jadi semak apa yang benar-benar wujud sebelum menukar apa-apa yang lain.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Gunakan snx -d untuk membongkar. Membunuh proses meninggalkan antara muka dan laluannya, dan percubaan seterusnya kemudian gagal atas sebab yang tiada kaitan dengan kelayakan. Log masuk pertama juga merekodkan tandatangan pelayan di bawah /etc/snx/, sebab itulah skrip tanpa pengawasan mungkin memerlukan satu larian interaktif sebelum ia boleh berfungsi langsung. Padam keadaan itu hanya apabila anda berniat untuk meluluskan pelayan semula.

Simptom tiga: nama diselesaikan sehingga terowong naik

Inilah yang rosak secara senyap. snx menulis pelayan DNS yang ditolak terus ke dalam /etc/resolv.conf. Di mana laluan itu ialah pautan simbolik ke /run/systemd/resolve/, suntingan boleh hilang pada peristiwa penyelesai seterusnya, dan selepas terputus entri yang ditolak juga boleh kekal.

Dua susunan berfungsi, dan pilihan itu haruslah sengaja dan bukan apa yang dicadangkan oleh hasil carian pertama:

  • Ambil alih fail itu: gantikan pautan simbolik dengan fail statik dan pasang libnss-resolve serta varian i386-nya, supaya perkhidmatan nama masih mempunyai sandaran apabila fail itu ditulis semula di bawahnya.
  • Kekalkan systemd-resolved sebagai pemilik dan daftarkan pautan terowong: resolvectl dns tunsnx 10.0.0.10, kemudian resolvectl domain tunsnx corp.example, dan sahkan dengan resolvectl status.

Catat pelayan nama sebelum VPN sebelum menyambung. Jika anda menyunting fail itu dengan tangan, membuang entri yang ditolak selepas itu ialah sebahagian daripada prosedur, bukan pembersihan pilihan, kerana komputer riba yang menyimpan DNS korporat selepas terputus tidak akan dapat menyelesaikan apa-apa yang lain.

Simptom empat: portal berfungsi dan CLI tidak

Keluaran tembok api terkini telah memindahkan perisian tengah daripada pelayar ke daemon Java setempat, jadi portal bercakap dengan ejen setempat pada port 14186. Alamat itu memerlukan pengecualian sijil pelayar dan proses yang berjalan.

ps ax | grep cshell
/usr/bin/cshell/launcher

Baris arahan ialah laluan berasingan: snx -s vpn.example.com -u user, dengan ~/.snxrc menyimpan pelayan, nama pengguna dan keutamaan pengesahan semula. Sesi portal yang berfungsi tidak mengatakan apa-apa tentang sama ada CLI dipasang dengan betul, dan klien kosong tidak mengendalikan kod sekali guna.

Jalan pintas kontena yang menelan lebih banyak daripada yang dijimatkan

snx memeriksa modul tun, memuatnya apabila tiada, mencipta antara muka terowong, menulis semula laluan dan menolak trafik melaluinya. Menghasilkannya semula di dalam kontena bermakna memasang /dev dan /lib/modules serta memberi keupayaan luas, yang menyerahkan sebahagian besar pentadbiran rangkaian hos kepada kontena.

Apabila kotak pasir benar-benar diperlukan, mesin maya ialah sempadan yang lebih bersih: klien mendapat kernel yang boleh diubahnya, dan hos mengekalkan jadual laluannya. Pilih itu sebelum anda menghabiskan petang pada keupayaan yang akan anda sesali memberi.

Artikel berkaitan