DNS تقسیم‌شده و VPN: قواعد دامنه مسیرهای IP نیستند
DNS تقسیم‌شده resolver را بر اساس نام انتخاب می‌کند و پاسخ همچنان به مسیر نیاز دارد. قاعده دامنه و مسیر را جداگانه، روی همان پلتفرمی که واقعاً اجرا می‌کنید بیازمایید.
لپ‌تاپ شما intranet.corp را از طریق تونل حل می‌کند، در حالی که gitlab.com همچنان به resolver ارائه‌دهنده می‌رود، و این همان ترتیبی است که مطابق طراحی کار می‌کند. دو تصمیم جداگانه آن را ساخت: قاعده تطبیق نام resolver را انتخاب کرد و یک مسیر پاسخ را برگرداند. هر یک را بشکنید و مرورگر خرابی نشان می‌دهد که از بیرون یکسان به نظر می‌رسد. بیشتر گزارش‌های DNS تقسیم‌شده خرابی دوم را توصیف می‌کنند و در همان حال شواهدی درباره اولی نقل می‌کنند.
دو نیمه در جاهای مختلف زندگی می‌کنند و معمولاً افراد مختلفی آن‌ها را ویرایش می‌کنند. یکی سیاست DNS متصل به پروفایل VPN است، دیگری مسیری است که تونل نصب می‌کند یا نگه می‌دارد. اشکال‌زدایی متوقف می‌شود وقتی هیچ‌کس مشخص نمی‌کند کدام نیمه واقعاً جابه‌جا شده است.
دو تصمیم پنهان در یک درخواست
نیمه نام یک شیء سیاست است نه مسیر. در Windows سیاست حل نام روی پروفایل VPN است؛ در پلتفرم‌های Apple مجموعه دامنه‌های تطبیق روی شیء تنظیمات DNS؛ در Linux دامنه مسیریابی، خط resolver تقسیم‌شده یا ترتیب سوئیچ سرویس نام. نیمه مسیر مسیریابی معمولی است که تونل یا دست آن را نصب می‌کند و هیچ ایده‌ای از نام میزبان ندارد. پروفایلی که یک پسوند را می‌پذیرد فقط تعیین می‌کند چه کسی پاسخ می‌دهد؛ هرگز پاسخ را قابل دسترس نمی‌کند.
یک آزمون علامت سریع آن‌ها را جدا می‌کند: نام را با یک نشانی جایگزین کنید. اگر نشانی کار کند، مسیر درست است و قاعده غلط. اگر نشانی هم شکست بخورد، ممکن است قاعده درست باشد و مسیر نباشد.
چگونه هر پلتفرم همان قاعده نام را بیان می‌کند
قصد یکسان است و نام فیلدها نه. نمونه‌ای که از یک کلاینت به کلاینت دیگر کپی شود تمیز تجزیه می‌شود و هرگز مطابقت نمی‌یابد. سه شکل چنین است:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
دامنه تطبیق یا مسیریابی یک آزمون پسوند است، بنابراین intranet.corp دامنه git.intranet.corp را پوشش می‌دهد و corp.intranet را پوشش نمی‌دهد، و برعکس کردن آن شایع‌ترین خطای کل پیکربندی است. Windows نگاشت را به‌صورت سیاست حل نام متصل به پروفایل حمل می‌کند، با ترتیب اولویت خودش در برابر هر فهرست پسوندی که رابط از قبل داشت. پلتفرم‌های Apple دامنه‌های تطبیق را به شیء تنظیمات DNS افزونه شبکه متصل می‌کنند و سیستم آن‌ها را برای هر resolver محدوده اعمال می‌کند. هیچ‌یک از این شکل‌ها مسیر نیست و هیچ‌کدام نمی‌تواند نشانی دسترس‌ناپذیر را دسترس‌پذیر کند. مرجع سیاست حل نام در Windows نام فیلدها و قواعد اولویت آن پلتفرم را فهرست می‌کند و آن‌ها همان‌هایی نیستند که اسناد Apple یا systemd استفاده می‌کنند.
پاسخ درست هنوز به مسیر نیاز دارد
پاسخ resolver فقط یک نشانی است، و برنامه هنوز باید به آن برسد. طراحی تونل تقسیم‌شده اغلب 10.20.0.0/16 را فشار می‌دهد و مسیر پیش‌فرض را نگه می‌دارد، پس نام داخلی حل می‌شود و اتصال سپس معلق می‌ماند. حالت عکس به همان اندازه رایج است: مسیر وجود دارد، resolver عمومی به نام خصوصی با NXDOMAIN پاسخ می‌دهد و خرابی به‌عنوان مشکل مسیریابی ثبت می‌شود. آزمودن اول مسیر شما را به تماشای مسیرها برای نامی می‌فرستد که هرگز حل نمی‌شد.
دروازه سومی هم هست که هیچ نیمه‌ای آن را پوشش نمی‌دهد. یک ACL روی دروازه، قاعده فایروال یا سیاست سمت کلاینت می‌تواند اتصال را پس از درست بودن هر دو تصمیم بیندازد. وقتی نام حل می‌شود، مسیر وجود دارد و اتصال باز هم مهلت تمام می‌کند، آزمودن DNS را کنار بگذارید.
آزمودن نام‌ها و مسیرها با ترتیب ثابت
ترتیبی انتخاب کنید و آن را نگه دارید، وگرنه به دنبال مرحله‌ای می‌روید که آخرین بار شکست خورده است. نام داخلی کامل مستند را حل کنید، تأیید کنید که پاسخ نشانی است که جدول مسیریابی می‌تواند حمل کند، سپس با یک نام عمومی تکرار کنید تا ثابت کنید تونل همه چیز را نگرفته است. روی میزبان systemd پرس‌وجو و دامنه مسیریابی resolver یک فرمان فاصله دارند:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10کلاینت Windows همان دو پرسش را با cmdletهای متفاوت می‌پرسد. دومی رابطی را گزارش می‌کند که سیستم واقعاً استفاده می‌کرد:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10اگر جست‌وجو نشانی برگرداند و بررسی مسیر رابط فیزیکی را نام ببرد، قاعده نام کار کرده و مسیر نه. اگر نام کوتاه شکست بخورد در حالی که نام کامل حل می‌شود، فهرست پسوندها غلط است نه resolver.
کجا مقایسه معمولاً اشتباه می‌شود
خطای اول پرسیدن از یک resolver عمومی بی‌ربط درباره یک نام خصوصی و خواندن رد آن به‌عنوان شاهد درباره VPN است. دومی فرض این است که یک جست‌وجوی عمومی کارآمد مسیر resolver تونل را ثابت می‌کند. سومی این است که تونل تقسیم‌شده و DNS تقسیم‌شده را یک تصمیم طراحی بدانیم، در حالی که یک استقرار می‌تواند در یکی درست و در دیگری خراب باشد. هر خطا نتیجه‌گیری‌های مطمئن از آزمونی می‌دهد که هرگز بخش متهم را تمرین نکرده است.
مرورگری با DNS امن خودش هم می‌تواند قاعده سیستم را دور بزند، به همین دلیل شکست یک مرورگر در حالی که دیگری موفق می‌شود تناقض نیست. resolverی را که پاسخ داد مقایسه کنید، نه مرورگری را که شکایت کرد.
وقتی هر دو نیمه دیده شوند، پرسش باقی‌مانده پرسش سیاست است نه فنی: کدام فضاهای نام به سازمان تعلق دارند، مالک هر پاسخ کیست و کدام‌یک اصلاً باید ماشین را ترک کنند. آن را کنار پروفایل بنویسید، چون نفر بعدی که به قاعده دست بزند به آن نیاز خواهد داشت.