دامنه VPN شما در dnsmasq انتقال ناحیه نیست

ناحیهٔ شرکت را در پیکربندی dnsmasq کارخواه جست‌وجو می‌کنید، پیدا نمی‌کنید و نتیجه می‌گیرید که VPN دامنهٔ خود را فشار نداده است. آنچه فشار داده شده یک اشارهٔ مسیریابی است، نه ناحیه. کارخواه دامنه و resolverی را که باید برای آن پاسخ دهد ثبت می‌کند، و backend مدیریت‌شده آن را به ارسال شرطی تبدیل می‌کند. جست‌وجو در جای اشتباه تشخیصی مطمئن و کاملاً نادرست می‌دهد.

آنچه کارخواه پذیرفت همان چیزی نیست که دروازه پیشنهاد داد

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

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

دو نوع ورودی دامنه

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

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

localhost در resolv.conf یک باگ نیست

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

جایگزینی آن ورودی با یک resolver عمومی اصلاح نادرست کلاسیک است. حل نام عمومی را بازمی‌گرداند و سیاست شرطی را در همان ویرایش دور می‌ریزد.

backendها را با هم اشتباه نگیرید

نمونهٔ مدیریت‌شدهٔ dnsmasq و resolver سیستم برنامه‌های متفاوتی با پیکربندی متفاوت و نماهای وضعیت متفاوت هستند. فرمان وضعیت برای یکی چیز مفیدی دربارهٔ دیگری نمی‌گوید.

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

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

یک نام خصوصی مجاز و یک نام کنترل عمومی را از مسیر معمول برنامه بپرسید. پرس‌وجوی مستقیم از سرور شرکت ثابت می‌کند که رکورد وجود دارد؛ ثابت نمی‌کند که کارخواه آن سرور را انتخاب کرده است. پرس‌وجوی دوم همان است که سیاست را می‌آزماید.

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