سرور DNS اشتباه در VPN ویندوز: متریک، ترتیب اتصال یا پسوند
سه سازوکار ویندوز ریزالور DNS را انتخاب می‌کنند و هر یک به شکلی متفاوت شکست می‌خورند. بر پایه دامنه فضای نام، ترتیب سراسری یا اینکه آیا اصلاح پس از اتصال دوباره دوام می‌آورد تصمیم بگیرید.
ممکن است یک کلاینت ویندوز تونلی سالم داشته باشد، ریزالور شرکتی را حمل کند و باز هم نام‌های داخلی را به روتر خانه بفرستد. سه سازوکار مختلف تعیین می‌کنند کدام سرور پاسخ می‌دهد و هر یک به شکلی متفاوت شکست می‌خورند. لازم نیست هر سه را اصلاح کنید: نشانه به شما می‌گوید کدام یک در میان است. درخت تصمیم زیر چند دقیقه وقت می‌گیرد و از نتیجه معمول جلوگیری می‌کند، جایی که تغییر متریک، بازآرایی رجیستری و یک قاعده NRPT با هم می‌رسند و هیچ‌کس نمی‌داند کدام یک کاری کرده است.
سه سازوکار تصمیم می‌گیرند و معمولاً یکی اشتباه است
متریک رابط، آداپترها را برای یک خانواده نشانی معین مرتب می‌کند. ترتیب اتصال زیر Tcpip\Linkage فهرستی ماشینی از شناسه‌های رابط است که مسیرهای کد قدیمی‌تر هنوز به آن مراجعه می‌کنند. جدول خط مشی تفکیک نام (NRPT) یک فضای نام را به سرورهای مشخصی می‌بندد و فهرست پسوندها تعیین می‌کند که آیا نام کوتاه اصلاً گسترش می‌یابد یا نه. این‌ها مستقل‌اند و به همین دلیل ریزالور درست روی آداپتر VPN در برابر ترجیح کهنه‌ای در جای دیگر می‌بازد.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
هیچ‌یک از این سازوکارها آن سوی تونل نیست. اگر سروری که VPN هل می‌دهد نتواند نام را تفکیک کند، هر تنظیمی در سمت کلاینت فقط تزئین است، پس نخستین تصمیم این است که آیا خود ریزالور وقتی مستقیم پرسیده می‌شود می‌تواند پاسخ دهد.
تصمیم یک: آیا ریزالور هل داده شده اصلاً می‌تواند پاسخ دهد؟
صریح از سرور بپرسید و آن را با یک جست‌وجوی معمولی مقایسه کنید. شکاف میان پاسخ‌ها مسئله انتخاب را از مسئله دسترسی جدا می‌کند و اینجا سریع‌ترین دوراهی است:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aاگر اولی موفق و دومی ناموفق باشد، ریزالور در دسترس است و ویندوز بد انتخاب می‌کند؛ به تصمیم‌های فضای نام و ترتیب در پایین بروید. اگر اولی هم ناموفق باشد، هیچ‌چیز روی کلاینت کمکی نمی‌کند: بررسی کنید که UDP و TCP 53 از تونل به سرور برسند، فایروال میزبان روی سرور استخر را دور نریزد و ارسال‌کننده‌های خود سرور سالم باشند.
در همین دوراهی بایستید. اعمال یک قاعده NRPT بر ریزالوری که به آن دسترسی ندارید همان خرابی را با پیکربندی بیشتری برای برگرداندن تولید می‌کند و عیب واقعی را پشت قاعده‌ای پنهان می‌کند که معتبر به نظر می‌رسد.
تصمیم دو: یک فضای نام یا هر پرس‌وجو؟
دامنه ابزار را تعیین می‌کند. وقتی فقط نام‌های شرکتی شکست می‌خورند، فضای نام را ببندید نه اینکه ماشین را بازآرایی کنید: قاعده NRPT آن پسوند را به ریزالور تونل می‌فرستد و بقیه را به حال خود می‌گذارد. وقتی هر جست‌وجو تحت تأثیر است، مشکل ترجیح سراسری آداپترهاست و متریک جای شروع است، چون هیچ تنظیمی روی سرور را تغییر نمی‌دهد.
متریک را برای هر خانواده نشانی، روی هر دو رابط تنظیم کنید و سپس ترتیب را تأیید کنید:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv611 را با ifIndex آداپتر تونل از سطر بالا جایگزین کنید؛ اگر 11 آداپتر LAN است، همان فرمان مسیر اشتباه را پایین می‌آورد. بالا بردن آداپتر LAN به جای آن همان ترتیب را از سوی دیگر می‌رساند: netsh int ip set interface interface="Ethernet" metric=15، و برای خانواده دوم netsh int ipv6 set interface interface="Ethernet" metric=15، چون int ip فقط IPv4 را لمس می‌کند.
ترتیب اتصال آخرین راه است نه نخستین گام. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage فهرستی Bind از شناسه‌های دستگاه دارد و آوردن شناسه تونل به جلو واقعاً تغییر می‌دهد کدام آداپتر اول پرسیده شود، اما این یک مقدار رجیستری ماشینی بدون دامنه برای هر فضای نام است. پیش از ویرایش آن را صادر کنید و پس از آن تونل را دوباره وصل کنید تا ترتیب در حالتی که کلاینت انتظار دارد اعمال شود.
برای یک فضای نام واحد، ابزار باریک‌تر را ترجیح دهید:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersتصمیم سه: آیا اصلاح پس از اتصال دوباره دوام می‌آورد؟
متریکی که تا اتصال دوباره شماره‌گیری بعدی کار می‌کند هرگز ذخیره نشده بود. L2TP/IPsec و سایر پروفایل‌های اتصال هنگام شروع اتصال از نو ساخته می‌شوند، پس مقدار ذخیره‌شده در ورودی دفترچه تلفن به صورت IpInterfaceMetric زندگی می‌کند، نه فقط روی رابط زنده. برخی محیط‌ها آن فیلد را دقیقاً به همین دلیل اسکریپت می‌کنند؛ برخی دیگر ترجیح را از خط مشی مدیریت هل می‌دهند و نقطه پایانی را به حال خود می‌گذارند.
حافظه نهان و ثبت جداگانه‌اند. اجرای این‌ها پس از بالا آمدن تونل ورودی‌های کهنه را اصلاح می‌کند و کلاینت را دوباره ثبت می‌کند، اما هیچ‌یک آداپتری را بازآرایی نمی‌کند:
ipconfig /registerdns
ipconfig /flushdnsدر همان لایه یک کلید خاموشی هست. غیرفعال کردن ثبت پویا روی آداپتر فیزیکی مانع از آن می‌شود که کلاینت نشانی سمت VPN خود را با نام اشتباه اعلام کند و این تعمیری متفاوت از تازه‌سازی بالاست.
IPv6 در این تصمیم سطر خودش را می‌خواهد. اگر آداپتر فیزیکی نشانی سراسری IPv6 داشته باشد در حالی که تونل فقط IPv4 حمل می‌کند، ویندوز می‌تواند برای تفکیک نام مسیر بدون تونل را ترجیح دهد. آن خانواده را جداگانه بررسی کنید، چون متریکی که برای IPv4 تنظیم شده هیچ چیزی درباره آن نمی‌گوید:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricغیرفعال کردن IPv6 روی آداپتر LAN آن مسیر و پروتکل را با آن حذف می‌کند؛ تغییر متریک روی رابط IPv6 یا یک قاعده NRPT برای فضای نام شرکتی خانواده را نگه می‌دارد و ترجیح را اصلاح می‌کند. باریک‌تر را انتخاب کنید مگر آنکه تصمیم گرفته باشید آن پیوند نباید IPv6 داشته باشد.
با منبع نام‌برده بررسی کنید و یک مالک نگه دارید
با ابزارهایی بررسی کنید که گزارش می‌دهند کدام منبع در کار است، نه فقط اینکه صفحه‌ای بار می‌شود:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aسپس پالایش را از انتخاب جدا کنید، چون از درون یک برنامه یکسان به نظر می‌رسند. block-outside-dns در OpenVPN پورت 53 را روی آداپترهای دیگر مسدود می‌کند؛ ریزالور انتخاب نمی‌کند. اگر اکنون هر پرس‌وجو شکست بخورد، ممکن است یک پالایه تنها سرور در دسترس را مسدود کرده باشد؛ اگر ریزالور پیکربندی‌شده نادیده گرفته می‌شود، ترتیب یا قاعده فضای نام اشتباه است. تغییر هر دو با هم پرس‌وجوی مسدود و پرس‌وجوی نادیده‌گرفته‌شده را از هم تشخیص‌ناپذیر می‌کند.
یک مالک برای خط مشی DNS نگه دارید: پروفایل VPN، یک خط مشی مدیریت یا یک قاعده NRPT، نه دو تا از آن‌ها. پیش از بستن کار:
- ریزالور هل داده شده وقتی صریح نام برده شود پاسخ می‌دهد و جست‌وجوی معمولی از آن استفاده می‌کند.
- قاعده یا متریکی که تغییر داده‌اید خانواده نشانی‌ای را پوشش می‌دهد که واقعاً پرس‌وجوها را حمل می‌کند.
- تنظیم از قطع و وصل دوباره جان سالم به در می‌برد، یا آن را به پروفایل ذخیره‌شده منتقل کرده‌اید.
- دقیقاً یک سازوکار معتبر است و بقیه به حال خود رها شده‌اند.
ترتیب را وضعیت محیطی بدانید نه چیزی که تمامش می‌کنید. پس از اتصال دوباره و پس از به‌روزرسانی ویندوز که پشته شبکه را لمس می‌کند دوباره بررسی کنید، چون هر یک از این دو می‌تواند آداپتر فیزیکی را دوباره به جلو بیاورد.