مسیرهای ارسال‌شده OpenVPN نصب نمی‌شوند: زمان‌بندی، اختیارات یا سیاست
یک مسیر ارسال‌شده می‌تواند در یک مسابقه زمان‌بندی، اختیارات ناکافی یا سیاست کلاینت ناپدید شود. ابتدا فهرست ارسال سرور را با جدول واقعی مقایسه کنید.
سرور می‌گوید مسیر را ارسال کرده است، کلاینت می‌گوید متصل است، و مقصد هنوز غیرقابل‌دسترس است. سه علت دقیقاً همین تصویر را می‌سازند. افزودن مسیر پیش از وجود دستگاه اجرا شده بود، کلاینت اختیارات لازم برای تغییر جدول را نداشت، یا سیاستی به کلاینت گفته بود گزینه‌های ارسال‌شده را نادیده بگیرد.
از بیرون یکسان به نظر می‌رسند و اصلاح‌های متفاوتی می‌خواهند. گزارش کلاینت را در همان نقطه‌ای بخوانید که تصمیم درباره مسیر گرفته می‌شود.
ثابت کنید مسیر وجود ندارد، نه اینکه فقط خراب است
با اثبات اینکه مسیر غایب است و نه خراب شروع کنید. در لینوکس، ip route show dev tun0 فهرست می‌کند که کلاینت چه چیزی روی دستگاه تونل نصب کرده است. در ویندوز، route print یا Get-NetRoute همان چیز را به شکل جدول نشان می‌دهد.
مسیری که وجود دارد ولی ترافیک را هدایت نمی‌کند مشکلی دیگر است. این کار بررسی را به قواعد ارسال و دیوار آتش منتقل می‌کند، نه به نصب مسیر.
زمان‌بندی: افزودن پیش از وجود دستگاه اجرا شده بود
کلاینت PUSH_REPLY سرور را پس از برپا شدن کانال کنترل و پس از پیکربندی رابط تجزیه می‌کند. تنها آن‌گاه جدول مسیریابی را لمس می‌کند، با هر سازوکاری که سکو فراهم کند. لینوکس از netlink عبور می‌کند؛ ویندوز از API استفاده می‌کند که به توکن ارتقایافته نیاز دارد. اسکریپت یا کلاینتی که به‌محض خواندن پیکربندی مسیرها را اضافه می‌کند ممکن است پیش از وجود دستگاه TUN/TAP اجرا شود و هسته افزودن را رد می‌کند.
همین مسابقه توضیح می‌دهد چرا مسیری که با دست تایپ می‌شود کار می‌کند ولی مسیر خودکار نه: تا زمانی که آن را تایپ می‌کنید، رابط برپاست.
route-delay برای همین حالت وجود دارد، و route-up اسکریپتی را نام می‌برد که پس از پیکربندی رابط و مسیرها اجرا می‌شود. مسیرهایی را که به نشانی تونل وابسته‌اند در همان قلاب بگذارید، نه در مرحله‌ای زودهنگام.
اختیارات: چه کسی می‌تواند جدول را تغییر دهد
تغییر جدول مسیریابی ویندوز به توکن ارتقایافته نیاز دارد. رابط گرافیکی که کاربر عادی اجرا کرده باشد می‌تواند نشانی آداپتور را از طریق سرویس تنظیم کند و باز هم نتواند مسیری اضافه کند. آن‌گاه گزارش خطایی به سبک دسترسی رد شد نشان می‌دهد، نه ارسال گم‌شده.
اجرای رابط گرافیکی به‌عنوان مدیر، یا استفاده از کلاینت مبتنی بر سرویس، آن نتیجه را تغییر می‌دهد. وظیفه زمان‌بندی‌شده‌ای که کلاینت را بدون توکن لازم اجرا می‌کند، تغییر نمی‌دهد.
پیش از تغییر هر چیزی بررسی کنید کلاینت واقعاً با کدام حساب اجرا می‌شود. نسخه و حالت سرویس تعیین می‌کنند کدام علت‌ها اصلاً ممکن‌اند، پس هر دو را کنار خروجی مسیر ثبت کنید.
سیاست: مسیرهای ارسال‌شده می‌توانند عمداً کنار گذاشته شوند
route-nopull کلاینت را وادار می‌کند مسیرهایی را که سرور ارسال می‌کند نادیده بگیرد، از جمله مسیر پیش‌فرض ارسال‌شده، در حالی که نشانی تونل هنوز پذیرفته می‌شود. گزینه‌های DNS و DHCP ارسال‌شده با همان دستور کنار گذاشته می‌شوند. چنین کلاینتی معیوب نیست؛ او خطوط مسیر صریح را در پیکربندی خود انتظار دارد.
route-noexec کنترلی متفاوت است: کلاینت را کاملاً از اجرای تغییرات مسیر بازمی‌دارد. توپولوژی‌ای که کلاینت نمی‌تواند نقشه‌برداری کند می‌تواند نتیجه‌ای مشابه بدهد، و مسیر به‌جای افزوده‌شده به‌عنوان ردشده ثبت می‌شود. خط گزارشی را که تصمیم را اعلام می‌کند بخوانید، به‌جای حدس زدن کدام‌یک از سه علت صدق می‌کند. سپس پروفایل مؤثر را بررسی کنید، چون یک واردکننده یا ابزار مدیریت می‌تواند گزینه‌هایی بیفزاید که کاربر هرگز ویرایش نکرده است.
پروفایلی که در ویرایشگر متن تمیز به نظر می‌رسد می‌تواند در زمان اجرا دستور افزوده‌شده‌ای داشته باشد.
فهرست ارسال را با جدول مقایسه کنید
پس از اتصال، فهرست ارسال سرور را کنار جدول کلاینت بگذارید. در لینوکس آن ip route show dev tun0 است؛ در ویندوز، route print یا Get-NetRoute. اگر مسیر غایب است، ابتدا نصب را درست کنید. اگر وجود دارد و ترافیک شکست می‌خورد، به سیاست ارسال و دیوار آتش بروید.
نسخه کلاینت، حسابی که با آن اجرا می‌شود و اینکه مبتنی بر سرویس است یا نه را ثبت کنید. این سه واقعیت به نفر بعدی می‌گویند کدام علت‌ها رد شده‌اند.