WireGuard DNS روی iPhone: دامنه فقط یک پسوند جستجو است

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

خط DNS به چه چیزی تجزیه می‌شود

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

DNS = 10.24.8.53, lab.internal.example

نشانی، resolver را تأمین می‌کند. دامنه پسوندی را تأمین می‌کند که به کلاینت اجازه می‌دهد یک نام کوتاه تایپ کند و سیستم پیش از پرسیدن بقیه را اضافه کند. هیچ‌یک از این دو چیزی درباره‌ی محدود کردن resolver به آن دامنه نمی‌گوید و این همان بخشی است که مردم انتظار دارند و به دست نمی‌آورند. تنها یک فیلد در پلتفرم می‌تواند آن محدودیت را بیان کند و آن این فیلد نیست.

دو فیلد Apple، دو کار متفاوت

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

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

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

چرا هر نام همچنان به resolver تونل می‌رسد

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

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

DNS تفکیک‌شده در واقع به چه چیزی نیاز دارد

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

در دستگاه‌های مدیریت‌شده‌ی Apple این معمولاً از طریق یک پروفایل پیکربندی ارائه می‌شود که تنظیمات DNS مخصوص دامنه را حمل می‌کند. این مکانیزمی متفاوت از فایل پیکربندی WireGuard است و آن دو تنها در صورتی می‌توانند همزیستی کنند که کلاینت پروفایل را رعایت کند. پیش از فرض اینکه دو محصول یکسان رفتار می‌کنند، بررسی کنید کلاینت شما واقعاً آن فیلد را چه می‌نامد. یک اسکریپت wg-quick روی Mac و اپلیکیشن WireGuard روی iPhone خطوط مشابهی را می‌خوانند و آن‌ها را از طریق لایه‌های متفاوت نصب می‌کنند.

تنظیمات نصب‌شده را بخوانید، نه پیکربندی را

روی Mac می‌توانید بررسی کنید که سیستم در نهایت به چه چیزی رسیده است، که آموزنده‌تر از خواندن دوباره‌ی فایلی است که نوشته‌اید. فهرست resolverها نشان می‌دهد کدام سرورها برای کدام دامنه‌ها پیکربندی شده‌اند و پرسش‌های محدودشده نشان می‌دهند کدام یک برنده شد. کلاینتی که خط را خراب می‌کند این را اینجا نشان می‌دهد، نه در فایلی که نوشته‌اید. در iOS خط فرمان معادلی وجود ندارد، پس شواهد آنجا یک نتیجه است: یک نام خصوصی که از طریق تونل حل می‌شود و یک نام عمومی که پاسخش آشکار می‌کند کدام resolver پاسخ داده است.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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