dnsmasq পোর্ট 53 বাইন্ড করতে পারছে না: যে সকেটটি এটি দখল করে আছে তা খুঁজুন

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

এই ক্রমে পাঁচটি ধাপ: ত্রুটি পুনরুৎপাদন করুন, লিসেনার তালিকা করুন, wildcard বোঝুন, কাজ বণ্টন করুন, তারপর যাচাই করুন।

ধাপ 1: ত্রুটি পুনরুৎপাদন করুন ও পড়ুন

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

হুবহু টেক্সটটি রাখুন। অ্যাড্রেস ব্যবহৃত হচ্ছে, অনুমতি ব্যর্থতা আর অনুপস্থিত ইন্টারফেস—সবই স্টার্ট ব্যর্থতা হিসেবে আসে, আর তারা তিনটি ভিন্ন মেরামতের দিকে ইঙ্গিত করে।

ধাপ 2: মালিকদের তালিকা করুন

প্রথমে সকেটগুলো তালিকা করুন। সোর্স পোর্ট 53-এ ফিল্টার দেখার অনুমতি থাকলে দুই ট্রান্সপোর্ট ও মালিক প্রসেস—দুটোই দেখায়:

ss -lntup 'sport = :53'

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

ধাপ 3: wildcard ফাঁদ

bind-interfaces অপশন ঠিক করে dnsmasq wildcard সকেট বাইন্ড করবে নাকি প্রতিটি কনফিগার করা ইন্টারফেসের জন্য একটি করে সকেট, যেমনটি বর্ণনা করে dnsmasq রেফারেন্স। এটি ছাড়া dnsmasq wildcard বাইন্ড করে অনুরোধগুলো ইন্টারফেস অনুযায়ী ফিল্টার করতে পারে, যা অন্য ডেমন wildcard ধরে থাকলে সঙ্গে সঙ্গে ব্যর্থ হয়। Linux bind-dynamic যোগ করে, যা স্টার্টের পরে তৈরি ইন্টারফেস সামলায়—VPN ইন্টারফেস কেবল কানেক্টের সময় দেখা দিলে এটি বাস্তব সমস্যা।

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

ধাপ 4: কাজ বণ্টন করুন

ঠিক করুন কোন ডেমন VPN ক্লায়েন্টদের উত্তর দেবে আর কোনটি হোস্টকে। টানেল অ্যাড্রেসে শুনে আপস্ট্রিমে ফরওয়ার্ড করা একটি রিজলভার একটি সাধারণ ব্যবস্থা; দুটি রিজলভার যার প্রত্যেকে ভাবে সে পোর্ট 53-এর মালিক, সেটি আদৌ কোনো ব্যবস্থা নয়।

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

ধাপ 5: সকেট যাচাই করুন, তারপর পথ

রিস্টার্টের পরে ক্লায়েন্ট পরীক্ষা করার আগে নিশ্চিত করুন যে অভীষ্ট সকেটগুলো আছে। যে ডেমন কখনো বাইন্ড করেনি তাকে রুট দিয়ে বাঁচানো যায় না, আর সঠিকভাবে বাইন্ড করা সকেটের বিরুদ্ধে ক্লায়েন্ট ব্যর্থতা ভিন্ন সমাধানের ভিন্ন সমস্যা। তারপর টানেলে থাকা ক্লায়েন্ট থেকে পৌঁছানো যায় কি না দেখুন। কেবল তারপরেই জিজ্ঞাসা করা উচিত প্রয়োজনীয় নামগুলো রিজলভ হয় কি না।

আলাদা রাখার মতো তিনটি ফলাফল: সকেট আছে, ক্লায়েন্ট সেখানে পৌঁছায়, উত্তরটি সঠিক।

যা করা উচিত নয়

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

মেশিনটি ম্যানেজড হলে মালিকানা সংক্রান্ত সিদ্ধান্তটি লিখে রাখুন যেখানে পরবর্তী অ্যাডমিনিস্ট্রেটর তা পাবেন। ইমেজ পুনর্নির্মাণ হলেই পোর্ট সংঘর্ষ ফিরে আসে।