কেন nc -uz প্রমাণ করতে পারে না যে একটি OpenVPN সার্ভার প্রস্তুত

চালানো nc -uz একটি OpenVPN সার্ভারের বিপরীতে প্রায় কিছুই মাপে না, আর OpenBSD ম্যানুয়াল তার সতর্কতায় এটাই বলে: ওই মোডে UDP স্ক্যান সফলতা জানায়, কিছু শুনুক বা না শুনুক। এক্সিট স্ট্যাটাস দূরের অবস্থা নয়, স্থানীয় পাঠ প্রতিফলিত করে, তাই যে সুপারভাইজার এটিতে ভরসা করে সে প্রক্রিয়া তালিকা বিশ্বাসযোগ্য দেখালে একটি মৃত সার্ভারকে সুস্থ বলে চিহ্নিত রাখে। এটি প্রতিস্থাপন শুরু হয় পরীক্ষাটি কোন প্রশ্নের উত্তর দেবে তা ঠিক করে, কারণ প্রক্রিয়া, লিসেনার, প্রমাণীকরণ এবং অ্যাপ্লিকেশনের নাগাল চারটি আলাদা পর্যবেক্ষণ। যে পরীক্ষা এদের একটির নাম বলে তা কাজে লাগে; যে পরীক্ষা চারটিকেই বোঝায় তা বোঝা।

একটি UDP পরীক্ষা কী দেখতে পারে আর কী পারে না

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

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

পরীক্ষাটি কনফিগার করা ট্রান্সপোর্টের সঙ্গে মেলানো যেকোনো ফলাফলে ভরসা করার আগে আসে। UDP স্থাপনার জন্য দরকার ভিন্ন সংকেত, ভিন্ন প্রোটোকল নয়।

তিন কলকারী, তিন ভিন্ন প্রশ্ন

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

এগুলো একই পরীক্ষা নয়, আর একটি পরীক্ষা সৎভাবে তিনটিই ঢাকতে পারে না। আগে কলকারী বেছে নিন, তারপর প্রমাণ।

বর্তমান ইনস্ট্যান্স থেকে পরীক্ষাটি গড়ুন

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

তিন আউটপুট, তিন দাবি: ইউনিট সক্রিয়, এই বুট ইনিশিয়ালাইজেশন লাইনটি তৈরি করেছে, আর কিছু UDP পোর্ট ধরে আছে। এর কোনোটিই বলে না যে কোনো ক্লায়েন্ট সংযুক্ত হতে পারে। স্ট্যাটাস পাতায় এগুলো আলাদা রাখুন, যাতে কোনো ঘটনা একটি সবুজ বিন্দুতে চুপসে না যায়।

ইচ্ছাকৃতভাবে ভাঙুন এবং পরীক্ষাটি দেখুন

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

ব্লকটি লাইন ধরে পড়ুন। netcat কমান্ড exit=0 ছাপে, অথচ কিছুই বাঁধা নেই — এক লাইনেই পুরো সমস্যা। প্রথম ss কিছু ছাপে না, পুনরায় চালু সফল হয়, আর দ্বিতীয় ss আবার লিসেনার দেখায়। আপনার পরীক্ষা যদি থামানো সার্ভারের বিরুদ্ধে পাস করে, তবে তা স্থানীয় স্ট্যাক মাপছে, আর কিছু নয়।

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

স্ট্যাটাস লাইনটি কী বলা উচিত

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

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

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