OpenVPN مقدار DNS را می‌فرستد، اما ممکن است حل‌کننده هرگز آن را نبیند

لاگ کلاینت سرور DNS ارسال‌شده را نشان می‌دهد، تونل متصل است و یک نام داخلی هنوز به چیزی حل نمی‌شود. هیچ چیز در خود ارسال خراب نیست. گزینه رسید و حل‌کننده سیستم‌عامل هرگز از آن استفاده نکرد، چون در بیشتر کلاینت‌های Unix، OpenVPN مقدار را تحویل می‌دهد و کاربرد را به بستر واگذار می‌کند.

نشانه: لاگ DNS را نشان می‌دهد و نام‌ها هنوز شکست می‌خورند

OpenVPN dhcp-option اطلاعات DNS و دامنه را حمل می‌کند و کلاینت آنچه دریافت کرده را ثبت می‌کند. در برخی پیاده‌سازی‌ها کلاینت آن تنظیمات را درون خود اعمال می‌کند؛ در برخی دیگر آن‌ها را برای یک اسکریپت یکپارچه‌سازی یا سرویس شبکه صادر می‌کند. خط لاگ فقط نیمه اول ماجرا را توصیف می‌کند. نیمه دوم جایی رخ می‌دهد که کلاینت کنترلی بر آن ندارد. شکست معمولاً همان‌جاست.

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

دریافت کردن به معنای اعمال کردن نیست

کلاینت می‌تواند مقدار DNS ارسال‌شده را ثبت کند در حالی که حل‌کننده سیستم هنوز متعلق به سرویس دیگری است. مرورگر نیز ممکن است سیاست DNS رمزگذاری‌شده خودش را داشته باشد که حل‌کننده سیستم را کاملاً دور بزند، و این وضعیت به‌یادماندنی را پدید آورد که یک برنامه نام‌های داخلی را حل می‌کند و برنامه دیگر نه.

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

مالک حل‌کننده را در هر بستر پیدا کنید

در Windows، جدول سیاست حل نام می‌تواند پسوندهای مشخص را به سرورهای مشخص هدایت کند و کلاینت VPN نیز ممکن است قواعدی آنجا نصب کند. سیاست را بررسی کنید، نه فقط فهرست DNS آداپتور را. در Linux، NetworkManager یا systemd-resolved می‌توانند مالک پیکربندی باشند، و اینکه کدام‌یک مالک است تعیین می‌کند اتصال دوباره چه چیزی را حفظ خواهد کرد.

وضعیت مؤثر را با ابزاری بخوانید که واقعاً به پرس‌وجوها پاسخ می‌دهد: resolvectl query internal.example.net روی میزبان systemd-resolved، یا معادل همان بستر. سپس آن پاسخ را با سرور DNS که لاگ کلاینت می‌گوید فرستاده، مقایسه کنید.

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

اسکریپت‌ها و foreign_option

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

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

نام را آزمایش کنید، نه لاگ را

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

اگر نام حل می‌شود اما سرویس شکست می‌خورد، به‌جای تغییر دوباره DNS به مسیریابی و دسترسی برنامه‌ها بروید. راهنمای OpenVPN گزینه dhcp-option و محیط اسکریپت را مستند می‌کند؛ از آن برای تأیید آنچه انتظار می‌رود کلاینت شما اعمال کند پیش از ویرایش فایل حل‌کننده دیگر استفاده کنید.