نئے اوبنٹو پر GlobalProtect کا لینکس کلائنٹ کیوں ناکام ہوتا ہے

معقول مفروضہ یہ ہے کہ آپ کے GlobalProtect پورٹل سے ملا .deb خراب ہے، یا وینڈر نے ناقص بلڈ جاری کیا۔ عام طور پر ایسا نہیں ہوتا۔ وینڈر کا لینکس انٹرفیس اب بھی Qt5 WebKit سے منسلک ہے، اور نئے اوبنٹو ریلیز اسے مزید فراہم نہیں کرتے، اس لیے پیکیج ایسی لائبریری مانگ رہا ہے جو آپ کی ڈسٹری بیوشن نے جان بوجھ کر ہٹائی۔ یہ پیکیجنگ کی بے میل ہے، خراب ڈاؤن لوڈ نہیں، اور یہی فرق طے کرتا ہے کہ آپ دوپہر پیکیجز کو زبردستی منوانے میں گزاریں گے یا دس منٹ دوسرا کلائنٹ چننے میں۔

.deb خراب نہیں

ایسا انحصار جو ڈسٹری بیوشن مزید نہیں رکھتی، لائبریری کے ریٹائر ہونے کا عام نتیجہ ہے۔ Qt5 WebKit بعد کے اوبنٹو آرکائیوز اور ڈیبیان سے ہٹا دیا گیا، اور وجہ طلب کی کمی نہیں بلکہ سیکیورٹی دیکھ بھال تھی۔ جب ایسا ہوتا ہے، ہر وہ پیکیج جو اب بھی اس سے منسلک ہے نصب نہیں ہو سکتا، چاہے وہ کتنی اچھی طرح بنایا گیا ہو۔

دو خرابیوں کو ایک ہی بگ بتایا جاتا ہے اور وہ ایک نہیں ہیں۔ لائبریری کے بغیر ریلیز پر انسٹالر نامکمل انحصار پر رک جاتا ہے۔ ایسی ریلیز پر جہاں کلائنٹ نصب ہو کر لاگ اِن پر ناکام ہو جاتا ہے، آپ دراصل ایمبیڈڈ براؤزر کمپوننٹ کے اندر TLS یا SAML ہینڈ شیک کا مسئلہ دیکھ رہے ہیں۔ پہلا پیکیجنگ ہے؛ دوسرا رن ٹائم، اور کوئی بھی پرانی لائبریریاں جدید ڈیسک ٹاپ میں نقل کر کے ٹھیک نہیں ہوتا۔

انحصار کو زبردستی منوانے کے بجائے تصدیق کریں

پیکیج کو واضح طور پر نصب کریں تاکہ ٹول حل نہ ہونے والے انحصار کا نام لے، نہ کہ آپ کو خلاصہ دے۔ پھر پوچھیں کہ کیا آپ کی ریلیز میں کوئی امیدوار ہے ہی، کیونکہ ”یہاں دستیاب نہیں“ اور ”اس آئینے سے عارضی طور پر غائب“ بالکل مختلف فیصلوں کی طرف لے جاتے ہیں:

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

اگر apt-cache policy کوئی امیدوار نہ بتائے تو اسے نصب کرنے کی کوشش چھوڑ دیں اور متبادل چننا شروع کریں۔ دلچسپ بات غائب پیکیج کا نام نہیں؛ دلچسپ بات یہ ہے کہ وینڈر کا انحصار گراف ان ڈسٹری بیوشنز کے ساتھ نہیں بڑھا جو آپ کے صارفین چلاتے ہیں۔

پرانی پیکیجز کو زبردستی منوانا ڈیسک ٹاپ کے ساتھ کیا کرتا ہے

جو حل گردش کر رہا ہے وہ یہ ہے کہ لائبریری کسی پرانی ریلیز سے کھینچ لی جائے۔ موجودہ اوبنٹو پر یہ Qt5 کے معمولی ورژن کے تصادم پر جا کر رکتا ہے: پرانی پیکیجز libqt5core5t64 کو پیچھے کھینچتی ہیں، اور پھر نصب شدہ KDE اور PyQt پیکیجز ایسا ABI ورژن مانگنے لگتے ہیں جو کم کیا گیا لائبریری مزید فراہم نہیں کرتی۔ نتیجہ ایک جزوی اپ گریڈ ہے جو غیر متعلق اطلاقات توڑ دیتا ہے، اور یہ اُس دوپہر سے کہیں بدتر ہے جس سے آپ نے آغاز کیا۔

یہ نتیجہ متوقع ہے، بدقسمتی نہیں۔ Qt کی معمولی ورژنز کے لیے ABI توقعات سخت ہیں، اور ایک ڈسٹری بیوشن ایک ہم آہنگ مجموعہ فراہم کرتی ہے۔ دوسری ریلیز سے ایک لائبریری ملانا کوئی نشانہ شدہ مرمت نہیں؛ یہ دوسرا، کم کنٹرول شدہ اپ گریڈ ہے۔

یہی مشورہ خرابی کے رن ٹائم ورژن پر بھی لاگو ہے۔ پرانے کلائنٹ کا ہینڈ شیک کامیاب کرانے کے لیے 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 ریلیز پر چلائیں، ورچوئل مشین میں اگر آپ کا ورک سٹیشن آگے بڑھ چکا ہے۔ یہ ڈیسک ٹاپ کو محفوظ رکھتا ہے اور پرانے انحصار کو ایسی حد کے اندر رکھتا ہے جسے آپ دوبارہ بنا سکتے ہیں۔