পোর্ট 1194 ইতিমধ্যে ব্যবহারে: এই OpenVPN সকেটটি কার?

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

ত্রুটিটি একটি স্থানীয় বাইন্ড বর্ণনা করে, তার বাইরে কিছু নয়। এটি প্রমাণ নয় যে কোনো প্রদানকারী পোর্টটি ব্লক করছে, কোনো ক্লায়েন্ট ভুল পাসওয়ার্ড পাঠিয়েছে, বা সার্টিফিকেট চেইন ভাঙা।

সঠিক বাইন্ড ত্রুটি পড়ুন

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

সকেটের তালিকা করুন, পোর্টের নয়

পোর্ট নম্বর একটি অসম্পূর্ণ তালিকা। এন্ডপয়েন্ট হলো একটি ট্রান্সপোর্ট, একটি ঠিকানা-পরিবার, একটি স্থানীয় ঠিকানা ও একটি পোর্ট, সবই একটি নেটওয়ার্ক নেমস্পেসের ভেতরে। একই নম্বরে একটি UDP শ্রোতা ও একটি TCP শ্রোতা ভিন্ন সকেট, আর ভিন্ন নেমস্পেসে একই নম্বরে দুটি প্রক্রিয়া কখনো মেলে না।

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

কোন প্রক্রিয়া এটি ধরে আছে তা খুঁজুন

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

এক মালিক, নাকি দুটি পরিকল্পিত ইনস্ট্যান্স

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

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

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

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

সবকিছুর আগে বাইন্ড যাচাই করুন

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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