কেন নতুন Ubuntu-তে GlobalProtect-এর Linux ক্লায়েন্ট ব্যর্থ হয়

যুক্তিসঙ্গত অনুমান হল আপনার GlobalProtect পোর্টাল থেকে পাওয়া .deb ভাঙা, বা ভেন্ডর খারাপ বিল্ড প্রকাশ করেছে। সাধারণত তা নয়। ভেন্ডরের 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 সংস্করণ দাবি করতে শুরু করে যা নামানো লাইব্রেরি আর দেয় না। ফলাফল একটি আংশিক আপগ্রেড যা অসম্পর্কিত অ্যাপ্লিকেশন ভাঙে, আর তা আপনি যে বিকেল দিয়ে শুরু করেছিলেন তার চেয়ে অনেক খারাপ।

এই ফল প্রত্যাশিত, দুর্ভাগ্য নয়। 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 সংস্করণে চালান, ভার্চুয়াল মেশিনে যদি আপনার ওয়ার্কস্টেশন আগে এগিয়ে গিয়ে থাকে। এটি ডেস্কটপ অক্ষত রাখে এবং পুরোনো নির্ভরতাকে এমন সীমার ভিতরে রাখে যা আপনি আবার তৈরি করতে পারেন।