কেন MagicDNS ডিভাইস সমাধান করে কিন্তু অফিসের হোস্টনেম নয়
MagicDNS একটি tailnet-এর ডিভাইসগুলোর নাম দেয়, আপনার অফিস জোনের হোস্টগুলোর নয়। স্প্লিট DNS-এর সঙ্গে পৌঁছানো যায় এমন রিজলভার ও রুটই অফিসের নামটিকে উত্তর দিতে দেয়।
MagicDNS একটি tailnet-এর প্রতিটি ডিভাইসকে তার মেশিন নাম ও tailnet-এর DNS ডোমেইন থেকে উদ্ভূত একটি নাম দেয়। সেই নাম Tailscale তৈরি করে এবং Tailscale-এর রিজলভার পথে তার উত্তর দেওয়া হয়। files.office.example-এর মতো অফিস হোস্টনেম এমন একটি জোনের অন্তর্গত যা Tailscale কখনো লেখেনি, তাই ডিভাইসের নাম বদলালে তা তৈরি হয় না। দুই নামস্থান পাশাপাশি থাকে; কেবল তাদের মালিক আলাদা।
সেই কার্যপ্রণালী খুব সাধারণ একটি অভিযোগের পেছনে থাকে: Tailscale হোস্ট উত্তর দেয়, অথচ ফাইল সার্ভার এখনো একটি রিজলিউশন ত্রুটি ফেরত দেয়।
দুই নামস্থান, দুই মালিক
একটি ডিভাইস নাম তৈরি হয় মেশিনের নিজের হোস্টনেম থেকে, সংঘর্ষ Tailscale সমাধান করে, আর ফলাফল tailnet ডোমেইনের অধীনে থাকে। অফিস জোন রক্ষণাবেক্ষণ করেন যিনি অফিস রিজলভার চালান, রেকর্ড তৈরি হয় প্রশাসক বা গতিশীল নিবন্ধনের মাধ্যমে। সংক্ষিপ্ত নাম পার্থক্যটি লুকায়: files হয়তো অফিস DNS যে সার্চ-সাফিক্স সম্প্রসারণের উত্তর দেয়, কোনো tailnet ডিভাইস, বা কিছুই নয়। পূর্ণ নামে কোয়েরি করলে দেখা যায় কোন সিস্টেমটি সত্যিই উত্তর দিয়েছিল।
সাবনেট রাউটারের মেশিন নাম বদলালে অফিস জোনের জন্য কিছুই হয় না। এটি একটি Tailscale ডিভাইসের নাম বদলায় এবং অফিস সার্ভারের রেকর্ড অপরিবর্তিত রাখে, তাই নাম বদলে আবার চেষ্টা করা কখনোই সমাধানে পৌঁছায় না।
অফিস জোনকে তার রিজলভারের দিকে নির্দেশ করুন
Tailscale-এর স্প্লিট DNS নির্বাচিত ডোমেইনের কোয়েরি আপনার উল্লেখ করা নেমসার্ভারে পাঠায়, আর বাকি সব অবশিষ্ট নীতিমালা অনুসরণ করে। অফিস রিজলভার যে ডোমেইনে সত্যিই সেবা দেয় সেটি যোগ করুন, আপনি যে সার্চ সাফিক্স টাইপ করেন তা নয়। সার্চ সাফিক্স ক্লায়েন্টকে বলে কী যোগ করতে হবে; এটি রিজলভারকে বলে না কোথায় দেখতে হবে। এই দুটি সেটিং কনসোলে একই রকম দেখায় এবং সম্পূর্ণ ভিন্নভাবে আচরণ করে।
সীমিত নেমসার্ভারকে তার সঙ্গে যুক্ত ডোমেইনের জন্য কর্তৃত্বপূর্ণ হতে হবে, নইলে উত্তরটি ঠিকানার বদলে একটি রেফারেল হবে।
পৌঁছানো যোগ্যতা সমাধানের আগে আসে
ক্লায়েন্টকেও সেই নেমসার্ভারে পৌঁছাতে হবে। একটি ব্যক্তিগত LAN-এর রিজলভারের জন্য সাবনেট রুট ঘোষণা ও গ্রহণ করতে হবে, অ্যাক্সেস নীতিমালাকে কোয়েরি অনুমোদন করতে হবে এবং ফেরার পথ থাকতে হবে। প্রশাসনিক কনসোলে সঠিক DNS ঠিকানা কেবল প্রমাণ করে কনফিগারেশন সংরক্ষিত হয়েছে। প্যাকেট রিজলভারে পৌঁছাতে না পারলে লক্ষণটি টাইমআউট, যা কর্তৃত্বপূর্ণ “এমন কোনো রেকর্ড নেই” উত্তরের থেকে আলাদা দেখায়।
এই পার্থক্যটি রোগনির্ণয়মূলক। টাইমআউট রাউটিং বা নীতিমালার দিকে ইঙ্গিত করে, আর তাৎক্ষণিক নেতিবাচক উত্তর রেকর্ড বা জোনের দিকে ইঙ্গিত করে। কোনো DNS সেটিং বদলানোর আগে দেখুন আপনি কোনটি পান।
নামের ব্যর্থতাকে সেবার ব্যর্থতা থেকে আলাদা করুন
রিসোর্স যদি তার ব্যক্তিগত ঠিকানায় সাড়া দেয় কিন্তু হোস্টনেমে না দেয়, তদন্ত DNS-এ থাকে। দুটির কোনোটিই কাজ না করলে আগে রাউটিং বা সেবা ঠিক করুন, কারণ অগম্য ঠিকানায় সমাধিত একটি নাম অগ্রগতি নয়। পূর্ণ নামে কোয়েরি করুন এবং কোন সার্ভার উত্তর দিয়েছে তা লক্ষ্য করুন। macOS-এ কিছু কমান্ড-লাইন টুল সাধারণ অ্যাপ্লিকেশন থেকে ভিন্ন পথ নেয়, তাই একটি টার্মিনাল dig ও একটি ব্রাউজার একই নাম নিয়ে একমত নাও হতে পারে।
ডিভাইসের স্বাভাবিক মোড এটি হলে একটি এক্সিট নোড নির্বাচিত করে পরীক্ষাটি আবার করুন। এক্সিট নোডের DNS হ্যান্ডলিং এক্সিটবিহীন কনফিগারেশন থেকে আলাদা, আর কেবল একটি মোডে পরীক্ষা করলে ব্যবহারকারীরা যে ব্যর্থতা দেখেন তা মিস হতে পারে।
জোন, রিজলভারের ঠিকানা এবং কোয়েরি বহনকারী রুটটি লিখে রাখুন। এই তিনটি আরেক দফা নাম বদলানো ছাড়াই বেশিরভাগ MagicDNS বিস্ময়ের ব্যাখ্যা দেয়।