SNX di Linux: pustaka 32-bit dan resolver yang mengatur ulang diri

SSL Network Extender dari Check Point gagal di Linux dengan empat cara yang dapat dikenali, dan tiga di antaranya salah dibaca sebagai masalah login. Entah binari tidak mau mulai, atau mulai tetapi tidak meninggalkan rute, atau tersambung lalu resolusi nama mati, atau portal peramban bekerja sementara baris perintah tidak. Kerjakan semuanya dalam urutan itu, karena masing-masing menjadi syarat masuk bagi berikutnya.

Gejala satu: pemuat menolak sebelum login

Pemasang yang diambil dari tembok api menaruh binari 32-bit dengan setuid-root di /usr/bin/snx. Pada distribusi 64-bit ia tidak berjalan sampai arsitektur i386 diaktifkan dan pustaka yang menjadi tujuan penautannya ada.

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"

Daftar not found yang kosong adalah gerbang bagi semua yang setelahnya. Himpunan paket yang tepat bergeser antar rilis: satu laporan yang berhasil membutuhkan libstdc++5:i386, libx11-6:i386, dan libpam0g:i386, laporan lain juga membutuhkan libstdc++6:i386. Bacalah ldd alih-alih menyalin daftar paket dari tutorial yang ditulis untuk distribusi lain.

Jika snx sama sekali tidak ditemukan, pemasang tidak pernah selesai atau memasang di suatu tempat di luar PATH Anda. Itu kegagalan yang berbeda, dan ada baiknya mengonfirmasinya sebelum menambahkan arsitektur ke sistem. Periksa dengan command -v snx dan lihat di direktori yang dilaporkan pemasang. Menambahkan paket i386 ke mesin yang binarinya memang tidak ada tidak memperbaiki apa pun.

Gejala dua: login berhasil dan tidak ada yang dirutekan

Login yang berhasil membuat tunsnx dan menyunting tabel rute sendiri, jadi periksa apa yang benar-benar ada sebelum mengubah hal lain.

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

Gunakan snx -d untuk membongkar. Membunuh proses meninggalkan antarmuka dan rutenya, dan percobaan berikutnya lalu gagal karena alasan yang tidak ada hubungannya dengan kredensial. Login pertama juga mencatat tanda tangan server di /etc/snx/, karena itu skrip tanpa pengawasan mungkin perlu satu jalankan interaktif sebelum bisa bekerja sama sekali. Hapus keadaan itu hanya ketika Anda berniat menyetujui server lagi.

Gejala tiga: nama terurai sampai terowongan naik

Inilah yang rusak diam-diam. snx menulis server DNS yang didorong langsung ke /etc/resolv.conf. Di tempat jalur itu berupa tautan simbolik ke /run/systemd/resolve/, suntingan bisa hilang pada peristiwa resolver berikutnya, dan setelah terputus entri yang didorong pun bisa sama-sama tertinggal.

Dua pengaturan berhasil, dan pilihannya harus disengaja, bukan sekadar yang disarankan hasil pencarian pertama:

• Ambil alih berkasnya: ganti tautan simbolik dengan berkas statis dan pasang libnss-resolve beserta varian i386-nya, agar layanan nama tetap punya cadangan ketika berkas ditulis ulang di bawahnya.
• Pertahankan systemd-resolved sebagai pemilik dan daftarkan tautan terowongan: resolvectl dns tunsnx 10.0.0.10, lalu resolvectl domain tunsnx corp.example, dan pastikan dengan resolvectl status.

Catat server nama sebelum VPN sebelum menyambung. Jika Anda menyunting berkas dengan tangan, menghapus entri yang didorong setelahnya adalah bagian dari prosedur, bukan pembersihan opsional, karena laptop yang menyimpan DNS korporat setelah terputus tidak akan bisa mengurai apa pun yang lain.

Gejala empat: portal bekerja dan CLI tidak

Rilis tembok api terbaru memindahkan middleware dari peramban ke daemon Java lokal, sehingga portal berbicara dengan agen lokal pada porta 14186. Alamat itu membutuhkan pengecualian sertifikat peramban dan proses yang berjalan.

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

Baris perintah adalah jalur terpisah: snx -s vpn.example.com -u user, dengan ~/.snxrc menyimpan server, nama pengguna, dan preferensi autentikasi ulang. Sesi portal yang bekerja tidak mengatakan apa pun tentang benar tidaknya CLI terpasang, dan klien telanjang tidak menangani kode sekali pakai.

Jalan pintas kontainer yang menghabiskan lebih banyak daripada menghemat

snx memeriksa modul tun, memuatnya jika tidak ada, membuat antarmuka terowongan, menulis ulang rute, dan mendorong lalu lintas melaluinya. Mereproduksi itu di dalam kontainer berarti memasang /dev dan /lib/modules serta memberi kemampuan luas, yang menyerahkan sebagian besar administrasi jaringan hos kepada kontainer.

Ketika kotak pasir benar-benar diperlukan, mesin virtual adalah batas yang lebih bersih: klien mendapat kernel yang boleh ia ubah, dan hos tetap menyimpan tabel rutenya. Pilih itu sebelum menghabiskan sore pada kemampuan yang akan Anda sesali berikan.