تنظیم DNS روی آداپتور VPN ویندوز با PowerShell و سپس بررسی آن

اتصال VPN در ویندوز سرورهای DNS را در پروفایلی که در تنظیمات ویرایش می‌کنید ذخیره نمی‌کند. وقتی تونل بالا می‌آید، کلاینت پیکربندی IP را با دروازه مذاکره می‌کند، دروازه فهرستی از حل‌کننده‌ها می‌فرستد و ویندوز آن را روی آداپتور تونل اعمال می‌کند. آن آداپتور رابطی جداست از Wi-Fi یا Ethernet شما، و فهرست به رابط تعلق دارد، نه به پروفایل. وقتی بدانید کدام شیء مالک مقدار است، بازنویسی آن در PowerShell یک دستور است؛ ماندگار کردن بازنویسی پس از اتصال مجدد بخشی است که به تصمیم نیاز دارد.

کدام شیء مالک نشانی است

RAS آداپتور تونل را وقتی اتصال موفق شود می‌سازد و وقتی اتصال قطع شود آن را برمی‌دارد. سرورهای DNS که در ipconfig /all می‌بینید در همان تبادل پیکربندی می‌رسند، کنار نشانی‌های IPv4 و IPv6 و مسیرها. چون مقدار به رابط متصل است، Set-DnsClientServerAddress در چیزی می‌نویسد که فقط تا وقتی اتصال وجود دارد وجود دارد.

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

پیش از دست زدن به DNS نام مستعار را پیدا کنید

نام پروفایل و نام مستعار رابط معمولاً یک رشته‌اند، اما یک شیء نیستند. Get-VpnConnection پروفایل‌ها را فهرست می‌کند؛ Get-NetAdapter رابط‌هایی را فهرست می‌کند که ویندوز واقعاً دارد. دستورهای DNS دومی را می‌خواهند، و این دو بیشتر از آنچه مردم انتظار دارند از هم جدا می‌شوند، به‌ویژه وقتی کلاینت توصیفگری مانند "(RAS)" به نام آداپتور می‌افزاید.

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

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

یک بار متصل شوید، سپس پیش از نوشتن هر دستور DNS نام مستعار واقعی را بخوانید:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

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

ترتیب از نحو مهم‌تر است. آداپتور باید بالا باشد، نام مستعار باید حل شود و حساب باید اجازه تغییر تنظیمات رابط را داشته باشد. اتصال هر کاربر معمولاً تغییر را از کاربر واردشده می‌پذیرد؛ اتصال همه کاربران که با -AllUserConnection ساخته شده است معمولاً به پوسته ارتقایافته نیاز دارد.

خود دستور یک خط است، مستندشده در مرجع Set-DnsClientServerAddress:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

چرا اتصال مجدد می‌تواند تغییر را باطل کند

بازنویسی به یک نمونه رابط تعلق دارد. وقتی کلاینت آداپتور را پایین می‌آورد و در اتصال بعدی دوباره می‌سازد، مقادیر فرستاده‌شده دوباره اعمال می‌شوند و فهرست شما از بین می‌رود. برخی کلاینت‌ها رابط را در هر اتصال از نو می‌سازند؛ برخی دیگر آن را در تمام نشست دوباره به کار می‌برند. شاخص رابط را در Get-NetAdapter بین دو اتصال مقایسه کنید تا بدانید کدام رفتار را دارید.

سه پاسخ پایدار وجود دارد و روی هم چیدنشان خطاهای خودش را می‌سازد. پسوند DNS مخصوص اتصال به‌همراه یک قاعده NRPT تنها فضای نام داخلی را به حل‌کننده داخلی می‌فرستد و نام‌های عمومی را به حال خود می‌گذارد. تنظیم Group Policy یا MDM که روی اتصال VPN اعمال شود DNS را هنگام اتصال بدون هیچ اسکریپتی تنظیم می‌کند. وظیفه زمان‌بندی‌شده‌ای که به رویداد اتصال واکنش نشان دهد و دستور را دوباره اجرا کند گزینه زمخت است، اما کار می‌کند و گزارش باقی می‌گذارد. یک مالک برای DNS انتخاب کنید و بنویسید کدام است.

نام‌های داخلی تک‌برچسبی هم به فهرست جست‌وجوی پسوند نیاز دارند. Set-DnsClientGlobalSetting -SuffixSearchList برای کل ماشین است، پس حل را برای هر آداپتور روی دستگاه تغییر می‌دهد، از جمله Ethernet. آن را روی ماشین آزمایشگاهی پیش از رفتن به تصویر امتحان کنید.

حل را بررسی کنید، نه فقط تنظیم را

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

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

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

آزمایش را دو بار اجرا کنید، یک بار درست پس از اتصال و یک بار پس از قطع و اتصال مجدد، و Get-DnsClientServerAddress خروجی هر دو اجرا را مقایسه کنید. اگر مقدار فرستاده‌شده در اتصال دوم برگشته باشد، بازنویسی با آداپتور زیسته و مرده است، و تنها مسیر NRPT یا سیاست از بخش پیشین دوام می‌آورد. هر دو رونوشت و مهرهای زمانی اتصال را نگه دارید؛ آن‌ها پرسش ماندگاری را سریع‌تر از یک دور ویرایش دیگر حل می‌کنند.