GlobalProtect Linux istemcisi daha yeni Ubuntu'da neden başarısız oluyor

Makul varsayım, GlobalProtect portalınızdan gelen .deb dosyasının bozuk olduğu ya da sağlayıcının hatalı bir derleme yayımladığıdır. Genellikle öyle değildir. Sağlayıcının Linux arayüzü hâlâ Qt5 WebKit'e bağlanıyor ve daha yeni Ubuntu sürümleri onu artık sağlamıyor, dolayısıyla paket, dağıtımınızın bilerek kaldırdığı bir kütüphaneyi istiyor. Bu bir paketleme uyuşmazlığıdır, bozuk bir indirme değildir, ve bu fark öğleden sonrayı paketleri zorlamakla mı yoksa on dakikayı başka bir istemci seçmekle mi geçireceğinizi belirler.

.deb bozuk değil

Dağıtımın artık taşımadığı bir bağımlılık, bir kütüphanenin devreden çıkarılmasının olağan sonucudur. Qt5 WebKit sonraki Ubuntu arşivlerinden ve Debian'dan çıkarıldı; neden talep eksikliği değil güvenlik bakımıydı. Bu olduğunda, ona hâlâ bağlanan her paket ne kadar iyi derlenmiş olursa olsun kurulamaz hale gelir.

İki arıza aynı hata olarak bildirilir ve değildir. Kütüphanenin olmadığı bir sürümde kurucu, karşılanmayan bir bağımlılıkta durur. İstemcinin kurulup ardından oturum açmada başarısız olduğu bir sürümde ise gömülü tarayıcı bileşeninin içinde bir TLS veya SAML el sıkışma sorunu görürsünüz. Birincisi paketlemedir; ikincisi çalışma zamanıdır ve hiçbiri eski kütüphaneleri modern bir masaüstüne kopyalayarak onarılmaz.

Bağımlılığı zorlamak yerine doğrulayın

Paketi açıkça kurun ki araç çözülmemiş bağımlılığı adlandırsın, size bir özet vermesin. Ardından sürümünüzde herhangi bir aday olup olmadığını sorun, çünkü „burada mevcut değil” ve „bu aynadan geçici olarak eksik” tamamen farklı kararlara götürür:

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

Eğer apt-cache policy hiçbir aday bildirmezse, kurmayı denemeyi bırakın ve bir alternatif seçmeye başlayın. İlginç olan eksik paket adı değil; ilginç olan, sağlayıcının bağımlılık grafiğinin kullanıcılarınızın çalıştırdığı dağıtımlarla birlikte hareket etmemiş olmasıdır.

Eski paketleri zorlamak masaüstüne ne yapar

Dolaşan geçici çözüm, kütüphaneyi daha eski bir sürümden çekmektir. Güncel bir Ubuntu'da bu, Qt5 küçük sürüm çakışmasına varır: eski paketler libqt5core5t64 geriye çeker, ardından kurulu KDE ve PyQt paketleri, düşürülmüş kütüphanenin artık sağlamadığı bir ABI sürümünü talep etmeye başlar. Sonuç, ilgisiz uygulamaları bozan kısmi bir yükseltmedir; bu da başladığınız öğleden sonradan çok daha kötüdür.

Bu sonuç beklenir, şanssızlık değil. Qt'nin küçük sürümlere ilişkin ABI beklentileri katıdır ve bir dağıtım tek bir tutarlı küme teslim eder. Başka bir sürümden tek bir kütüphaneyi karıştırmak hedefli bir düzeltme değil; daha az denetlenen ikinci bir yükseltmedir.

Aynı öneri arızanın çalışma zamanı varyantı için de geçerli. Eski bir istemcinin el sıkışması başarılı olsun diye OpenSSL'in sistem geneli güvenlik düzeyini düşürmek, tek bir uygulamayı onarmak için makinedeki her TLS bağlantısını değiştirir; başka bir şey bozulduğunda ihtiyaç duyacağınız paket yöneticisi dahil.

openconnect bu protokolü konuşuyor

OpenConnect, GlobalProtect protokolünü doğrudan uygular ve protokol notları hem çağrıyı hem de iki sunucu arayüzü arasındaki ayrımı açıklar. Portal ayarları ve ağ geçidi listesini dağıtır; ağ geçidi tüneli sonlandırır:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

Portal ihtiyacınız olan ağ geçidini atlıyorsa, --usergroup=gateway veya sonu /gateway ile biten bir URL portal adımını atlar. Birden fazla ağ geçidi sunulduğunda, --authgroup=NAME aralarından seçer. Kimlik doğrulama bir kullanıcı adı ve paroladır, isteğe bağlı olarak istemci sertifikasıyla, ve SAML ağ geçitleri pratikte network-manager-openconnect üzerinden çalışır, elle yazılmış bir komut satırı yerine.

Katı bir posture ilkesine sahip ağ geçidi, tünel vermeden önce bir HIP raporu da isteyebilir. OpenConnect bir tane üretip gönderebilir, ancak ağ geçidi üretemediği bir envanter talep ediyorsa hiçbir bayrak bu ilkeyi değiştirmez; bu sunucu tarafındaki bir karardır.

Tüneli doğrulayın ve openconnect'in neyi düzeltmeyeceğini bilin

Başarı iletisine güvenmek yerine tünelin gerçekte neyi uyguladığını denetleyin. Ağ geçidi yönlendirmeyi ve yapılandırmayı XML olarak gönderir ve istemci bunları uygular, dolayısıyla eksik bir rota yapılandırma veya seçim sorunudur, istemci hatası değil:

ip -4 addr show
ip route
resolvectl status

MTU ayrı bir bakışı hak ediyor. GlobalProtect yapılandırması her zaman sıfır MTU bildirir, bu yüzden istemci bunu kapsülleme ek yükünden tahmin eder. Küçük istekler geçerken tıkanan büyük aktarımlar klasik belirtidir ve çare, yol keşfini kapatmak değil bağlantıda açık bir MTU'dur.

IPv6 yine ayrı bir konu. PAN onu GlobalProtect 4.0'da ekledi ve OpenConnect desteği 9.0 sürümünden itibaren deneysel olarak tanımlanıyor, bu yüzden tünel kalktı diye adres ailesinin IPv4 gibi davrandığını varsaymayın. Ve ağ geçidi, açık kaynak istemcinin karşılayamadığı bir posture denetimini zorluyorsa, sağlayıcı istemcisini desteklenen bir LTS sürümünde, iş istasyonunuz ilerlediyse sanal makinede çalıştırın. Bu, masaüstünü sağlam tutar ve eski bağımlılığı yeniden kurabileceğiniz bir sınırın içine koyar.