প্রতি ঘণ্টার OpenVPN বিচ্ছিন্নতা: পুনরায় আলোচনা নাকি সত্যিকারের পুনঃসংযোগ?

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

ধাপগুলো ক্রমে করুন, কারণ প্রথমটি ঠিক করে বাকি পৃষ্ঠাটি আদৌ আপনার জন্য প্রযোজ্য কি না। এগিয়ে গেলে আপনি এমন ত্রুটির জন্য টাইমার টিউন করতে একটি সন্ধ্যা কাটাবেন যার সঙ্গে এর কোনো সম্পর্ক নেই।

নরম রিসেট আর পুনরায় চালু আলাদা করুন

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

কার্যকর টাইমার পড়ুন, আপনার ফাইল নয়

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

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

যেখানে সত্যিই পুশ হয় সেখানেই বদলান

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

যেখানে প্রোফাইল কেন্দ্রীয়ভাবে তৈরি হয়, স্থাপিত কপি নয়, টেমপ্লেট সম্পাদনা করুন, নইলে পরের প্রভিশনিং রান এইমাত্র সরানো মানটি ফিরিয়ে আনবে। এক নয়, দুটি বিরতি দেখে যাচাই করুন: একটি নীরব ঘণ্টা 7200-এ বসানো টাইমারের সঙ্গেও সামঞ্জস্যপূর্ণ।

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

পুনরায় আলোচনা বন্ধ করে আপনি কী ছাড়ছেন

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

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

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

যখন বিরতি অন্য কোথাও ইঙ্গিত করে

কনফিগারেশনে দুটি প্রতিবেশী একই রকম লক্ষণ ও ভিন্ন সমাধান দেয়। নির্দিষ্ট সময় ধরে কিছু না এলে ping-restart টানেল পুনরায় চালু করে, আর ping-exit ক্লায়েন্টকে পুরোপুরি বন্ধ করে। লগে কোথাও পুনরায় আলোচনা ছাড়া নিষ্ক্রিয় বিচ্ছিন্নতা এগুলোর, বা এমন NAT ডিভাইসের, যা নিজের সময়সূচিতে UDP ম্যাপিংয়ের মেয়াদ শেষ করেছে।

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

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