لماذا يفشل عميل Linux من GlobalProtect على إصدارات Ubuntu الأحدث

الافتراض المعقول هو أن ملف .deb من بوابة GlobalProtect لديك تالف، أو أن المورّد أصدر بناءً معيباً. عادةً ليس كذلك. لا تزال واجهة Linux من المورّد ترتبط بـ Qt5 WebKit، وإصدارات Ubuntu الأحدث لم تعد توفره، لذا تطلب الحزمة مكتبة أزالتها توزيعتك عمداً. هذا عدم تطابق في التغليف، لا تنزيل تالف، وهذا الفرق يحدد ما إذا كنت ستقضي العصر في فرض الحزم أو عشر دقائق في اختيار عميل آخر.

ملف .deb ليس تالفاً

الاعتماد الذي لم تعد التوزيعة تحمله نتيجة طبيعية لسحب مكتبة من الخدمة. أُزيل Qt5 WebKit من أرشيفات Ubuntu اللاحقة ومن Debian، وكان السبب صيانة الأمان لا نقص الطلب. عندما يحدث ذلك، يتوقف كل حزمة لا تزال ترتبط به عن أن تكون قابلة للتثبيت، مهما كان بناؤها جيداً.

يُبلّغ عن عطلين كأنهما الخطأ نفسه وليسا كذلك. على إصدار بلا المكتبة يتوقف المثبّت عند اعتماد غير مُلبّى. وعلى إصدار تُثبَّت فيه الحزمة ثم تفشل عند تسجيل الدخول، فأنت ترى مشكلة مصافحة TLS أو SAML داخل مكوّن المتصفح المضمّن. الأول تغليف؛ الثاني وقت تشغيل، ولا يُصلَح أي منهما بنسخ مكتبات قديمة إلى سطح مكتب حديث.

أكّد الاعتماد بدل فرضه

ثبّت الحزمة صراحةً كي تسمّي الأداة الاعتماد غير المحلول بدل أن يعطيك ملخصاً. ثم اسأل إن كان لإصدارك أي مرشّح على الإطلاق، لأن «غير متوفر هنا» و«مفقود مؤقتاً من هذه المرآة» يقودان إلى قرارات مختلفة تماماً:

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

إذا apt-cache policy لم يُبلّغ عن أي مرشّح، فتوقف عن محاولة تثبيته وابدأ باختيار بديل. المثير ليس اسم الحزمة المفقودة؛ المثير هو أن مخطط اعتماديات المورّد لم يتحرك مع التوزيعات التي يشغّلها مستخدموك.

ما يفعله فرض الحزم القديمة بسطح المكتب

الحل الملتف الذي ينتشر هو سحب المكتبة من إصدار أقدم. على Ubuntu حديث ينتهي ذلك إلى تعارض في الإصدار الفرعي لـ Qt5: الحزم الأقدم تسحب libqt5core5t64 إلى الخلف، ثم تبدأ حزم KDE وPyQt المثبّتة بطلب إصدار ABI لم تعد المكتبة المخفّضة توفره. النتيجة ترقية جزئية تكسر تطبيقات غير ذات صلة، وهي عصر أسوأ بكثير من الذي بدأت به.

هذه النتيجة متوقعة وليست سوء حظ. توقعات ABI في Qt للإصدارات الفرعية صارمة، والتوزيعة توفّر مجموعة واحدة متماسكة. خلط مكتبة من إصدار آخر ليس إصلاحاً موجهاً؛ إنه ترقية ثانية أقل ضبطاً.

تنطبق النصيحة نفسها على نسخة وقت التشغيل من العطل. خفض مستوى أمان OpenSSL على مستوى النظام كي تنجح مصافحة عميل قديم يغيّر كل اتصال TLS على الجهاز لإصلاح تطبيق واحد، بما في ذلك مدير الحزم الذي ستحتاجه عندما يتعطل شيء آخر.

openconnect يتحدث البروتوكول

يُنفّذ OpenConnect بروتوكول GlobalProtect مباشرةً، و ملاحظات البروتوكول تصف الاستدعاء والفصل بين واجهتي الخادم. توزّع البوابة الإعدادات وقائمة المداخل؛ والمدخل يُنهي النفق:

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

إذا أغفلت البوابة المدخل الذي تحتاجه، --usergroup=gateway أو عنوان URL ينتهي بـ /gateway يتجاوز خطوة البوابة. وعندما تُعرض عدة مداخل، --authgroup=NAME يختار بينها. المصادقة اسم مستخدم وكلمة مرور، واختيارياً شهادة عميل، ومداخل SAML تعمل عملياً عبر network-manager-openconnect بدل سطر أوامر مكتوب يدوياً.

قد يطلب مدخل ذو سياسة posture صارمة تقرير HIP قبل منح نفق. يستطيع OpenConnect توليد واحد وإرساله، لكن إذا طلب المدخل جرداً لا يستطيع إنتاجه، فلا يغيّر أي علم تلك السياسة؛ ذلك قرار من جهة الخادم.

تحقق من النفق، واعرف ما لن يصلحه openconnect

افحص ما طبّقه النفق فعلاً بدل الوثوق برسالة النجاح. يرسل المدخل التوجيه والإعداد كـ XML ويطبّقه العميل، لذا فالمسار المفقود مشكلة إعداد أو اختيار لا خطأ في العميل:

ip -4 addr show
ip route
resolvectl status

يستحق MTU نظرة خاصة. يُبلّغ إعداد GlobalProtect دائماً عن MTU صفر، لذا يقدّر العميل واحداً من عبء التغليف. النقل الكبير الذي يتوقف بينما تمر الطلبات الصغيرة هو العَرَض الكلاسيكي، والعلاج MTU صريح على الاتصال لا إيقاف اكتشاف المسار.

IPv6 قصة أخرى. أضافه PAN في GlobalProtect 4.0، ويوصف دعم OpenConnect بأنه تجريبي من الإصدار 9.0، فلا تفترض أن عائلة العناوين تتصرف مثل IPv4 لمجرد أن النفق ارتفع. وإذا فرض المدخل فحص posture لا يستطيع العميل مفتوح المصدر تحقيقه، فشغّل عميل المورّد على إصدار LTS مدعوم، في جهاز افتراضي إن كان محطة عملك قد تقدمت. هذا يبقي سطح المكتب سليماً ويضع الاعتماد القديم داخل حد يمكنك إعادة بنائه.