چگونه مسیریابی VPN DNS را برای هر پیوند از resolvectl بخوانیم
resolvectl status سرورها، دامنه‌ها و مسیر پیش‌فرض را برای هر پیوند نشان می‌دهد. آن‌ها را با هم بخوانید، سپس نام را بپرسید و توجه کنید کدام پیوند پاسخ داد.
resolvectl status را اجرا کنید و دیواری از بلوک‌های هر پیوند می‌گیرید، هرکدام با سرورهای خودش و خط دامنه‌های خودش. خطی که مسیریابی را تعیین می‌کند فهرست دامنه‌هاست، نه نشانی سرور نام، چون stub محلی هر پرس‌وجو را به پیوندی می‌فرستد که نام را ادعا می‌کند. این ادعاها را پیش از خواندن پاسخ بخوانید، سپس نام را بپرسید و بررسی کنید کدام پیوند آن را تولید کرد. پاسخ نادرست از پیوند درست مشکلی متفاوت از پاسخ درست از پیوند نادرست است.
هر بلوک هر پیوند چه چیزی به شما می‌گوید
هر بلوک سرورهایی را که resolver برای آن رابط به کار می‌برد، فهرست دامنه‌ها و اینکه پیوند مسیر پیش‌فرض است یا نه فهرست می‌کند. فهرست دامنه‌ها مجموعه‌ای از ادعاهاست و resolver تطبیق بلندترین پسوند را اعمال می‌کند: پرس‌وجو برای host.corp.example را پیوندی که corp.example دارد پیش از پیوندی که فقط مسیر پیش‌فرض دارد ادعا می‌کند. دو پیوند که پسوند یکسان را ادعا می‌کنند نتیجه را به اولویت و ترتیب می‌سپارند، از این‌رو تکراری‌ها نخست شایسته توجه‌اند. خط سرور جاری نشان می‌دهد کدام‌یک از سرورهای فهرست‌شده در آن لحظه در کار است.
نشانی stub مانند 127.0.0.53 در /etc/resolv.conf فقط می‌گوید stub جلو است. نام بالادستی که پاسخ داده را نمی‌گوید، از این‌رو تشخیصی که تنها بر resolv.conf تکیه کند متوقف می‌شود.
سه نوع ورودی دامنه را درست بخوانید
| ورودی | چه چیزی را ادعا می‌کند | خطای معمول |
|---|---|---|
| corp.example | دامنه مسیریابی و پسوند جست‌وجو: نام‌های زیر آن به این پیوند می‌روند و رشته به نام‌های بی‌پسوند افزوده می‌شود | حذف شده چون مسیریابی به هر حال کار می‌کند |
| ~corp.example | فقط مسیر: نام‌های زیر آن به این پیوند می‌روند، اما پسوند افزوده نمی‌شود | فرض شده که برای مسیریابی لازم است |
| ~. | مسیر پیش‌فرض: پرس‌وجوهایی را ادعا می‌کند که هیچ پیوند دیگری با آن‌ها مطابقت ندارد | در نمایه تقسیم‌شده فعال مانده، پس نام‌های عمومی از تونل پیروی می‌کنند |
تیلدا رفتار جست‌وجو را عوض می‌کند، نه مسیریابی را. ورودی بدون تیلدا هم دامنه مسیریابی است و هم دامنه جست‌وجو، پس نام‌های زیر آن به آن پیوند فرستاده می‌شوند و به نام‌های تک‌برچسبی پسوند افزوده می‌شود. ورودی با تیلدا همان پسوند را مسیریابی می‌کند ولی آن را بیرون از فهرست جست‌وجو نگه می‌دارد. از این‌رو برداشتن تیلدا تغییر می‌دهد کدام نام‌های بی‌پسوند حل می‌شوند، و از این‌رو نبودن تیلدا مسئله جست‌وجوست نه شکست DNS تقسیم‌شده.
ورودی مسیر پیش‌فرض هر چیزی را ادعا می‌کند که هیچ پیوند دیگری با آن مطابقت ندارد. نمایه تونل کامل معمولاً آن را می‌خواهد و نمایه تقسیم‌شده معمولاً نه، چون نام‌های عمومی آن‌گاه به resolver خصوصی می‌روند و ممکن است آنجا شکست بخورند. جدول را بر پایه قصد نمایه بخوانید، نه با کپی پرچم‌ها میان نمایه‌ها. وقتی دو پیوند پسوند یکسان را ادعا می‌کنند، پیش از ویرایش هر چیز دیگری مسئله اولویت را روشن کنید.
نامی را بپرسید و ببینید کدام پیوند پاسخ داد
زیرفرمان query نشانی، پروتکل و پیوند یا دامنه‌ای را که پاسخ را تولید کرده چاپ می‌کند. یک نام را که باید پسوند خصوصی ادعا کند و یک نام عمومی معمولی را بیازمایید، سپس منابع گزارش‌شده را مقایسه کنید. اگر نام خصوصی از پیوند بی‌سیم پاسخ دهد، ادعا نیست یا تونل پایین است، و اگر نام عمومی در نمایه تقسیم‌شده از تونل پاسخ دهد، مسیر پیش‌فرض بیش از حد گسترده است. این دو شکست در مرورگر یکسان و در این خروجی وارونه به نظر می‌رسند.
resolvectl status
resolvectl query host.corp.exampleپروتکل گزارش‌شده را هم ببینید، چون پاسخ از حافظه نهان یا از فایل میزبان می‌تواند بدون پرسیدن از هیچ بالادستی برسد. پاسخ از حافظه نهان ثابت می‌کند که نام زمانی حل شده بود، نه اینکه سیاست کنونی آن را درست مسیریابی می‌کند.
مسیریابی نام را از مسیریابی بسته جدا نگه دارید
تصمیم resolver مسیر نمی‌سازد. سرور انتخاب‌شده هنوز به مسیری به نشانی خود نیاز دارد و نشانی برگشتی هنوز به مسیری به شبکه خصوصی نیاز دارد، پس سیاست DNS درست می‌تواند با اتصالی که هرگز باز نمی‌شود هم‌زمان باشد. وقتی نامی حل می‌شود و برنامه شکست می‌خورد، نشانی و مسیر را بررسی کنید نه اینکه دوباره DNS را عوض کنید. حل نام و دسترس‌پذیری دو پرسش با دو مالک متفاوت‌اند.
برنامه‌ها می‌توانند از resolver سامانه کاملاً بگذرند، با تنظیم DNS امن خودشان یا یک resolver توکار. نتیجه resolvectl مسیر سامانه را توصیف می‌کند و مرورگری که آن را نادیده بگیرد با هر آزمونی که می‌کنید ناسازگار خواهد بود. پیش از نتیجه‌گیری که سیاست خراب است آن تنظیم را بررسی کنید.
نشانی‌ای را که نام به آن حل شد در کنار پیوند ثبت کنید. نام درست که به نشانی نادرست اشاره می‌کند مسئله رکورد است نه مسیریابی.
پس از تغییر پیوند دوباره بررسی کنید
اتصال دوباره یا تغییر بی‌سیم وضعیت پیوند را بازمی‌سازد و مدیر شبکه ممکن است دامنه‌ها و سرورهای خود را روی هر چیزی که دستی تنظیم شده دوباره بنشاند. سپس همان دو نام را بپرسید و با خط پایه ثبت‌شده مقایسه کنید. اگر ویرایش دستی ناپدید شده باشد، اصلاح باید در نمایه اتصال باشد نه در فرمان پوسته. ثبت پیش و پس همان چیزی است که این را آشکار می‌کند.
فقط نام‌ها و بافت سروری را که گزارش نیاز دارد به اشتراک بگذارید، چون پسوندهای داخلی توپولوژی را افشا می‌کنند. مستندات systemd-resolved درباره مسیریابی دامنه قاعده بلندترین تطبیق و رفتار تیلدا را پوشش می‌دهد و یک بار خواندن بیشتر خطاهای جدول بالا را جلوگیری می‌کند: مسیریابی پرس‌وجوی systemd-resolved.