روی یک Mac، ping نام یک ماشین tailnet را حل می‌کند در حالی که nslookup شکست برمی‌گرداند، و هر دو فرمان راست می‌گویند. برنامه‌ها از طریق حل‌کننده سامانه حل می‌کنند که Tailscale آن را برای هر واسط پیکربندی می‌کند، در حالی که nslookup و host پرونده ایستایی را می‌خوانند که MagicDNS هرگز به آن دست نمی‌زند. دو مسیر می‌توانند بدون از دست رفتن حتی یک بسته اختلاف داشته باشند. پیش از تغییر هر تنظیم DNS تصمیم بگیرید برنامه شکست‌خورده شما کدام مسیر را رفته است.

دو مسیر حل، دو پاسخ متفاوت

ترافیک برنامه‌ها در macOS از حل‌کننده سامانه می‌گذرد، و ورودی‌های حل‌کننده محدودشده برای هر واسط تعیین می‌کنند کدام کارساز برای کدام دامنه پاسخ دهد. Tailscale ورودی MagicDNS خود را همان‌جا نصب می‌کند، از این رو Safari و ssh نام‌های tailnet را پیدا می‌کنند. در عوض nslookup و host و dig /etc/resolv.conf را می‌خوانند یا کارسازی را در خط فرمان می‌گیرند، و آن پرونده معمولاً هنوز نام router یا کارساز اداری را می‌برد. نام tailnet فرستاده‌شده به آن پرونده هیچ پاسخ معتبری ندارد که منتظرش باشد، بنابراین ابزار شکست را گزارش می‌کند در حالی که مسیر سامانه موفق است.

هیچ‌یک از دو ابزار بدرفتاری نمی‌کند. آن‌ها از کارسازهای متفاوت می‌پرسند، و تنها یکی از آن کارسازها از tailnet شما خبر دارد.

همان نام را از مسیر سامانه بیازمایید

از فراخوان جست‌وجوی سامانه به عنوان نخستین آزمون استفاده کنید، سپس آن را با پرسشی که مستقیماً به حل‌کننده MagicDNS فرستاده می‌شود مقایسه کنید. املای هر دو را یکسان نگه دارید، از جمله دامنه tailnet، چون نام کوتاه و نام کاملاً واجد شرایط دو پرسش متفاوت با دو پاسخ متفاوت‌اند.

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

آن سه خروجی به سه پرسش پاسخ می‌دهند: سامانه چه برمی‌گرداند، کدام حل‌کننده‌ها برای کدام دامنه‌ها پیکربندی شده‌اند، و خود MagicDNS چه می‌داند. نامی که در دوم و سوم هست ولی در اولی نیست به پیکربندی محلی اشاره دارد نه به tailnet.

وقتی نام حل شد، سرویس را بیازمایید

پاسخ درست DNS تنها اثبات می‌کند که نامی به نشانی‌ای نگاشت می‌شود. سرویس پشت آن می‌تواند متوقف باشد، درگاه می‌تواند با قاعده دسترسی پالوده شود، و گواهی می‌تواند میزبان متفاوتی از آنچه تایپ کردید نام ببرد.

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

متن اصلی خطا را نگه دارید، چون هشدار گواهی، پایان مهلت اتصال و نام پیدانشده هر یک به جای متفاوتی می‌رسند. تغییر کارسازهای نام سومین را درست می‌کند و یک بعدازظهر را برای دو مورد اول هدر می‌دهد.

MagicDNS جایگزین DNS اداری نیست

نامی درون یک ناحیه اداری نام دستگاه tailnet نیست حتی وقتی همان کارخواه می‌تواند به هر دو برسد. وقتی مقصد پشت router زیرشبکه است، کارخواه برای آن ناحیه به split DNS نیاز دارد که به حل‌کننده داخلی اشاره کند، که تنظیمی متفاوت از MagicDNS است و در کنار آن مستند شده است.

دامنه‌های جست‌وجو هم اهمیت دارند. به یک نام کوتاه واجد شرط‌نشده هر پسوند پیکربندی‌شده به ترتیب افزوده می‌شود، بنابراین لپ‌تاپی که به‌تازگی به شبکه دیگری پیوسته می‌تواند از طریق پسوندی کهنه حل کند. پیش از خراب اعلام کردن ناحیه بررسی کنید کدام پسوند اعمال شده است.

وقتی هر دو مسیر شکست می‌خورند، واقعیت‌های tailnet تصمیم می‌گیرند

اگر جست‌وجوی سامانه و پرسش مستقیم هر دو برای دستگاهی که باور دارید وجود دارد شکست بخورند، مشکل بالادست حل‌کننده Mac است.

نام ماشین و دامنه tailnet را در کنسول مدیریت تأیید کنید، تأیید کنید دستگاه برخط و تأییدشده است، و تأیید کنید تنظیمات DNS کارخواه به صورت محلی غیرفعال نشده است. دستگاهی که برون‌خط است نامش را نگه می‌دارد و به‌سادگی نشانی‌ای برای برگرداندن ندارد.

سپس بر پایه شواهد انتخاب کنید. نامی که در مسیر سامانه حل می‌شود و در nslookup شکست می‌خورد تفاوت مسیر ابزار است؛ نامی که حل می‌شود در حالی که سرویس رد می‌کند مشکل دسترسی یا گواهی است؛ نامی که هیچ‌جا حل نمی‌شود مشکل tailnet یا پیکربندی DNS است. سه مالک، سه اصلاح، و مستندات MagicDNS جزئیات macOS مورد نخست را پوشش می‌دهد.

مقالات مرتبط