DNS تقسیم‌شده روی OpenVPN: دامنه مسیریابی در هر سیستم‌عامل چه کاری باید انجام دهد

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

نخست خط‌مشی را نام ببرید، سپس ابتدایی سکویی را انتخاب کنید که آن را بیان می‌کند.

سه تنظیمی که به‌آسانی اشتباه گرفته می‌شوند

پسوند جست‌وجو یک نام کوتاه را گسترش می‌دهد: نوشتن files به files.corp.example تبدیل می‌شود وقتی مفسر پسوندها را به ترتیب امتحان می‌کند. دامنه مسیریابی انتخاب می‌کند کدام مفسر به پرس‌وجوهای درون یک فضای نام پاسخ دهد. مسیر IP فقط مفسر انتخاب‌شده را قابل‌دسترس می‌کند. این سه در لایه‌های متفاوتی زندگی می‌کنند و جایگزین کردن یکی با دیگری پیکربندی‌ای می‌سازد که درست به نظر می‌رسد و چیزی را حل نمی‌کند.

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

لینوکس: دامنه‌ای فقط برای مسیریابی، نه پسوند جست‌وجو

در systemd-resolved دامنه‌ای که با تیلده آغاز می‌شود دامنه‌ای فقط برای مسیریابی است، یعنی پرس‌وجوهای آن فضای نام به مفسر پیوندخورده می‌روند بدون آنکه پسوند جست‌وجو هم شوند. resolvectl domain tun0 '~corp.example' این را تنظیم می‌کند و resolvectl dns tun0 10.8.0.1 سرور را نام می‌برد. هر دو تنظیم به رابط تعلق دارند، پس با آن ناپدید می‌شوند. تیلده همان بخشی است که مردم جا می‌اندازند، و بدون آن نام‌های کوتاه از طریق مفسر کاری حل می‌شوند.

همان دامنه را به‌عنوان پسوند جست‌وجوی سراسری هم نصب نکنید. این دو تنظیم زائد نیستند؛ یکی مسیریابی می‌کند و دیگری آنچه را تایپ کرده‌اید بازنویسی می‌کند.

ویندوز به خط‌مشی فضای نام نیاز دارد، نه به پسوند

ویندوز خط‌مشی DNS تقسیم‌شده را در جدول خط‌مشی حل نام نگه می‌دارد، نه در پسوند DNS آداپتور. یک قاعده فضای نام را به سرورهای مشخصی نگاشت می‌کند: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. تنظیم تنها پسوند ظاهر نام‌های کوتاه را عوض می‌کند؛ پرس‌وجو را به سرور دیگری هدایت نمی‌کند.

پس از اتصال، خط‌مشی مؤثر را با Get-DnsClientNrptPolicy بررسی کنید، چون قاعده‌ای از اتصال پیشین می‌تواند از تونل بیشتر عمر کند. وقتی تونل قطع می‌شود قاعده‌ها را با نام حذف کنید و نام نمایشی را پایدار نگه دارید تا پاکسازی به مدخل درست بخورد.

برای هر سکو یک مالک مفسر نگه دارید

مدیر میزکار، اسکریپت up اوپن‌وی‌پی‌ان و دیمن مفسر محلی همه می‌توانند بخواهند همان پیکربندی را بنویسند. وقتی اختلاف دارند، آخرین نویسنده برنده می‌شود و نتیجه به ترتیب برچیدن بستگی دارد. یک مؤلفه را انتخاب کنید که مالک وضعیت مفسر باشد، بگذارید بقیه گزارش دهند نه بنویسند، و اتصال دوباره را آزمایش کنید: خط‌مشی باید بدون تکرار قاعده‌ها از آن جان سالم به در ببرد. قطع اتصال را هم آزمایش کنید، چون وضعیت باقی‌مانده همان چیزی است که اتصال بعدی را متفاوت رفتار می‌کند.

برنامه‌هایی که مفسر رمزنگاری‌شده خودشان را همراه می‌آورند خط‌مشی سیستم‌عامل را کاملاً نادیده می‌گیرند. این ویژگی برنامه است، نه نقص تونل.

نتیجه را بررسی کنید، نه متن پروفایل را

در هر سکو یک نام را که باید از تونل برود و یکی را که نباید حل کنید و تأیید کنید کدام سرور پاسخ داد. resolvectl query host.corp.example و Resolve-DnsName host.corp.example هر دو سروری را که پاسخ داده گزارش می‌کنند. پس از اتصال دوباره تکرار کنید. سپس تأیید کنید که مفسر تونل در نشانی‌ای که پروفایل تحمیل می‌کند قابل‌دسترس است، چون خط‌مشی درستی که به سرور غیرقابل‌دسترس اشاره کند همانند نبود خط‌مشی شکست می‌خورد.

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