پیام «File exists» OpenVPN روی یک مسیر، مشکل فایل نیست

از همان‌جا شروع کنید که پیام ظاهر می‌شود. کلاینتی وصل می‌شود، تونل بالا می‌آید و سپس گزارش ثبت می‌کند که فرمان افزودن مسیر در لینوکس با File exists شکست خورده است. هیچ‌چیز در آن جمله به گواهی، کلید یا فایل پیکربندی اشاره نمی‌کند، هرچند واژه‌ها این را القا می‌کنند. هسته دارد جدول مسیریابی خود را توصیف می‌کند و پیشوندی که خواستید نصب شود از قبل یک ورودی دارد.

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

کلاینت در واقع چه می‌خواست

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

مسیر موجود را بخوانید، نه فقط نشانی را

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

چهار مالکی که یک پیشوند می‌تواند داشته باشد

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

هر مالک تصحیح متفاوتی می‌خواهد. مسیر متصل مال شما نیست که پاکش کنید؛ حذفش می‌تواند دسترسی محلی را پیش از قابل استفاده شدن تونل بشکند و هسته آن را برمی‌گرداند. مسیری که در مالکیت یک مدیر است باید از طریق همان مدیر تغییر کند، نه با ip route del دستی که اتصال دوباره بعدی آن را باطل می‌کند.

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

block-local به پرسش دیگری پاسخ می‌دهد

وقتی یک پروفایل همه ترافیک را از تونل می‌فرستد، کلاینت باید تصمیم بگیرد با شبکه محلی چه می‌شود. پرچم block-local آن تصمیم را با مسیریابی LAN محلی از طریق تونل تغییر می‌دهد و در همان حال استثنای مستند برای دروازه LAN را حفظ می‌کند؛ این یک انتخاب خط‌مشی ترافیک با پیامدهای آشکار برای دسترس‌پذیری است.

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

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

حلقه را ببندید: تکراری را در منبعش حذف کنید

وقتی دانستید کدام مالک ورودی را در دست دارد، دستور تکراری را همان‌جا که تعریف شده حذف کنید. این می‌تواند یک خط route در پروفایل، یک push از سرور یا قلابی باشد که دیگر نیازی به اجرا ندارد.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

سپس دوباره وصل شوید و سه چیز را تأیید کنید: تونل بالا می‌آید، مقصد موردنظر به مسیری که می‌خواستید تجزیه می‌شود و خطا از میان می‌رود بدون اینکه خطای تازه‌ای جای آن ظاهر شود. گزارش تمیز با مسیر انتخابی نادرست، تعمیر نیست.

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