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

گام یک: نمایه را جایی بگذارید که سرویس آن را جست‌وجو می‌کند

سرویس ویندوز نمایه‌ها را از یک پوشه ثابت می‌خواند و رابط گرافیکی از همان جا می‌خواند، بنابراین نمایه‌ای که هنگام درون‌ریزی کار می‌کند ممکن است هنگام بوت نامرئی بماند. فایل‌های .ovpn را در پوشه config نصب قرار دهید که معمولاً زیر Program Files است. نمایه‌ای که در پوشه Downloads یک کاربر رها شود اصلاً در گستره سرویس نیست.

راهنمایی‌های قدیمی‌تر به پوشه config-auto اشاره می‌کنند که برخی بیلدهای دوره 2.5 آن را رعایت می‌کردند و انتشارهای بعدی نه. به همین دلیل یک ارتقا می‌تواند یک راه‌اندازی خودکار سالم را به سکوت تبدیل کند، بدون آن که چیزی درباره اعتبارنامه‌ها در گزارش باشد. پیش از جابه‌جایی هر فایلی تأیید کنید که بیلد نصب‌شده واقعاً کدام پوشه را می‌خواند.

با چند نمایه روی یک ماشین، به هر یک از طریق dev-node یک آداپتور نام‌دار بدهید. وگرنه بر سر یک واسط رقابت می‌کنند و دومی به شکلی شکست می‌خورد که شبیه مشکل اعتبارنامه است.

گام دو: سرویس را اجرا کنید، نه آیکون سینی

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

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

بررسی کنید که حساب سرویس می‌تواند نمایه و مواد کلید را بخواند. مشکل مجوز هنگام بوت در گزارش دقیقاً مثل شکست احراز هویت دیده می‌شود.

گام سه: مسیر را به تونل ببندید

ورودی دائمی اینجا ابزار اشتباهی است. افزودن مسیر با -P باعث می‌شود از راه‌اندازی مجدد جان سالم به در ببرد و، بدتر، از بسته شدن تونل هم. وقتی VPN پایین است، پیشوند هنوز به دروازه‌ای اشاره می‌کند که دیگر نیست، پس میزبان تا وقتی کسی ورودی را پاک نکند به آن مقصد نمی‌رسد.

سه جایگزین درست رفتار می‌کنند. مسیر را از سرور هل بدهید که هنگام اتصال آن را اضافه و هنگام قطع آن را حذف می‌کند. آن را در یک اسکریپت route-up که route_vpn_gateway را می‌خواند اضافه کنید تا گام بعدی از تونل مذاکره‌شده بیاید. یا از Add-VpnConnectionRoute با یک نمایه بومی VPN ویندوز استفاده کنید که پیشوند را به آن اتصال می‌بندد.

وقتی سرور بیش از نیاز این سایت عرضه می‌کند، route-nopull مسیرهای هل داده‌شده را رد می‌کند و جدول را کاملاً محلی می‌گذارد. این با نمایه مشترکی سازگار است که کاربرانش نباید مسیر پیش‌فرض شرکتی بگیرند.

گام چهار: از یک بوت سرد جان سالم به در ببرید

اجرای سرویس پیش از وجود پشته شبکه یک تلاش ناموفق و بدون تکرار به بار می‌آورد. قرار دادن آن روی Automatic (Delayed Start)، یا افزودن وابستگی به سرویس شبکه، آن مسابقه را برمی‌دارد. سپس آزمون بوت را تکرار کنید و بررسی کنید که تلاش دوم دیگر لازم نیست.

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

توالی‌ای را بیازمایید که واقعاً مستقر می‌کنید، نه آن یکی که می‌توانید دستی راه بیندازید. بوت سرد تنها آزمونی است که ترتیب را تمرین می‌دهد.

گام پنج: بدون رابط گرافیکی بررسی کنید

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

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

مقالات مرتبط