Linux-এ AWS Client VPN চালু হচ্ছে না? রানটাইম মিলিয়ে নিন

আপনি Ubuntu-তে AWS Client VPN প্যাকেজ ইনস্টল করেছেন, চালিয়েছেন, এবং কোনো প্রোফাইল পড়ার আগেই একটি অনুপস্থিত শেয়ার করা লাইব্রেরি নিয়ে লোডার ত্রুটি পেয়েছেন। প্রথম প্রবৃত্তি হলো সেই লাইব্রেরিটি কোনো পুরোনো রিলিজ থেকে নিয়ে এগিয়ে যাওয়া। সাধারণত এতে একটি ভাঙা নির্ভরতা বদলে এমন একটি সিস্টেম পাওয়া যায় যা আর নিজের প্যাকেজ ডেটাবেসের সঙ্গে মেলে না। লঞ্চ ব্যর্থতা নেটওয়ার্কের নয়, সাপোর্ট-সীমার প্রশ্ন।

ত্রুটি নেটওয়ার্কের নয়, লাইব্রেরির নাম বলে

একটি ডেস্কটপ VPN ক্লায়েন্টকে আপনার প্রোফাইল বা এন্ডপয়েন্ট দেখার আগেই তার রানটাইম লোড করতে হয়। ডায়নামিক লোডার যখন কোনো সিম্বল সমাধান করতে পারে না, প্রক্রিয়াটি প্রথম সেকেন্ডেই মরে যায় এবং উইন্ডো কখনো দেখা যায় না। প্রোফাইল সম্পাদনা, DNS কাজ বা রুট পরিবর্তনের কোনো পরিমাণই সেই পর্যায়ে পৌঁছায় না। বার্তাটি আক্ষরিকভাবে পড়ুন, কারণ এটি ঠিক বলছে লোডারের কোন অবজেক্টটি দরকার ছিল।

এভাবেই আপনি দুই ধরনের ব্যর্থতার পরিবার আলাদা করেন। অনুপস্থিত শেয়ার করা অবজেক্ট আপনার হোস্টে প্যাকেজিংয়ের সমস্যা, আর প্রমাণীকরণ প্রত্যাখ্যান হলো সেবা-পক্ষের সিদ্ধান্ত যা ক্রমে অনেক পরে আসে।

দুটোই একটি বন্ধ হয়ে যাওয়া উইন্ডোতে শেষ হয়, তাই বাগ রিপোর্টে এগুলো গুলিয়ে যায়।

গ্লোবালাইজেশন সুইচ আলাদা সমস্যা

ICU বা গ্লোবালাইজেশন উল্লেখ করা ত্রুটিগুলো কিছু ক্লায়েন্ট বিল্ডের নিচের .NET রানটাইম থেকে আসে, TLS স্ট্যাক থেকে নয়। ইনভ্যারিয়েন্ট-গ্লোবালাইজেশন সুইচ সেট করা সেই রানটাইম কীভাবে কালচার ডেটা সামলায় তা বদলায়, এবং এটি অনুপস্থিত libssl যোগায় না। TLS ত্রুটি থামাতে এটি প্রয়োগ করলে এমন ক্লায়েন্ট থাকে যা চালু হয় এবং পরে অন্য জায়গায় ব্যর্থ হয়।

দুটোকে আলাদা বাক্সে রাখুন: একটি রানটাইমের আচরণ বদলায়, অন্যটি লিংকারকে সন্তুষ্ট করে। দ্বিতীয়টি যখন আছে তখন প্রথমটির দিকে হাত বাড়ানো ছেড়ে দেওয়ার মতো অভ্যাস।

হোস্ট যদি সত্যিই প্রয়োজনীয় রানটাইম দিতে না পারে, সমর্থিত উত্তর হলো পরিবর্তিত নয়, ভিন্ন একটি হোস্ট।

পুরোনো OpenSSL আমদানি কেন উল্টো ফল দেয়

পুরোনো ডিস্ট্রিবিউশন থেকে libssl আর libcrypto /usr/lib-এ কপি করা যথেষ্টবার কাজ করে, তাই প্রলুব্ধ করে। এটি লাইব্রেরিকে প্যাকেজ ম্যানেজারের নিয়ন্ত্রণের বাইরে রাখে, ফলে পরবর্তী প্রতিটি নিরাপত্তা হালনাগাদ হয় এটি মিস করে, নয় এটি নিয়ে সংঘর্ষে পড়ে। যে হোস্টে ব্রাউজার বা SSH ক্লায়েন্টও চলে, সেখানে আপনি এমন প্রোগ্রামের ক্রিপ্টো স্ট্যাক বদলে ফেলেছেন যারা তা কখনো চায়নি।

সমর্থিত পথ হলো নথিভুক্ত প্যাকেজ উৎস এবং আপনার ঠিক OS রিলিজ ও আর্কিটেকচারের জন্য তার নির্ভরতা সমাধান। AWS Linux ক্লায়েন্টের প্রয়োজনীয়তা এবং আপনি যে সংস্করণ ইনস্টল করছেন তার রিলিজ নোট দেখুন, কারণ সমর্থন ম্যাট্রিক্স রিলিজভেদে সরে যায়।

পুরোনো ফোরামের সমাধান এক জোড়া রিলিজের স্ন্যাপশট, সামঞ্জস্যের নিশ্চয়তা নয়।

ভেন্ডরের সেবা-সংজ্ঞা অক্ষত রাখুন

কিছু নির্দেশিকা প্যাকেজ করা ইউনিটের বদলে একটি ন্যূনতম systemd ইউনিট দেয়। সেই ইউনিট সাধারণত আর্গুমেন্ট, হার্ডেনিং সেটিংস এবং ভেন্ডর পরে যোগ করা ইন্টিগ্রেশন বাদ দেয়, আর ফলে তৈরি ব্যর্থতা এমন জায়গায় দেখা যায় যা আপনি সম্পাদনার সঙ্গে মিলিয়ে দেখবেন না।

পরিবর্তন দরকার হলে বরং drop-in ব্যবহার করুন: ইউনিটের .d ডিরেক্টরিতে ছোট একটি ওভাররাইড ফাইল যা একটি নির্দেশ যোগ বা প্রতিস্থাপন করে, সঙ্গে মন্তব্য কেন এটি আছে এবং কীভাবে ফেরানো যায়। ভেন্ডরের ফাইল অক্ষত থাকে, আর পরবর্তী প্যাকেজ হালনাগাদ আপনার কাজ চুপচাপ বাতিলও করে না, নকলও করে না।

ওভাররাইডের পথ আপনার নোটে লিখে রাখুন, কারণ পরের প্রশাসক আগে সেখানেই দেখবেন।

রুট ডিবাগ করার আগে লঞ্চ প্রমাণ করুন

অনুমোদিত প্রোফাইল দিয়ে ক্লায়েন্টকে নির্ভরযোগ্যভাবে চালু করান, তারপর সাইন ইন করুন, তারপর টানেল নিশ্চিত করুন, আর কেবল তারপর রুট, DNS ও ব্যক্তিগত রিসোর্স দেখুন। প্রতিটি পর্যায় নিজের প্রমাণ তৈরি করে, আর এগুলো মিশিয়ে দিলে রানটাইম সমস্যা রাউটিং সমস্যার মতো দেখায়। ভেন্ডর সাপোর্ট দরকার হলে বন্ধ হওয়া উইন্ডোর স্ক্রিনশটের বদলে প্রথম কাজের স্টার্টআপ ইভেন্টটি ধরে রাখুন।

কখনোই ব্যক্তিগত কী বা এমবেড করা ক্রেডেনশিয়ালসহ সম্পূর্ণ প্রোফাইল ডায়াগনস্টিক উপাদান হিসেবে সংযুক্ত করবেন না।

একটি প্রশ্নই এসব টিকিটের বেশিরভাগ সমাধান করে: ইনস্টল করা ক্লায়েন্ট সংস্করণটি কি এই OS রিলিজে এখনো সমর্থিত? না হলে সমাধান হলো একটি সমর্থিত জোড়া, আরেকটি লাইব্রেরি শিকার নয়।