چه کسی واقعاً تنظیمات DNS اوپن‌کانکت را در ویندوز اعمال می‌کند؟
ویندوز وضعیت حل‌کننده را در سه جا نگه می‌دارد. پیش از ویرایش دستی DNS آداپتور یا افزودن قاعده فضای نام، کمکی‌ای را که مالک اتصال است پیدا کنید.
بالا آوردن تونل همان نصب مقادیر DNS آن نیست. اوپن‌کانکت مذاکره می‌کند و یک کمک‌کننده در سمت ویندوز اعمال می‌کند. فاصله میان این دو گام بیشتر شکست‌های نام‌های خصوصی را در این کارخواه توضیح می‌دهد، و کمک‌کننده تقریباً هرگز صفحه تنظیمات VPN ویندوز نیست.
آنچه دروازه ارائه کرده را از آنچه ویندوز نصب کرده جدا کنید
کارخواه داده‌های اتصال را به یک واسط اسکریپت می‌سپارد و نسخه‌های یونیکس و ویندوز برنامه‌های جداگانه‌ای هستند. در ویندوز پیاده‌سازی معمولاً یک کمک‌کننده جاوااسکریپت است که متغیرهایی مانند سرور DNS داخلی و دامنه داخلی را پیش از دست زدن به هر آداپتوری می‌خواند. هیچ چیز در خود تونل وضعیت حل‌کننده را نمی‌نویسد.
این جداسازی مهم است، چون یک مقدار می‌تواند در مذاکره وجود داشته باشد و هرگز به آداپتور نرسد. کمک‌کننده‌ای که غایب است، نیمه‌راه شکست می‌خورد یا نسخه قدیمی‌تری است که در پوسته GUI جا داده شده، ویندوز را دقیقاً همان‌گونه که بود رها می‌کند. نشست متصل به نظر می‌رسد، نام خصوصی هنوز از طریق ارائه‌دهنده محلی حل می‌شود و هیچ چیز در پنجره کارخواه به تفاوت اشاره نمی‌کند. خواندن خروجی خود کمک‌کننده تنها راه مطمئن برای فهمیدن این است که کدام مرحله شکسته است.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
پوسته GUI ممکن است نسخه خودش از کارخواه و کمک‌کننده را همراه داشته باشد، بنابراین وجود یک openconnect.exe دوم جای دیگری روی دیسک چیزی را ثابت نمی‌کند. پیش از داوری درباره پیکربندی‌اش، فایل اجرایی‌ای را که نشست را آغاز کرد پیدا کنید.
وضعیت حل‌کننده را بدون تغییر خواندن کنید
سه پرس‌وجوی فقط-خواندنی ابهام معمول را پوشش می‌دهند و هر کدام به پرسشی متفاوت پاسخ می‌دهند:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveسرور در سطح آداپتور همان چیزی است که بیشتر مردم از DNS وی‌پی‌ان می‌فهمند. پسوند مخصوص اتصال تعیین می‌کند که آیا نام کوتاه اصلاً گسترش می‌یابد. فهرست خط‌مشی فضای نام بر نام‌های منطبق صرف‌نظر از ترتیب آداپتورها اعمال می‌شود، و نتیجه خالی در آنجا وقتی کمک‌کننده هرگز قصد ساختنش را نداشته عیب نیست. خواندن هر سه پیش از ویرایش همان چیزی است که از تعمیری جلوگیری می‌کند که فقط نشانه را جای دیگری می‌برد.
با نام کاملاً واجد شرایط شروع کنید. اگر FQDN حل می‌شود و نام کوتاه نه، شکاف پسوند یا فهرست جستجو است، نه نشانی سرور.
به‌عنوان گام دوم مستقیماً از سرور موردنظر بپرسید، با هر ابزار حل‌کننده‌ای که از قبل نصب شده است. پاسخ مستقیم ثابت می‌کند سرور قابل دسترس و برای ناحیه معتبر است. درباره اینکه یک برنامه به‌طور پیش‌فرض از کدام سرور می‌پرسد چیزی ثابت نمی‌کند.
مؤلفه‌ای را که مالک اتصال است نام ببرید
دو آرایش رایج است. کارخواهی که از پایانه آغاز می‌شود مسیر اسکریپت خود را صریح می‌فرستد، پس مالک در فرمان اجراشده دیده می‌شود. برنامه بسته‌بندی‌شده خودش کارخواه را برای شما آغاز می‌کند و کمک‌کننده را در پوشه خودش نگه می‌دارد، یعنی فروشنده تعیین می‌کند چه وقت تغییر کند.
پیش از جایگزینی هر چیزی، نسخه‌های کمک‌کننده را میان نصب‌ها مقایسه کنید. اجرای کمک‌کننده‌ای که از یک آینه گرفته شده با اختیارات بالا چون نام فایل آشنا به نظر می‌رسد، یک شکاف DNS را به حادثه امنیتی تبدیل می‌کند.
وقتی مالک شناخته شد، هدف تعمیر آشکار می‌شود: مسیر اسکریپت پشتیبانی‌شده در راه‌انداز، به‌روزرسانی بسته، یا نمایه اصلاح‌شده روی دروازه. هیچ‌کدام نیازی به ویرایش دستی ویژگی‌های آداپتور ندارد.
مالک را درست کنید، نه آداپتور را
DNSای که دستی روی آداپتور تنظیم شده اغلب پس از قطع اتصال می‌ماند، به همین دلیل به نظر می‌رسد کار می‌کند و بعد در شبکه بعدی دردسر می‌سازد. حل‌کننده عمومی پیچ‌شده روی هر واسط، مشکل فضای نام خصوصی را به‌جای حل کردن پنهان می‌کند. وقتی کمک‌کننده هرگز مقدار DNS دریافت نکرده، نمایه دروازه جایی است که باید نگاه کرد. وقتی دریافت کرده و آداپتور هنوز سرور قدیمی را نشان می‌دهد، کمک‌کننده در هنگام اتصال شکست خورده و گزارش کارخواه معمولاً آن را نزدیک خطوط راه‌اندازی تونل ثبت می‌کند.
وضعیت را از مسیر پشتیبانی‌شده بازسازی کنید، سپس یک چرخه کامل را بررسی کنید: وصل شوید، FQDN خصوصی را حل کنید، سرویس را باز کنید، قطع کنید و تأیید کنید که آداپتور با سرورهای پیشین خود بازگشته است.
برنامه‌ای را که واقعاً شکست می‌خورد بررسی کنید
مرورگری با تنظیم DNS رمزنگاری‌شده خودش همه موارد بالا را نادیده می‌گیرد و همچنان از یک حل‌کننده عمومی پاسخ می‌دهد. برنامه‌ای که پاسخ منفی ذخیره‌شده از پیش از بالا آمدن تونل را نگه می‌دارد همان رفتار را دارد. پیش از تغییر دوباره نشانی‌های حل‌کننده، آن را با یک پرس‌وجوی ساده سامانه روی همان ماشین مقایسه کنید.
اگر پرس‌وجوی سامانه درست است و برنامه نادرست، خطای باقی‌مانده درون پیکربندی DNS همان برنامه است، نه در مسیر VPN.