Linux'ta SNX: 32 bit kütüphaneler ve kendini sıfırlayan bir çözümleyici

SNX Linux'ta yükleyicide, yönlendirme tablosunda veya çözümleyicide başarısız olur ve her biri oturum açma sorunu gibi görünür. Dört belirtiyi sırayla ele alın.

Check Point'in SSL Network Extender'ı Linux'ta dört tanınabilir şekilde başarısız olur ve bunlardan üçü yanlışlıkla oturum açma sorunu olarak okunur. Ya ikili dosya başlamaz, ya başlar ve hiçbir yol bırakmaz, ya bağlanır ve ad çözümlemesi ölür, ya da tarayıcı portalı çalışırken komut satırı çalışmaz. Bunları bu sırayla ele alın, çünkü her biri bir sonrakinin giriş koşuludur.

Belirti bir: yükleyici oturum açmadan önce reddeder

Güvenlik duvarından alınan kurulum programı 32 bit, setuid-root bir ikili dosyayı /usr/bin/snx konumuna bırakır. 64 bit bir dağıtımda i386 mimarisi etkinleştirilene ve bağlandığı kütüphaneler var olana kadar çalışmaz.

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"

Boş not found listesi sonraki her şey için kapıdır. Kesin paket kümesi sürümler arasında değişir: çalışan bir rapor libstdc++5:i386, libx11-6:i386 ve libpam0g:i386 gerektiriyordu, bir diğeri libstdc++6:i386 da gerektiriyordu. Başka bir dağıtım için yazılmış bir öğreticiden paket listesi kopyalamak yerine ldd okuyun.

snx hiç bulunamazsa, kurulum programı hiç tamamlanmadı ya da PATH'inizin dışında bir yere kuruldu. Bu başka bir arıza ve sisteme mimari eklemeden önce doğrulanmaya değer. command -v snx ile kontrol edin ve kurulum programının bildirdiği dizine bakın. İkili dosyanın hiç olmadığı bir makineye i386 paketleri eklemek hiçbir şeyi düzeltmez.

Belirti iki: oturum açma başarılı ve hiçbir şey yönlendirilmiyor

Başarılı bir oturum açma tunsnx oluşturur ve yönlendirme tablosunu kendisi düzenler, bu yüzden başka bir şeyi değiştirmeden önce gerçekte ne olduğunu kontrol edin.

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

Sökmek için snx -d kullanın. Süreci öldürmek arayüzü ve yollarını geride bırakır ve sonraki deneme kimlik bilgileriyle hiç ilgisi olmayan bir nedenden başarısız olur. İlk oturum açma ayrıca /etc/snx/ altında bir sunucu imzası kaydeder, bu yüzden denetimsiz bir betik çalışabilmek için önce bir etkileşimli çalıştırmaya ihtiyaç duyabilir. Bu durumu yalnızca sunucuyu yeniden onaylamayı düşündüğünüzde silin.

Belirti üç: tünel yükselene kadar adlar çözülür

Sessizce bozulan budur. snx itilen DNS sunucularını doğrudan /etc/resolv.conf dosyasına yazar. Bu yolun /run/systemd/resolve/ içine bir sembolik bağlantı olduğu yerde, düzenleme bir sonraki çözümleyici olayında kaybolabilir ve bağlantı kesildikten sonra itilen girdiler de aynı şekilde kalabilir.

İki düzenleme işe yarar ve seçim ilk arama sonucunun önerdiği değil, bilinçli olmalıdır:

  • Dosyayı devralın: sembolik bağlantıyı statik bir dosyayla değiştirin ve libnss-resolve ile i386 sürümünü kurun, böylece dosya altından yeniden yazıldığında ad hizmetinin yine bir yedeği olur.
  • systemd-resolved'ı sahip olarak tutun ve tünel bağlantısını kaydedin: resolvectl dns tunsnx 10.0.0.10, ardından resolvectl domain tunsnx corp.example, ve resolvectl status ile doğrulayın.

Bağlanmadan önce VPN öncesi ad sunucularını not edin. Dosyayı elle düzenlerseniz, itilen girdileri sonradan kaldırmak prosedürün parçasıdır, isteğe bağlı temizlik değildir, çünkü bağlantı kesildikten sonra kurumsal DNS'i koruyan bir dizüstü bilgisayar başka hiçbir şeyi çözemez.

Belirti dört: portal çalışıyor ve CLI çalışmıyor

Son güvenlik duvarı sürümleri ara yazılımı tarayıcıdan yerel bir Java artalan sürecine taşıdı, bu yüzden portal 14186 bağlantı noktasındaki yerel bir aracıyla konuşur. Bu adres bir tarayıcı sertifikası istisnası ve çalışan bir süreç gerektirir.

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

Komut satırı ayrı bir yoldur: snx -s vpn.example.com -u user, burada ~/.snxrc sunucuyu, kullanıcı adını ve yeniden kimlik doğrulama tercihini tutar. Çalışan bir portal oturumu CLI'nin doğru kurulup kurulmadığı hakkında hiçbir şey söylemez ve çıplak istemci tek kullanımlık kodları işlemez.

Kazandırdığından fazlasına mal olan konteyner kestirmesi

snx tun modülünü denetler, yoksa yükler, bir tünel arayüzü oluşturur, yolları yeniden yazar ve trafiği onun üzerinden geçirir. Bunu bir konteyner içinde yeniden üretmek /dev ve /lib/modules dizinlerini bağlamak ve geniş yetkiler vermek anlamına gelir, bu da ana makinenin ağ yönetiminin çoğunu konteynere verir.

Gerçekten bir korumalı alan gerektiğinde, sanal makine daha temiz sınırdır: istemci değiştirebileceği bir çekirdek alır ve ana makine yönlendirme tablosunu korur. Vermekten pişman olacağınız yetkilere bir öğleden sonra harcamadan önce bunu seçin.

İlgili makaleler