OpenVPN هنوز مسیرهای قدیمی را هل می‌دهد؟ ببینید چه چیزی بارگذاری کرده است
یا سرور هرگز ویرایش شما را نخوانده، یا کلاینت هرگز آنچه را دریافت کرده نصب نکرده است. پروسه در حال اجرا، فهرست ارسال‌شده و مسیر بازگشت را مقایسه کنید.
یک مسیر اضافه می‌کنید، سرویس را ری‌استارت می‌کنید، دوباره وصل می‌شوید و جدول کلاینت دقیقاً مثل قبل است. دو چیز متفاوت می‌تواند درست باشد: سرور ویرایش شما را بارگذاری نکرده، یا کلاینت آنچه را دریافت کرده نصب نکرده است. جز نشانه هیچ چیز مشترکی ندارند، پس اولین قدم این است که بفهمید کدام‌یک را دارید.
مقایسه زیر از پروسه به بیرون می‌رود، چون پروسه تنها مرجع این است که کدام فایل معتبر است.
فایلی که ویرایش کردید و فایلی که پروسه می‌خواند
با unit و خط فرمانی که ساخته شروع کنید. روی میزبان systemd، systemctl cat openvpn@server خط ExecStart را چاپ می‌کند، و unit نمونه معمولاً مسیر پیکربندی را از نام نمونه می‌گیرد، بنابراین دیمونی که به‌صورت openvpn@office راه‌اندازی شده فایلی متفاوت از دیمون openvpn@server می‌خواند. این را با argv پروسه در حال اجرا مقایسه کنید. ابزار مدیریت پیکربندی راه دیگری برای گم‌شدن تغییر اضافه می‌کند: می‌تواند فایل درست را در جایی بنویسد که unit هرگز ذکر نمی‌کند و آن‌وقت یک استقرار موفق مثل هیچ‌وپوچ به نظر می‌رسد.
برچسب‌های زمانی سریع روشن می‌کنند: اگر فایل از زمان شروع پروسه تازه‌تر باشد، پروسه نمی‌توانسته آن را خوانده باشد. فریم‌ور روتر حالت سومی اضافه می‌کند، چون بسیاری از مدل‌ها تنظیمات را در فلش نگه می‌دارند و هنگام بوت پیکربندی را از نو می‌سازند، که ویرایش فایل روی دیسک را کاملاً لایه اشتباه می‌کند.
سرور چه چیزی می‌فرستد و کلاینت چه چیزی نصب می‌کند
مسیر ارسال‌شده باید از دو فیلتر بگذرد. روی سرور باید در پیکربندی بارگذاری‌شده باشد، نه در بلوک کامنت‌شده یا در فایل مخصوص کلاینتی که نامش نمی‌خواند. روی کلاینت باید pull فعال باشد و هیچ pull-filter آن گزینه را دور نیندازد. با verbosity 4 وصل شوید و گزینه‌های ارسال‌شده‌ای را که کلاینت گزارش می‌کند بخوانید: اگر مسیر در آن فهرست باشد، سرور کار خود را کرده و این کلاینت است که نصب نکردنش را انتخاب می‌کند.
فایل‌های مخصوص کلاینت منبع رایج سردرگمی‌اند. فایلی که به نام common name گواهی نام‌گذاری شده، گزینه‌ها را فقط به همان کلاینت می‌فرستد، و اختلاف یک کاراکتر ارسال را بی‌صدا متوقف می‌کند، بدون خطا در هیچ طرف. سرور common name را که هنگام اتصال دیده ثبت می‌کند، پس آن مقدار را با نام فایل مقایسه کنید، نه با آنچه فکر می‌کنید نام کلاینت است.
پیشوند ارسال‌شده و مسیر بازگشت دو مشکل متفاوت‌اند
کلاینتی که آگاهانه redirect-gateway را نادیده می‌گیرد تا مسیر اینترنت محلی خود را حفظ کند، شکاف دوم و بی‌ربطی می‌سازد. پروب‌های سرور به آدرس تونل می‌رسند و پاسخ‌ها هرگز نمی‌رسند، چون پاسخی که به IP تونل سرور نشانه رفته از دروازه پیش‌فرض معمولی کلاینت مسیریابی می‌شود. مسیر زیرشبکه ارسال‌شده اینجا مقصر نیست؛ آنچه غایب است مسیری است که ترافیک شبکه تونل سرور را از دستگاه تونل برمی‌گرداند.
افزودن آن مسیر روی کلاینت پاسخ‌ها به پروب‌هایی که سرور آغاز می‌کند را درست می‌کند. جایگزین مسیر زیرشبکه ارسال‌شده نیست، و برعکسش هم درست است، چون این دو جهت‌های متضاد حرکت را توصیف می‌کنند.
جدول‌ها را در دو سر مقایسه کنید
پس از هر تغییر، دوباره وصل شوید و جدول کلاینت را برای پیشوند ارسال‌شده و برای دستگاه تونل بخوانید. سپس در هر دو جهت آزمایش کنید: از کلاینت به میزبان در زیرشبکه ارسال‌شده، و از همان میزبان به کلاینت. مسیری که وجود دارد اما ترافیکی حمل نمی‌کند یعنی یکی از سه چیز: طرف مقابل فوروارد نمی‌کند، فایروال جریان را می‌اندازد، یا پاسخ راه بازگشتی ندارد.
سه شناسه را کنار هم نگه دارید: مسیر پیکربندی، نام unit یا نمونه، و هویت کلاینتی که با آن آزمایش کردید.
این سه، رخداد بعدی را به یک بررسی پنج‌دقیقه‌ای تبدیل می‌کنند نه تحقیق دوباره، و همان چیزی هستند که همکارتان وقتی تونل مشکل کس دیگری می‌شود لازم دارد.
مشکل مسیری که از ری‌استارت جان سالم به در می‌برد اغلب اصلاً مشکل مسیریابی نیست؛ خطا بالاتر از جدولی است که مدام می‌خوانید.