OpenVPN یک سرور DNS فرستاد، اما Linux آن را نادیده می‌گیرد

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

بررسی یک: اتصال چگونه آغاز می‌شود

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

فرایند خط فرمان به‌طور خودکار یک اتصال NetworkManager نیست، و اتصال NetworkManager به‌طور خودکار همان چیزی نیست که resolv.conf را نوشته است. این دو فرض بیشتر ساعت‌های تلف‌شده در این بررسی را توضیح می‌دهند. بپرسید کدام مؤلفه DNS را برای رابطی که واقعاً می‌بینید منتشر می‌کرد.

پیش از ادامه مالک را بنویسید. هر بررسی بعدی به آن وابسته است.

بررسی دو: پیوند resolver در واقع چه چیزی را نگه می‌دارد

روی میزبان systemd-resolved، resolvectl status هر پیوند را با سرورهای DNS و دامنه‌هایش فهرست می‌کند. پیوند تونل را پیدا کنید و ورودی‌هایش را بخوانید، و فرض نکنید که رابط tun0 نام دارد، زیرا شماره‌گذاری از ترتیب ایجاد پیروی می‌کند. اگر نشانی ارسال‌شده در پیوند نباشد، تحویل شکست خورده است نه پرس‌وجو.

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

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

بررسی سه: آیا فضای نام آن پیوند را انتخاب می‌کند

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

تخصیص دامنه را بررسی کنید، نه فقط نشانی سرور را. دامنه‌ای که به‌صورت ~corp.example نوشته شده یک دامنه مسیریابی است، و تیلد تغییر می‌دهد که نام چگونه تطبیق داده می‌شود.

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

بررسی چهار: یک مالک، نه دو

اگر NetworkManager از قبل VPN و وضعیت resolver را مدیریت می‌کند، افزودن یک اسکریپت قلاب نامرتبط نویسندگان رقیب ایجاد می‌کند. قلابی که بسته برای systemd-resolved فراهم می‌کند یک یکپارچه‌سازی پشتیبانی‌شده است و چرخه عمر مشخصی انتظار دارد: script-security 2، یک مسیر up، up-restart، یک مسیر down و down-pre. آن گزینه‌ها باعث می‌شوند ثبت و حذف در لحظه‌های درست رخ دهند نه فقط در نخستین اتصال.

از مسیر نصب‌شده از بسته استفاده کنید، نه مسیری نمونه‌ای که از یک راهنما کپی شده است. مجوزها هم مهم‌اند، زیرا قلاب پس از کاهش دسترسی‌ها اجرا می‌شود.

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

بررسی پنج: همان نتیجه پس از اتصال دوباره

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

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