বুটে SoftEther ক্লায়েন্ট: AccountStartupSet ও ডেমন ক্রম

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

অ্যাকাউন্টটি স্বয়ংক্রিয়ভাবে চালুর জন্য চিহ্নিত কি না নিশ্চিত করুন

ফ্ল্যাগটি ক্লায়েন্টের নিজস্ব কনফিগারেশনের ভেতরে অ্যাকাউন্ট রেকর্ডে থাকে, তাই ক্লায়েন্ট পুনরায় ইনস্টল করলে বা খালি ডিরেক্টরি পুনরুদ্ধার করলে তা মুছে যায়। অন্য কিছু বদলানোর আগে ব্যবস্থাপনা কনসোল খুলে অ্যাকাউন্ট তালিকাটি দেখুন।

cd /opt/softether/vpnclient
./vpncmd

VPN Client ব্যবস্থাপনার জন্য 2 বেছে নিন এবং Enter চেপে স্থানীয় সার্ভার গ্রহণ করুন।

AccountStartupSet
office-hub
exit

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

সার্ভিসটি চালু হচ্ছে কি না, এবং যথেষ্ট আগে চালু হচ্ছে কি না নিশ্চিত করুন

Linux-এ ক্লায়েন্ট তার নিজস্ব ডিরেক্টরি থেকে ডেমন হিসেবে চলে, এবং কোনো বুট ধাপ অ্যাকাউন্ট ব্যবহার করার চেষ্টা করার আগেই তা চালু থাকতে হবে। ডিরেক্টরি বদলে এটি চালু করে দেওয়া একটি ছোট হুক এখনো rc.local চালায় এমন সিস্টেমে যথেষ্ট।

cd /opt/softether/vpnclient
./vpnclient start

যেখানে rc.local আর নেই, সেখানে স্পষ্ট WorkingDirectory ও রিস্টার্ট নীতি দিয়ে একটি systemd unit লিখুন। বাইনারিটি যে জায়গা থেকে চালু হয় তার সাপেক্ষে কনফিগারেশন খোঁজে, তাই ওই সেটিং ছাড়া একটি unit সফলভাবে চালু হয়েও কিছু পড়তে পারে না। ক্রম হলো সমস্যার দ্বিতীয় অর্ধেক: ডেমন শোনা শুরু করার আগে চলা কোনো সংযোগ প্রচেষ্টা মাঝেমধ্যে ব্যর্থ হয়, যা ধারাবাহিক ব্যর্থতার চেয়ে অনেক বেশি নির্ণয়-কঠিন। রিস্টার্ট নীতি তৃতীয় ক্ষেত্রটি ঢাকে, যেখানে ডেমন কয়েক ঘণ্টা পরে নিঃশব্দে মরে যায়।

আগের বুটের রেখে যাওয়া pid ফাইলে ভরসা না করে প্রসেস তালিকা দেখুন।

অ্যাডাপ্টারটি ঠিকানা পেয়েছে কি না নিশ্চিত করুন

অ্যাকাউন্ট সংযুক্ত হওয়ার পরেই ক্লায়েন্ট একটি ভার্চুয়াল অ্যাডাপ্টার দেখায় এবং অ্যাডাপ্টারটির তখনো ঠিকানা দরকার। SecureNAT চালানো হাব সাধারণত DHCP-এর উত্তর দেয়; কিন্তু ভৌত LAN-এ ব্রিজ করা হাব বরং সেই LAN-এর সার্ভারের উত্তর দেওয়ার আশা করে।

ip -brief address
dhclient vpn_vpn1

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

ঠিকানাবিহীন অ্যাডাপ্টার তালিকার সবচেয়ে নীরব ব্যর্থতা, কারণ অ্যাকাউন্ট তখনো সংযুক্ত বলে জানায়।

রুটটি আপনার ভাবনার দিকেই যাচ্ছে কি না নিশ্চিত করুন

সুস্থ লিংক ও বৈধ ঠিকানা থাকলেও ট্রাফিক ব্যর্থ হতে পারে। হাবের সাবনেটের ভেতরের কোনো গন্তব্যের জন্য কার্নেল কোন ইন্টারফেস ব্যবহার করবে জিজ্ঞেস করুন, তারপর সেই উত্তরটি টানেলের সঙ্গে মিলিয়ে দেখুন।

ip route get 10.10.20.15

হাবের রেঞ্জের সঙ্গে ওভারল্যাপ করা স্থানীয় সাবনেট জেতে, কারণ তার রুটটি আরও নির্দিষ্ট এবং আগেই ইনস্টল করা আছে।

এটি ক্লায়েন্টের বাগ নয়, একটি নম্বরায়ন সিদ্ধান্ত, আর সার্ভিস রিস্টার্ট করলে তা বদলাবে না। রিজলভার কনফিগারেশন হলো অন্য অর্ধেক: কাজ করা DNS সার্ভার ছাড়া একটি ঠিকানা এমন টানেল তৈরি করে যা প্রতিটি লিংক পরীক্ষা পাশ করে, তবু কোনো নাম খুলতে পারে না।

চারটি পরীক্ষা পুনর্নির্মাণের নোটে লিখুন

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

ফ্ল্যাগটি আবার প্রয়োগ করার এক লাইন, আর ভুলে যাওয়া সহজ।

ক্রমটি রাখুন: ফ্ল্যাগ, সার্ভিস, ঠিকানা, রুট। মাঝখান থেকে শুরু করা চেকলিস্ট অনেক আত্মবিশ্বাসী ভুল উত্তর তৈরি করে।