تونل برپاست، پس چرا نام خصوصی هنوز شکست می‌خورد؟
تونل کارکننده به این معنا نیست که کارخواه از حل‌کننده درست پرسیده است. بررسی کنید کدام‌یک پاسخ داده، سپس فقط ناحیه‌ای را که واقعاً لازم دارد ارسال کنید.
همه‌چیز درباره اتصال درست به نظر می‌رسد: تونل برپاست و کنسول نقطه پایانی خصوصی را نشان می‌دهد، با این حال هر درخواست در حل نام شکست می‌خورد. اقدام طبیعی سرزنش کردن تونل است، که معمولاً بی‌گناه از آب درمی‌آید. پرس‌وجو به کارسازی فرستاده می‌شود که هیچ چیزی درباره ناحیه خصوصی نمی‌داند. هیچ تغییر مسیریابی آن پاسخ را عوض نمی‌کند، چون مشکل این است که از چه کسی پرسیده شده.
پرس‌وجو به کدام حل‌کننده رسید؟
پیش از آنکه اصلاً به تونل نگاه کنید، حل‌کننده متصل به هر پیوند را پیدا کنید. لینوکس کارسازهای هر پیوند را با فرمان وضعیت حل‌کننده نشان می‌دهد، و مک‌اواس حل‌کننده‌های محدوده‌دار را در خروجی پیکربندی DNS نشان می‌دهد. اگر پاسخ هنوز از روتر خانه می‌آید، پیوند تونل هرگز بررسی نشده است.
resolvectl status
scutil --dns | head -40
dig +short internal.example.comدو مرحله در اینجا اشتباه گرفته می‌شود: کارسازی که نشانی حل‌کننده را هل می‌دهد، و کارخواهی که آن را روی پیوند فعال نصب می‌کند. نمایه می‌تواند گزینه را داشته باشد و گزارش می‌تواند رسیدن آن را نشان دهد، در حالی که سیستم‌عامل هنوز از کارساز قدیمی استفاده می‌کند. گزارش را با آنچه پیوند اعلام می‌کند مقایسه کنید و به پیوند اعتماد کنید.
از نشانی استفاده کنید که شبکه ابری واقعاً به آن پاسخ می‌دهد
شبکه‌های ابری معمولاً به نام‌های خصوصی از طریق نشانی رزروشده‌ای که دو واحد از پایه محدوده فاصله دارد پاسخ می‌دهند، بنابراین شبکه‌ای که از 10.0.0.0 شروع می‌شود در 10.0.0.2 پاسخ می‌دهد. برخی ارائه‌دهندگان نیز حل‌کننده پیوندی-محلی منتشر می‌کنند که بدون دانستن محدوده کار می‌کند، و این وقتی شبکه را فرد دیگری ساخته کمک می‌کند. پیش از سپردن نشانی نامزد به کسی، مستقیماً از آن بپرسید. نشانی‌ای که حل‌کننده نیست دقیقاً مانند افتادن در دیوار آتش به نظر می‌رسد، چون پرس‌وجو به‌سادگی هرگز پاسخی نمی‌گیرد.
اگر پرس‌وجوی مستقیم از داخل شبکه پاسخ دهد اما از طریق تونل نه، حل‌کننده درست است و مسیر میان دو نقطه نه. آن نتیجه بررسی را به مسیرها، ارسال و قواعد دسترسی منتقل می‌کند، نه به نمایه کارخواه.
تونل فضای نام را حمل نمی‌کند
بسته‌ها عبور می‌کنند؛ نام‌ها نه. به هر طرف باید گفت کدام فضای نام به طرف دیگر تعلق دارد، و آن شیئی جداگانه است که مالکش کسی است که ناحیه را در اختیار دارد. شکل معمول یک ارسال برای یک فضای نام است که به حل‌کننده‌ای قابل دسترس از طریق تونل اشاره می‌کند.
در عمل هر جهت قاعده خودش را لازم دارد، چون طرفی که ناحیه را دارد باید پرس‌وجو را بفرستد. هر دو جهت نیاز دارند منبع پرس‌وجو مسیریابی و مجاز شود، و طرف پاسخ‌دهنده باید پاسخ‌ها را از طریق تونل برگرداند نه به سمت اینترنت. ارسال را باریک نگه دارید تا تنها فضای نام خصوصی به پیوند وابسته باشد. فرستادن هر پرس‌وجو از آن، یک وابستگی کوچک را در لحظه افتادن تونل به قطعی کامل تبدیل می‌کند.
مرزها را به ترتیب طی کنید
حل‌کننده نصب‌شده روی پیوند فعال را بیازمایید، سپس پرس‌وجوی مستقیم به آن حل‌کننده، سپس همان پرس‌وجو از طرف دور، و در آخر برنامه‌ای که همان نام را به کار می‌برد. هر گام یک مرز را جدا می‌کند، بنابراین شکست به شما می‌گوید کجا را نگاه کنید، نه اینکه بررسی را از نو آغاز کنید. پاسخی که کار می‌کند در حالی که برنامه شکست می‌خورد، به اعتماد گواهی یا خط‌مشی API اشاره دارد، نه به DNS. آن خرابی‌ها واقعی‌اند و هیچ تغییر حل‌کننده‌ای آن‌ها را ترمیم نمی‌کند.
بنویسید کدام گام شکست خورد. همان یک خط چیزی است که نفر بعدی لازم دارد، و ثبتش ده ثانیه طول می‌کشد.
زنجیره را جایی نگه دارید که نفر بعدی آن را پیدا کند
حل‌کننده هل‌داده‌شده، قاعده ارسال، منبع مجاز پرس‌وجو و نقطه پایانی پاسخ‌دهنده را در یک جا ثبت کنید. وقتی نام خصوصی دوباره شکست می‌خورد، سابقه نشان می‌دهد تونل جابه‌جا شده، نشانی حل‌کننده تغییر کرده، یا قاعده‌ای باریک شده است. بدون آن هر رخداد از صفر شروع می‌شود و با همان سه حدس پایان می‌یابد.
سابقه را به‌قدری کوتاه نگه دارید که دقیق بماند: چهار خط، یک تاریخ و نام کسی که هر بخش را در اختیار دارد. سابقه کهنه از نبودنش بدتر است، چون معتبر به نظر می‌رسد در حالی که غلط است.