Linux-এ Kerio VPN ক্লায়েন্ট: পাঁচটি পরীক্ষা ক্রমানুসারে
ক্রমানুসারে পাঁচটি পরীক্ষা: প্যাকেজ আর্কিটেকচার, CLI উইজার্ড, কনফিগ ফাইল, সার্ভিস স্ক্রিপ্ট এবং লগ। প্রথম ব্যর্থটিতেই থামুন।
Linux-এ Kerio VPN ক্লায়েন্ট ইনস্টল করার পর কোনো ডেস্কটপ আইকন দেখা যায় না, আর প্রাইভেট নেটওয়ার্ক নাগালের বাইরে থাকে। এটি ভাঙা ইনস্টল নয়, এই ক্লায়েন্টের স্বাভাবিক রূপ: GFI-এর Linux নির্দেশনা কমান্ড-লাইন কনফিগারেশন ও একটি সার্ভিস স্ক্রিপ্টের বর্ণনা দেয়, কোনো GUI নেই। নিচের পরীক্ষাগুলো ক্রমানুসারে করুন, কারণ প্রতিটি আলাদা স্তর সরায়। প্রথম ব্যর্থতাই বলে দেয় কোথায় থামতে হবে, আর লাফিয়ে এগোনো মানে সাধারণত এমন প্যাকেজ নতুন করে বানানো যা কখনোই সমস্যা ছিল না।
বিল্ডটি মেশিনের সঙ্গে মেলে কি না নিশ্চিত করুন
শুরু করুন dpkg মেশিনটিকে কী ভাবে এবং প্যাকেজটি কীসের জন্য বানানো হয়েছে তা দিয়ে। সাধারণ 64-বিট সিস্টেমে dpkg --print-architecture প্রিন্ট করে amd64, আর ভেন্ডরের পৃষ্ঠা সাধারণ Debian প্যাকেজের পাশে amd64 প্যাকেজ তালিকাভুক্ত করে। যে ফাইলটি আপনি সত্যিই ইনস্টল করেছেন তার নামের রিলিজ স্ট্রিং পড়ুন, দুটি মিলে যাবে ধরে নেওয়ার বদলে।
2013 সালের i386-এর জন্য বানানো আর্কাইভ শুধু --force-architecture দেওয়ার কারণে 64-বিট হয়ে যায় না। জোর করে ইনস্টল করলে বিদেশি বাইনারি বসে, এখনও চালু হওয়া একটি লঞ্চারের পিছনে নির্ভরতার ব্যর্থতা লুকায়, এবং ডেমন ভুল লাইব্রেরি লোড করতে পারে। আপনার রিলিজ যদি কেবল 32-বিট হয়, তবে এটি 32-বিট পরিবেশে চালান বা গেটওয়ে মালিকের কাছে হালনাগাদ বিল্ড চান।
নির্ভরতা লাইনও দেখুন। dpkg -s kerio-control-vpnclient | grep -i depends দেখায় প্যাকেজ কী আশা করে, আর অপূরণ হওয়া ভার্সন পিন বা অনুপস্থিত রানটাইম লাইব্রেরি এখানেই ওঠে, ক্লায়েন্ট লগে নয়।
প্যাকেজ উইজার্ড দিয়ে এটি কনফিগার করুন
ডিজাইন অনুযায়ী ক্লায়েন্টের অ্যাপ ড্রয়ারে কোনো এন্ট্রি নেই, তাই আইকন না থাকা কনফিগারেশন সফল হয়েছে কি না সে সম্পর্কে কিছুই বলে না। উইজার্ডটি আবার খুলতে sudo dpkg-reconfigure kerio-control-vpnclient চালান এবং এর প্রশ্নগুলোর উত্তর দিন: VPN এন্ডপয়েন্ট, অ্যাকাউন্টের বিবরণ এবং সার্ভার সার্টিফিকেটের ফিঙ্গারপ্রিন্ট।
ফিঙ্গারপ্রিন্টের প্রশ্নটিকে একমাত্র জায়গা হিসেবে ধরুন যেখানে ভুল সার্ভার জিতে যেতে পারে। মানটি গেটওয়ে চালানো প্রশাসকের দেওয়া সার্ভার তথ্যের সঙ্গে মেলান, এন্ডপয়েন্ট যা দেখায় তার সঙ্গে নয়। যে ফিঙ্গারপ্রিন্ট যাচাই করতে পারেন না তা গ্রহণ করলে এই তালিকার বাকিটা শুধু সাজসজ্জা হয়ে যায়, কারণ পিন সংরক্ষণের পর শত্রু সার্ভার আসলটির মতোই দেখায়। মানটি যদি অন্য চ্যানেলে নিশ্চিত করা না যায়, থামুন ও জিজ্ঞাসা করুন, যদিও টানেল অন্যথায় উঠে আসত।
উইজার্ড আবার চালালে কনফিগারেশন বদলায় এবং ক্লায়েন্ট রিস্টার্ট হতে পারে, তাই যে সেশন দিয়ে কাজ করছেন তা ওই VPN-এর ওপর নির্ভর করলে মেশিনে দ্বিতীয় পথ রাখুন। শেল ইতিহাসে ঢুকে যাওয়া কোনো কমান্ডে পাসওয়ার্ড গেঁথে না দিয়ে স্বাভাবিক প্রম্পটে টাইপ করুন।
উইজার্ড যে ফাইল লেখে তা জানুন
কনফিগারেশন থাকে /etc/kerio-kvc.conf ফাইলে, যেটি অ্যাকাউন্ট ও পিন করা ফিঙ্গারপ্রিন্ট দুটোই বহন করে। এটিকে গোপন উপাদান হিসেবে দেখুন। sudo stat -c '%a %U %G' /etc/kerio-kvc.conf এটিকে সবার পড়ার উপযোগী হিসেবে দেখানো উচিত নয়।
অনুমোদিত হাতে করা সম্পাদনার পর নেটওয়ার্ক স্ট্যাক রিস্টার্ট না করে ফাইলটির মালিক ডেমনটি রিলোড করুন: sudo /etc/init.d/kerio-kvc reload। রিলোড কনফিগারেশন আবার পড়ে এবং চলমান সেশন ফেলে দেয়, তাই জীবন্ত সংযোগে এটি নিষ্ক্রিয় কাজ নয়।
কিছু বদলানোর আগে আগের ফাইলটি কপি করুন। সম্পাদনার পর প্রমাণীকরণ ব্যর্থ হলে শেষের ভালো কপিটি ফিরিয়ে আনতে কয়েক সেকেন্ড লাগে এবং সম্পাদনাটিকে নেটওয়ার্ক থেকে আলাদা করে, কোনটি সরেছে তা জানার সবচেয়ে সস্তা উপায় এটিই।
জীবন্ত সেশন ও বুট আচরণ আলাদা করুন
সার্ভিস স্ক্রিপ্ট চলমান সংযোগ নিয়ন্ত্রণ করে: sudo /etc/init.d/kerio-kvc stop এখনই টানেল শেষ করে, আর start সেটি ফিরিয়ে আনে। কোনোটিই পরের বুটে কী হবে তা ঠিক করে না, আর দূর থেকে পরিচালিত মেশিনে এই পার্থক্যটি গুরুত্বপূর্ণ।
লিঙ্ক সরানো বা কিছু মাস্ক করার আগে কে স্টার্টআপের মালিক তা দেখুন। প্যাকেজ নিজের init স্ক্রিপ্ট ইনস্টল করতে পারে, unit তৈরি করতে পারে, বা দুটোই করতে পারে, আর ভুল নাম নিষ্ক্রিয় করলে রিবুটের পর ক্লায়েন্ট ফিরে আসে। systemctl status kerio-kvc কে প্যাকেজ ডকুমেন্টেশনের ব্যবহৃত নামের সঙ্গে মিলিয়ে দেখুন, তারপর বুট প্রক্রিয়া সত্যিই যে পথ পড়ে সেটি নিষ্ক্রিয় করুন।
কনফিগারেশন একই রকম দেখায় বলে OpenVPN unit প্রতিস্থাপন করবেন না। এই ক্লায়েন্ট Kerio গেটওয়ের সঙ্গে নিজস্ব প্রোটোকলে কথা বলে, তাই একই ফাইলের দিকে তাক করা অন্য ডেমন প্রমাণীকরণ করবে না, আর অতিরিক্ত ব্যর্থতা প্রমাণ পড়া কঠিন করে তোলে। GFI-এর Linux ক্লায়েন্টও একসঙ্গে একটি VPN সংযোগ ধরে রাখে; ওই সীমা ক্লায়েন্টের জন্য, গেটওয়ের ব্যবহারকারী ধারণক্ষমতার জন্য নয়।
লগ পড়ুন, তারপর রিসোর্স যাচাই করুন
তিনটি ফাইল /var/log/kerio-kvc ডেমনটির গল্প বলে: init.log জীবনচক্রের ঘটনার জন্য, error.log জটিল ব্যর্থতার জন্য, আর debug.log বিস্তারিতের জন্য। আপনার প্রশ্নের উত্তর দেয় এমন ক্ষুদ্রতম অংশটুকু পড়ুন, এবং যেকোনো জায়গায় পেস্ট করার আগে এন্ডপয়েন্ট ও ব্যবহারকারীর নাম সরিয়ে ফেলুন। init.log এ উইজার্ড চালানোর সময়ের আশপাশে ফাঁক থাকলে বোঝা যায় ডেমনটি কখনো রিস্টার্ট হয়নি।
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
বৈধ প্যাকেজ, চলমান ডেমন আর নাগালের মধ্যে থাকা রিসোর্স—এই তিনটি আলাদা ফলাফল, এবং তিনটিই ঠিক থাকলেই তালিকাটি শেষ। অনুমোদিত পরিবর্তনের পর এমন হোস্ট চান যা কেবল গেটওয়ের পেছনে আছে, তারপর সেখানে একটি সাধারণ সার্ভিস খুলুন। টানেল উঠে গেছে অথচ রিসোর্স নেই—এমন হলে বাকি ত্রুটি থাকে গেটওয়ের রুট বা ফায়ারওয়াল নিয়মে, আপনি এইমাত্র যে ক্লায়েন্ট পুনঃকনফিগার করেছেন তাতে নয়।
আপনি যে অবস্থায় শেষ করলেন তা লিখে রাখুন: প্যাকেজ রিলিজ, আর্কিটেকচার, ফিঙ্গারপ্রিন্ট অন্য চ্যানেলে যাচাই হয়েছে কি না, এবং কোন রিলোড বা রিস্টার্ট চালিয়েছেন। এই টোকাটুকুই পরের জনের প্রথম পরীক্ষাকে সস্তা করে।