VPN کنترل DNS را در دست گرفت و نام‌های محلی را شکست: فهرست را درست کنید

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

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

کدام فهرست را برنامه‌ها واقعاً استفاده می‌کنند

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

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

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

خروجی را برای آداپتور تونل و برای آداپتور فیزیکی بخوانید و هر نشانی روی هر کدام را یادداشت کنید. ورودی ثابت را می‌توان با خط‌مشی یا اسکریپت حذف کرد؛ ورودی‌ای که DHCP می‌دهد به اجاره بسته است و برمی‌گردد، و این ترمیمی را که باید انتخاب کنید تغییر می‌دهد. نام‌های شبکه دور توسط حل‌کننده اعلام‌شده حل می‌شوند، نام‌های LAN محلی توسط آداپتور فیزیکی، و پرس‌وجو به فهرستی می‌رود که اول مشورت می‌شود.

سرورهای هل داده شده را حذف کنید یا آنها را پایین‌تر بچینید

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

شاخص 1 اول مشورت می‌شود، بنابراین نشانی‌های هل داده شده در دسترس می‌مانند اما دیگر پاسخ پیش‌فرض هر پرس‌وجو نیستند. پرچم validate=no یک آزمون دسترس‌پذیری را رد می‌کند که اغلب در حالی که تونل هنوز جا می‌افتد شکست می‌خورد، پس نتیجه را با فرمان show تأیید کنید نه اینکه به کد خروج اعتماد کنید.

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

کجا می‌توان push را فیلتر کرد

ترمیم بهتر گزینه را پیش از اعمال برمی‌دارد. کلاینت Community OpenVPN می‌تواند یک دستور هل داده شده را با نام فیلتر کند، که پیکربندی سرور را دست‌نخورده می‌گذارد.

pull-filter ignore "dhcp-option DNS "

فاصله انتهایی به تطبیق تعلق دارد و فیلتر گزینه را نام می‌برد نه نشانی سرور را. اگر پروفایل دستور block-outside-dns را هم داشته باشد، حذف آن حفاظت نشتی را عوض می‌کند نه حل نام را، پس آن را جداگانه تصمیم بگیرید نه اینکه دو ویرایش را با هم ببندید.

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

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

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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