آداپتور TAP در OpenVPN نصب نشد: کدام مرحله شکست؟

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

پیش از هر چیز شماره‌ی بیلد و مهر زمان نصب را جمع کنید. هر دو یک پوشه از گزارش‌ها را به جست‌وجویی تبدیل می‌کنند که واقعاً می‌توانید اجرا کنید.

سه مرحله، سه گزارش متفاوت

مرحله‌ی اول خود نصب‌کننده است که فایل‌ها را باز می‌کند، گزارش خودش را نگه می‌دارد و کد خلاصه‌ای مانند 1603 را گزارش می‌کند که می‌گوید تراکنش شکست خورده بدون اینکه بگوید کجا. مرحله‌ی دوم مخزن درایور است که بسته‌ی امضاشده در آن برای استفاده‌ی بعدی آماده می‌شود، و این دستاوردی متفاوت از اتصال آن به سخت‌افزار است. مرحله‌ی سوم ایجاد دستگاه است که Windows نمونه‌ای از دستگاه می‌سازد، INF را اعمال می‌کند و نتیجه را در گزارش setupapi ثبت می‌کند. هر شکاف خاموش میان هر دو مرحله از این مراحل همان جمله را برای کاربر تولید می‌کند.

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

setupapi.dev.log را پیرامون تلاش بخوانید

هر نصب دستگاه بخشی را در C:\Windows\INF\setupapi.dev.log می‌نویسد، و راهنمای گزارش SetupAPI توضیح می‌دهد که این بخش‌ها و وضعیت نهایی‌شان چگونه سازمان یافته‌اند. بخشی را پیدا کنید که مهر زمانش تلاش شما را در بر می‌گیرد، سپس همه‌ی آن را بخوانید نه اولین خط خطایی که به آن توجه می‌کنید. هشدارهای مربوط به دستگاه‌های نامرتبط در سراسر یک گزارش طولانی ظاهر می‌شوند و چیزی درباره‌ی این خرابی توضیح نمی‌دهند. وضعیت نهایی بخش منطبق، واقعیتی است که ارزش نقل در گزارش را دارد.

آن بخش را با نام آداپتور، شناسه‌ی دستگاه و بسته‌ی INF که در گزارش نصب‌کننده آمده مرتبط کنید. سه شناسه که در یک مهر زمان توافق دارند همان چیزی است که انتساب را مطمئن می‌کند.

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

بسته‌ی آماده‌شده تنها اثبات می‌کند که یک INF امضاشده به مخزن درایور رسیده است. در این نسل از Windows، pnputil /enum-drivers بسته‌های شخص ثالث را بر اساس ارائه‌دهنده، کلاس، نسخه و نام منتشرشده فهرست می‌کند، که به شما امکان می‌دهد بسته‌ی آداپتور OpenVPN را بیابید به‌جای حدس زدن از شماره‌ی oem. هیچ چیز در آن فهرست نمی‌گوید دستگاهی وجود دارد، راه‌اندازی شده یا به بسته‌ای که یافتید متصل است. این‌ها پرسش‌های جداگانه‌ای با پاسخ‌های جداگانه‌اند.

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

پیش از دست زدن به امضاها آداپتور را بررسی کنید

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

pnputil /enum-drivers
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status
Get-PnpDevice -Class Net | Where-Object Status -ne 'OK'

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

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