DNS ارسال‌شده توسط OpenVPN نادیده گرفته می‌شود: کدام مؤلفه آن را اعمال می‌کند

گزارش نشان می‌دهد گزینه‌ای که سرور فرستاده حاضر است، تونل بالاست، و نام‌های داخلی همچنان شکست می‌خورند. پرس‌وجوی مستقیم به ریزولور پاسخ می‌دهد، پس سرور سالم است، اما هر برنامه همچنان از روتر محلی می‌پرسد. آنچه به کلاینت رسیده یک پیشنهاد است، نه تغییری در ریزولور، و مؤلفه‌ای که مالک حل نام است در Linux، Windows و macOS متفاوت است. به‌محض اینکه گزینه را از مالکش جدا کنید، چهار خطا تقریباً هر گزارشی را پوشش می‌دهند: نبود هوک، دو هوک رقیب، DNS تفکیک‌شده که مطابق طراحی کار می‌کند، یا نام کوتاهی که به پسوند نیاز دارد نه به سرور.

گزینه ارسال‌شده یک پیشنهاد است، نه نصب

روی سرور، دو دستور نیت را توصیف می‌کنند نه اثر را:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

سه مرحله بین دو سر قرار دارد: ارسال باید برسد، کلاینت باید آن را آشکار کند، و یک هوک باید اعمالش کند. مرحله میانی را در گزارش کلاینت و مرحله آخر را در وضعیت ریزولور بخوانید، هرگز برعکس، چون یک خط گزارش فقط دو مرحله اول را اثبات می‌کند.

تأیید کنید که ارسال رسیده و مالک را پیدا کنید

با نام بردن راه‌انداز شروع کنید: یک openvpn دستور خالی، یک نمونه systemd، NetworkManager یا کلاینت فروشنده. همین تعیین می‌کند هوک کجا می‌تواند زندگی کند. روی میزبان دارای systemd-resolved، resolvectl status هر پیوند را با سرورهای DNS و دامنه‌های جست‌وجویی که واقعاً استفاده می‌کند فهرست می‌کند، و پیوند تونل همیشه tun0 نامیده نمی‌شود.

اگر نشانی ارسال‌شده در گزارش دیده می‌شود اما روی هیچ پیوندی نیست، یکپارچه‌سازی وجود ندارد. اگر روی پیوند هست و پرس‌وجوها هنوز جای دیگری می‌روند، مشکل این است که کدام پرس‌وجوها آن پیوند را انتخاب می‌کنند. NetworkManager dns=dnsmasq در فایل /etc/NetworkManager/NetworkManager.conf یک ارسال‌کننده محلی اجرا می‌کند که DNS تفکیک‌شده را عمداً پیاده می‌کند: نام‌های داخل دامنه VPN به ریزولور VPN می‌روند و بقیه مسیر قبلی را حفظ می‌کنند. این رفتار وقتی انتظار داشتید همه ترافیک جابه‌جا شود مانند خطا دیده می‌شود؛ تنظیمات هر اتصال را با nmcli connection show "My VPN" بررسی کنید، جایی که ipv4.dns و ipv4.dns-search مقادیر پشت آنچه دستگاه گزارش می‌کند را نگه می‌دارند، پیش از آنکه آن را خراب بنامید. اگر واقعاً هر پرس‌وجو باید به ریزولور VPN برسد، dns=dnsmasq را از NetworkManager.conf حذف کنید و NetworkManager را دوباره راه‌اندازی کنید، که حل نام را به تنظیمات اتصال برمی‌گرداند؛ در غیر این صورت DNS تفکیک‌شده را نگه دارید و فهرست دامنه‌های ارسال‌شده را تصحیح کنید.

Linux: گزینه‌ها را به ریزولور بسپارید

بسته‌های توزیع برای این کار هوکی همراه دارند و کلاینت باید اجازه اجرای آن را داشته باشد. چیدمان معمول روی میزبانی بدون systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

با systemd-resolved، اسکریپت قدیمی resolv.conf ممکن است چیز مهمی تغییر ندهد، چون ریزولور stub وضعیت هر پیوند را نگه می‌دارد. update-systemd-resolved ابزار کمکی شکلی از هوک را مستند می‌کند که up-restart و down-pre را به کار می‌برد، که وقتی یک رابط بیش از یک تلاش اتصال دوام می‌آورد اهمیت دارد. هر چه انتخاب کنید، یک مؤلفه باید مالک وضعیت باشد. افزودن هوکی بی‌ربط کنار NetworkManager به یک پیوند دو نویسنده می‌دهد و نتیجه آن‌گاه به ترتیب بستگی دارد نه به پیکربندی شما.

موردی هم هست که NetworkManager گزینه ارسال‌شده را کاملاً نادیده گرفت تا وقتی نشانی سرور در تنظیمات IPv4 اتصال وارد شد، و پس از آن وضعیت ریزولور نشان داد که در حال استفاده است. ارزش امتحان کردن پیش از بازنویسی اسکریپت‌ها را دارد، چون مشکل را از هوک پوسته به پروفایل اتصالی منتقل می‌کند که تونل را از قبل حمل می‌کند.

Windows و macOS بخش‌های متفاوتی را اعمال می‌کنند

کلاینت Windows واقعاً سرورهای DNS آداپتور VPN را تنظیم می‌کند، اما Windows همچنان رابط را بر اساس متریک انتخاب می‌کند و هنوز برای گسترش نام کوتاه به پسوند نیاز دارد. وضعیت آداپتور را تأیید کنید نه پروفایل را:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

اگر نشانی نیست، آن را با این تنظیم کنید Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1، سپس پسوند را به ویژگی‌های IPv4 آداپتور بیفزایید تا fileserver تبدیل شود به fileserver.corp.example. یک SearchList در سطح ماشین زیر Tcpip\Parameters همان کار را می‌کند. جایی که نام بلند حل می‌شود و نام خالی نه، ریزولور از قبل درست است و فهرست جست‌وجو خطاکار است. اصلاح‌ها به ترتیب: DOMAIN را ارسال کنید تا کلاینت پسوند را بیاموزد، آن پسوند را به فهرست جست‌وجوی آداپتور یا اتصال بیفزایید، و به‌عنوان اقدامی موقت نام را در hosts ثابت کنید، یا در LMHOSTS روی Windows؛ مرور NetBIOS از روتر عبور نمی‌کند، پس پخشی که نام کوتاه را در LAN اداری پیدا می‌کند هرگز به کلاینت تونل نمی‌رسد.

block-outside-dns block-outside-dns رفتاری از کلاینت Windows است، نه خطی قابل‌حمل در پروفایل، و کپی کردنش به پروفایل Linux یا macOS آن را در آنجا بازتولید نمی‌کند. اگر نام‌های عمومی کار کنند و داخلی‌ها روی Windows شکست بخورند، ترتیب آداپتورها را در تنظیمات پیشرفته با ipconfig /all بسنجید. در macOS ترتیب ریزولور برای هر سرویس متعلق به سیستم است، پس از scutil --dns استفاده کنید تا ببینید برای هر دامنه کدام ریزولور پرسیده می‌شود، و هر اصلاح پروفایل که گزارش می‌شود را وابسته به کلاینت بدانید نه عمومی.

ماشین مجازی روی همان لپ‌تاپ هیچ‌چیز از این را به ارث نمی‌برد. به مهمان برای دامنه داخلی ورودی ریزولور خودش را بدهید، یا بگذارید NAT هایپروایزر پرس‌وجوهایش را از طریق میزبان هدایت کند، که فقط تا وقتی تونل میزبان بالاست درست است.

تاریخچه سومین علت است. سرورهای DNS یا تنظیمات پسوند از پروفایل قبلی می‌توانند از اتصال‌های دوباره جان سالم به در ببرند، پس وقتی آداپتور درست به نظر می‌رسد و جست‌وجوها همچنان شکست می‌خورند، آداپتور زنده را با Get-VpnConnection مقایسه کنید و پیش از دست زدن به سرور، ورودی کهنه را پاک یا بازنویسی کنید.

اثبات کنید پرس‌وجو کجا رفت

یک ضبط در طول یک جست‌وجو بحث را تمام می‌کند: tcpdump -ni eth0 port 53 پرس‌وجوها را روی رابط فیزیکی نشان می‌دهد، یعنی از بیرون تونل خارج می‌شوند و ریزولور هرگز عوض نشده است. dig @10.8.0.1 name.corp.example سپس دو حالت باقی‌مانده را جدا می‌کند. اگر پرس‌وجوی مستقیم پاسخ دهد، ریزولور کار می‌کند و کلاینت از آن استفاده نمی‌کند؛ اگر زمان تمام شود، ریزولور از طریق تونل در دسترس نیست و هیچ تغییری در محل کمکی نمی‌کند.

اگر ریزولورِ هنوز در حال استفاده همانی است که ارائه‌دهنده داده، تونل ترافیک را رمز می‌کند در حالی که نام‌ها برای آن ارائه‌دهنده قابل مشاهده می‌مانند. این پرسشی درباره نشت است نه عملکرد، و همان ضبط پاسخش را می‌دهد: پرس‌وجو روی رابط فیزیکی به جایی بیرون تونل می‌رود.

دسترس‌پذیری شامل فایروال روی میزبان VPN است که باید UDP و TCP 53 را از استخر اجازه دهد. دروازه بسته درست مثل ارسال خراب به نظر می‌رسد، و همچنین ریزولوری که فقط از داخل شبکه تونل پاسخ می‌دهد. ضبط را پس از یک قطع و وصل دوباره تکرار کنید، چون تنظیماتی که در اتصال اول پدیدار و در دومین ناپدید می‌شوند خطای چرخه حیات در هوک هستند، نه گزینه مفقود.

یک مالک نگه دارید و به ترتیب بررسی کنید

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

حلقه را با چهار بررسی ببندید: نشانی ارسال‌شده روی پیوند تونل حاضر باشد، نام داخلی به‌صورت نام کاملاً واجد شرایط حل شود، همان نام بدون پسوند حل شود، و هر دو پس از یک اتصال دوباره هنوز درست باشند. یک ضبط می‌گوید کدام‌یک از چهار مورد شکست خورده است. راهنمای OpenVPN 2.6 دستورهای dhcp-option و دستورهای اسکریپت را با یادداشت‌های پلتفرمی‌شان فهرست می‌کند.