TLS ত্রুটির পরে OpenVPN বারবার চেষ্টা করে: এটি থামানোর উপায়

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

যে চক্র প্রথম ত্রুটিটি লুকায়

আপনি যা দেখেন তা একটি ব্যর্থতা নয়, বরং পুনরাবৃত্ত একটি ব্লক: একটি সংযোগের চেষ্টা, একটি TLS ত্রুটি, একটি বিরতি এবং তারপর একই ক্রম। প্রতিটি পুনরাবৃত্তি মূল লাইনটিকে জার্নালে আরও উপরে ঠেলে দেয়। ইউনিটটি ব্যর্থতায় পুনরায় চালু হলে, কেউ কারণ না পড়েই চক্রটি ঘণ্টার পর ঘণ্টা চলতে পারে। লক্ষণ হলো চক্রটি, যদিও মূল ত্রুটি একটিই আলোচনা সমস্যা।

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

কিছু বদলানোর আগে একটি পূর্ণ চক্র ধরে রাখুন। দূরবর্তী ঠিকানা, ত্রুটিতে উল্লিখিত TLS পর্যায় এবং প্রক্রিয়াটি আদৌ বের হয় কি না তা লিখে রাখুন।

চক্রের পেছনের পুনঃচেষ্টার ব্যবস্থা

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

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

TLS ব্যর্থতায় ক্লায়েন্টকে বের হতে বাধ্য করা

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

সুপারভাইজার ঠিক করে ওই প্রস্থান দৃশ্যমান হবে কি না। Restart=always বা Restart=on-failure সহ একটি systemd ইউনিট ক্লায়েন্টকে আবার চালু করে, তাই চক্র চলতে থাকে এবং অপশনটি কিছুই করছে না বলে মনে হয়। ক্লায়েন্টকে দোষ দেওয়ার আগে নীতিটি দেখুন:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no প্রক্রিয়াটিকে বন্ধ থাকতে দেয়, এবং Restart=on-failure অশূন্য স্ট্যাটাসের পরেও পুনরায় চালু করে। আপনি যদি চান ব্যর্থতা দৃশ্যমান হোক কিন্তু সেবাটি অসংশ্লিষ্ট ক্র্যাশ থেকে সেরে উঠুক, তাহলে Restart=on-failure সেট করুন এবং পুনরায় চালুর ঝড় থামাতে StartLimitBurst ও StartLimitIntervalSec ব্যবহার করুন। তারপর শেষ প্রস্থান কোড নিশ্চিত করতে ইউনিটের স্ট্যাটাস পড়ুন: systemctl status তা জানায়, এবং জার্নাল পুনরায় চালুর উপরে প্রথম ত্রুটিটি রেখে দেয়।

সিদ্ধান্তটি ইউনিটে বা প্রোফাইল নোটে লিখুন। যে প্রোফাইল TLS ব্যর্থতায় বেরিয়ে যায় তা কারণ লিপিবদ্ধ না থাকলে পরের মানুষের কাছে দুর্ঘটনা বলে মনে হয়। কোন ব্যর্থতাগুলো প্রক্রিয়া থামাবে এবং কোনগুলো আবার চেষ্টা করা হবে তা উল্লেখ করুন।

একটি অস্থায়ী এন্ডপয়েন্ট দিয়ে এটি প্রমাণ করা

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

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

কাজ শেষ হলে পরীক্ষার প্রোফাইলটি সরিয়ে ফেলুন। ইচ্ছাকৃতভাবে ভুল এন্ডপয়েন্টযুক্ত একটি কপি হলো সেই সব মানুষের জন্য ফাঁদ যারা পরে ডিরেক্টরির প্রতিটি প্রোফাইল চালু করে।

যে পর্যায়ে এই অপশন পৌঁছায় না

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

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

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