VPN-এর ভিতরে mDNS: .local নামগুলো কেন সমাধান হয় না

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

আজ কী সমাধান হয় আর কী কেবল সমাধান হওয়া মনে হয়, তা দেখুন

প্রথমে দুটি প্রশ্ন আলাদা করুন: হোস্টনামের জন্য unicast কুয়েরি রিজলভারকে জিজ্ঞাসা করে, আর _ipp._tcp-এর জন্য ব্রাউজ লোকাল লিংককে। Linux-এ avahi-browse -a দেখায় মাল্টিকাস্ট DNS কী দেখতে পায়, আর resolvectl query name.local দেখায় রিজলভার স্ট্যাক সেই নাম নিয়ে কী করে। macOS-এ dns-sd -B _ipp._tcp আগে ঠিকানা ছাড়াই আবিষ্কৃত সেবাগুলো তালিকাভুক্ত করে।

যদি ঠিকানা উত্তর দেয় আর নাম না দেয়, তাহলে রাউটিং কাজ করে আর আবিষ্কার কাজ করে না। একটি .local নাম হোস্টের নিজের উপরেই nss-mdns-এর মাধ্যমে উত্তর পেতে পারে avahi-browse ইনস্টল না থাকলেও, তাই সেই নামে সফল getent বা ping প্রমাণ নয় যে আবিষ্কার টানেল পার হয়েছে; ব্রাউজ ফলাফল আর রিজলভার ফলাফল আলাদা প্রমাণ। অ্যাপ্লিকেশন যা আবিষ্কার করেছে তা ক্যাশে রাখে, তাই ব্যর্থতা প্রায়ই সংযোগের সময় নয়, সংযোগের কয়েক ঘণ্টা পরে দেখা যায়। অ্যাপ্লিকেশন বন্ধ করে আবার খুলুন, তারপর দেখুন ক্যাশে থাকা এন্ট্রিতে নাম আছে নাকি ঠিকানা, কারণ আবিষ্কার থেমে যাওয়ার অনেক পরে ঠিকানা কাজ করতে থাকে।

কুয়েরি কেন কখনো টানেল পার হয় না

মাল্টিকাস্ট DNS কুয়েরি পাঠায় 224.0.0.251-এ, লোকাল নেটওয়ার্ক কন্ট্রোল ব্লকের ভিতরে, UDP পোর্ট 5353-এ। রাউটার ওই ব্লকের ঠিকানা ফরোয়ার্ড করে না, তাই কুয়েরি যে লিংকে পাঠানো হয়েছে সেখানেই থাকে। প্রেরকরা IP TTL বা IPv6 হপ লিমিট 255-এ সেট করে যাতে প্রাপক ইতিমধ্যে রাউটার পার হওয়া প্যাকেট বাতিল করতে পারে, আর এভাবেই প্রোটোকল লিংকের বাইরের স্পুফিং শনাক্ত করে, এভাবে নয় যে এটি লোকাল থাকে। লোকালিটি গন্তব্য ঠিকানা থেকে আসে, এক-হপ TTL থেকে নয়।

টানেলের ধরনও গুরুত্বপূর্ণ। tun-ধাঁচের ইন্টারফেস কেবল IP প্যাকেট বহন করে, তাই কোনো মাল্টিকাস্ট গ্রুপ এটি পার হয় না। tap-ধাঁচের ব্রিজ ব্রডকাস্ট ডোমেইনটাই বাড়ায়, তাই কিছু পুরনো ডিজাইন রাউটিংয়ের বদলে ব্রিজ করেছিল এবং ব্রিজের আনা প্রতিটি সমস্যা উত্তরাধিকারে পেয়েছিল।

বিশ্বস্ত-LAN ব্যতিক্রম এর কিছুই বদলায় না, কারণ এটি ঠিক করে কোন ট্রাফিক টানেল ব্যবহার করতে পারে, টানেলকে মাল্টিকাস্ট ফরোয়ার্ড করা শেখায় না। প্যাকেটের এখনো শোনার মতো কোনো সাধারণ সেগমেন্ট নেই।

যে নামকরণ ডিজাইন আপনি চালাতে পারবেন, তা বেছে নিন

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

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

নাম নয়, সেবাটি যাচাই করুন

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

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