Wi-Fi বলছে সংযুক্ত, কিছুই লোড হচ্ছে না: পুরোনো Mac রিজলভার

একটি আক্ষরিক ঠিকানায় ping করুন — উত্তর আসে। নাম দিয়ে সাইট খুলুন — কিছুই হয় না, অথচ নেটওয়ার্ক আইকন জোর দিয়ে বলে সংযোগ ঠিক আছে। যে Mac এইমাত্র কোনো VPN-এ যোগ দিয়েছে, সেখানে এই সমন্বয়টি প্রায় সবসময় বোঝায় যে লুকআপগুলো এমন সার্ভারের দিকে যাচ্ছে যা আর পৌঁছনো যায় না, নেটওয়ার্ক পড়ে যায়নি। ঠিকানাগুলো আগের কোনো এক সময়ে Wi-Fi সার্ভিসে পিন করা হয়েছিল এবং তারপর থেকে কিছুই সেগুলো সরায়নি। বাদ দিয়ে দিয়ে রোগনির্ণয় করুন, তারপর পিন করা এন্ট্রিগুলো মুছুন।

মেরামতটি ফ্লাশ নয়, মুছে ফেলা, আর পার্থক্যটা গুরুত্বপূর্ণ, কারণ বেশিরভাগ মানুষ প্রথমে যে কমান্ডগুলো চেষ্টা করেন সেগুলো পুরোপুরি অন্য কিছু করে।

সংযুক্ত মানে লিঙ্ক সম্পর্কে একটি বক্তব্য

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

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

নামকে প্যাকেট থেকে আলাদা করুন

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

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

পিন করা সার্ভারগুলো মুছুন

নেটওয়ার্ক সেটিংসে Wi-Fi সার্ভিসের বিবরণ খুলে DNS ট্যাবে যান। প্রতিটি সার্ভার সারি সরান, পরিবর্তন নিশ্চিত করুন, তারপর সার্চ ডোমেইনে আপনি কখনো যোগ করেননি এমন মান খুঁজে দেখুন। তালিকাটি খালি রেখে সার্ভিসটি আবার সংযুক্ত করুন এবং নিশ্চিত করুন যে DHCP-র দেওয়া ঠিকানাটি নিজে থেকেই ফিরে আসে। খালি তালিকাই সেই সাময়িক অবস্থা যা প্রমাণ করে পিন করা মানগুলোই সমস্যা ছিল।

পুরোনো সংস্করণগুলো একই প্যানেল আরও এক স্তর গভীরে, একটি Advanced বোতামের পিছনে লুকিয়ে রাখে, একই আচরণ ও একই ফলাফল নিয়ে।

প্যানেল নয়, অবস্থাটা পড়ুন

scutil --dns | head -40 macOS আসলে যে রিজলভারগুলো ব্যবহার করছে তা পরিধি অনুযায়ী দলবদ্ধ করে দেখায়, আর পরিচিত কোনো অভ্যন্তরীণ নামের দ্রুত nslookup দেখায় উত্তর আদৌ আসে কি না। দুটি আউটপুট মিলিয়ে দেখুন: পরিষ্কার প্যানেল অথচ তালিকায় এখনো একটি পুরোনো সার্ভার থাকা মানে ওই সেটিংটির মালিক অন্য কেউ। সেটি ভিন্ন বাগ, ভিন্ন সমাধান।

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

কে এন্ট্রিগুলো ফিরিয়ে আনে

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

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

বাকি সব রক্ষণাবেক্ষণের নাটক: এমন কমান্ড যা ইচ্ছাকৃত দেখায়, পরিমাপযোগ্য কিছুই বদলায় না, আর পরের মানুষের জন্য একই ভাঙা লুকআপ রেখে যায়।