ড্রপ হওয়া VPN-এ OpenConnect কতক্ষণ পুনরায় চেষ্টা চালিয়ে যাওয়া উচিত?

--reconnect-timeout একটি সংকীর্ণ প্রশ্নের উত্তর দেয়: টানেল ড্রপ হওয়ার পর এই ক্লায়েন্ট প্রসেসটি কতক্ষণ চেষ্টা চালিয়ে যায়, তারপর হাল ছেড়ে বেরিয়ে যায়। OpenConnect ম্যানুয়াল পৃষ্ঠা লিঙ্ক হারানো বা উত্তর দেওয়া বন্ধ করা পিয়ারের পরে পুনরায় প্রচেষ্টার জন্য 300 সেকেন্ডের নথিভুক্ত ডিফল্টসহ এই অপশনটি লিপিবদ্ধ করে, এবং সংখ্যাটি একটি চলমান ক্লায়েন্টের জন্য একটি সময়সীমা, VPN পৌঁছানোযোগ্য থাকে তার প্রমাণ নয়। এটি প্রসেসটি বাঁচিয়ে রাখার নীতিও নয়, এবং বেশিরভাগ বিভ্রান্তি এখান থেকেই শুরু হয়।

একটি দ্বিতীয় ব্যবস্থা উপরে বসলে বিভ্রান্তি আরও বাড়ে। ক্লায়েন্ট পুনরায় চালু করা সুপারভাইজার, গেটওয়েতে পিং করা প্রকবার এবং অন্তর্নির্মিত পুনঃপ্রচেষ্টা উইন্ডো—সবাই একটি ব্যর্থতায় প্রতিক্রিয়া জানাতে পারে, এবং ঘটনাটি তখন তিনটি সময়রেখা তৈরি করে যা কেউ মিলিয়ে দিতে পারে না।

পুনঃসংযোগ উইন্ডো আসলে কী সীমাবদ্ধ করে

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

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

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

সুপারভাইজার পুনরায় চালু এবং ক্লায়েন্ট পুনঃপ্রচেষ্টা দুইটি স্তর

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

সেই লাইনে দুটি বিবরণ গুরুত্বপূর্ণ। --background প্রসেসটিকে বিচ্ছিন্ন করে, তাই pid ফাইলই তার উপর একমাত্র নির্ভরযোগ্য হাতল হয়ে ওঠে, এবং টাইমআউট কেবল সেই একই প্রসেস বেঁচে থাকা পর্যন্ত খরচ হয়; যে সুপারভাইজার এটি মারে, সে চালিয়ে যাওয়ার কোনো বাজেট রাখে না।

ইচ্ছাকৃত বিচ্ছিন্নতার নিজস্ব সংকেত দরকার। পরিকল্পিত বিরতি আর সত্যিকারের বিভ্রান্তি একজন সরল দর্শকের কাছে একই দেখায়, দুটিই «সংযুক্ত নয়» হিসেবে পড়া হয়। বিরতিটিকে সুপারভাইজারের স্টপ অপারেশন বা র্যাপারের বোঝা একটি মার্কারের মাধ্যমে চালান, যাতে ইচ্ছাকৃত থামা কেউ না-চাওয়া রিস্টার্ট ঘটায় না।

হ্যান্ডঅফকে পুনঃপ্রচেষ্টা লুপের সঙ্গে প্রতিযোগিতা থেকে বিরত রাখা

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

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

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

বিভ্রান্তির সময়ে ও পরে কী যাচাই করবেন

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

যাচাইগুলো বাইরের দিকে রাখুন, কারণ প্রসেস টেবিল নিজে খুব কম প্রমাণ করে। ছোট বিচ্ছেদে pid স্থির থাকে কি না দেখুন, তারপর দীর্ঘটির পরে নিশ্চিত করুন এটি চলে গেছে এবং একবার প্রতিস্থাপিত হয়েছে:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

ছোট বাধার সময় নিশ্চিত করুন ক্লায়েন্ট সত্যিই পুনঃপ্রচেষ্টা করেছে, আগেভাগে বেরিয়ে যায়নি, এবং রুট ও রিজলভার এন্ট্রি নকল ছাড়াই ফিরে এসেছে। দীর্ঘ বিভ্রান্তির জন্য নিশ্চিত করুন পরিষ্কার এক্সিট এবং ঠিক একটি রিস্টার্ট এসেছে। প্রমাণীকরণ ব্যর্থতার জন্য নিশ্চিত করুন ক্লায়েন্ট এমন গেটওয়ের বিরুদ্ধে ঘুরছে না যা তাকে বারবার প্রত্যাখ্যান করবে। pid জমা না হয়ে একক মানে ফেরে কি না তা যাচাই যোগ করুন।

ইচ্ছাকৃত থামানোর জন্য স্বাস্থ্য URL পৌঁছানোযোগ্য না-ই থাকা উচিত এবং প্রসেস বন্ধ থাকা উচিত। তারপর অ্যাপ্লিকেশনের দিক থেকে লুপ বন্ধ করুন: একই অনুরোধ টানেল অনুপস্থিত থাকাকালে ব্যর্থ হতে হবে এবং ফিরে এলে আপনার নীতি যে উৎস ঠিকানা প্রত্যাশা করে সেখান থেকে সফল হতে হবে। সবুজ টানেল আইকন প্রমাণ নয়, কিন্তু সম্পূর্ণ অনুরোধ প্রমাণ।