NXDOMAIN از طریق VPN به معنای قطع تونل نیست

وسوسه‌انگیز است که یک جست‌وجوی ناموفق را دلیل فروپاشی تونل بخوانیم، به‌ویژه وقتی نام ده دقیقه پیش کار می‌کرد. پاسخ چیز دیگری می‌گوید. NXDOMAIN یک تراکنش کامل‌شدهٔ DNS است که در آن resolver اعلام کرده نام پرسیده‌شده وجود ندارد؛ تونل خراب معمولاً سکوت، اتمام مهلت یا تلاش برای تفکیک نام در برابر سرور اشتباه تولید می‌کند. نسخهٔ بدون wireshark از این استدلال یک پرس‌وجو، یک پاسخ‌دهنده و یک کد پاسخ است، و ثبت این سه‌گانه پیش از هر تغییر پیکربندی ارزش دارد.

پاسخ در واقع چه چیزی را اثبات می‌کند

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

همین تفاوت تعیین می‌کند که تعمیر به کجا تعلق دارد. رکورد AAAA گمشده روی میزبانی که رکورد A دارد، میزبان گمشده نیست، و صدور دوبارهٔ گواهی یا بازسازی تونل برای دنبال کردن آن، تنها سرنخ موجود را هدر می‌دهد. این تمایز شکل پیگیری را هم تعیین می‌کند: مشکل نام‌گذاری در زون اصلاح می‌شود و مشکل نوع با درخواست رکورد درست یا با پذیرش اینکه خانوادهٔ آدرس به‌سادگی غایب است اصلاح می‌شود.

افسانه: نام خصوصی گمشده یعنی تونل شکست خورده است

افسانه زنده می‌ماند چون این دو رویداد اغلب با هم می‌آیند. کلاینت به VPN وصل می‌شود، سیستم‌عامل resolverی را نگه می‌دارد که از قبل به آن اعتماد داشت، و نام داخلی که اکنون لازم دارد از سروری پرسیده می‌شود که هرگز از زون خصوصی نشنیده است. آن سرور صادقانه و منفی پاسخ می‌دهد. تونل بسته را حمل می‌کند؛ پاسخ فقط دربارهٔ فضای نامی است که پاسخ‌دهنده آن را سرویس نمی‌دهد.

تنظیمات split-horizon این را عادی می‌کند: نام زون یکسان به‌صورت عمومی و داخلی با محتوای متفاوت وجود دارد و فقط resolver داخلی رکوردهای خصوصی را می‌داند. بنابراین گرفتن پاسخی منفی که معتبر به نظر می‌رسد شاهدی است بر اینکه کدام resolver پاسخ داده، نه شاهی بر وضعیت رابط.

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

با نام درست از resolver درست بپرسید

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

دو خط اول نشان می‌دهد resolver محلی چه تصمیمی گرفته و از چه کسی می‌پرسد. جست‌وجوی +search بازتولید می‌کند که یک برنامه هنگام افزودن پسوند جست‌وجو چه می‌کند، که اغلب همان پرس‌وجوی واقعی است و نه آن چیزی که در ابزار تشخیصی تایپ شده. خط آخر مستقیماً از سرور داخلی می‌پرسد و سیاست کلاینت را دور می‌زند؛ اگر این موفق شود در حالی که جست‌وجوی ساده شکست می‌خورد، زون درست است و مسیریابی پرس‌وجوها نه.

حافظه نهان منفی تأخیر پس از اصلاح را توضیح می‌دهد

پاسخ‌های منفی بنا به طراحی در حافظه نهان ذخیره می‌شوند و RFC 2308 توضیح می‌دهد که عمر حافظه نهان منفی چگونه از رکورد اقتدار زون مشتق می‌شود. بنابراین اصلاح یک رکورد یا قاعدهٔ resolver تغییر فوری روی کلاینت را تضمین نمی‌کند و تکرار جست‌وجویی که همچنان پاسخ ذخیره‌شده را برمی‌گرداند چیز جدیدی اثبات نمی‌کند. فقط پاسخ‌دهندهٔ متفاوت، نام متفاوت یا حافظه نهان پاک‌شده شاهد تازه تولید می‌کند.

حافظه نهان محلی را پاک کنید، سپس همان پرس‌وجو را در برابر همان پاسخ‌دهنده تکرار کنید. در سیستم‌هایی که از سرویس resolver محلی استفاده می‌کنند این یک دستور است؛ در دیگران راه‌اندازی دوبارهٔ سرویس یا ابزاری از پلتفرم است و ابزار مشخص کمتر از تکرار یک آزمون یکسان پس از آن اهمیت دارد.

نام را از مسیر جدا کنید

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

رونوشت را نگه دارید: پرس‌وجو، پاسخ‌دهنده، کد و آدرس تفکیک‌شده. همین سابقه است که گزارش بعدی را قابل بررسی می‌کند و تفاوت میان یک تشخیص و داستانی دربارهٔ تونلی است که کند به نظر می‌رسید.