OpenVPN پس از تمدید DHCP قطع می‌شود: مسیر نقطه پایانی را نگه دارید

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

نشانه را با مسیرهای نیمه‌پیش‌فرض بسنجید

با redirect-gateway def1، OpenVPN به‌جای جایگزینی مسیر پیش‌فرض، 0.0.0.0/1 و 128.0.0.0/1 را نصب می‌کند. این دو با هم تمام فضای نشانی را پوشش می‌دهند و 0.0.0.0/0 را تنها با طول پیشوند شکست می‌دهند. بنابراین هر مقصدی بدون تطابق مشخص‌تر وارد تونل می‌شود.

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

پیش از دست زدن به چیز دیگری، شکل جدول را تأیید کنید. ip route show باید هر دو نیمه به‌علاوه یک مسیر میزبان برای نشانی سرور را فهرست کند؛ وقتی مسیر میزبان غایب است، بقیه بررسی یک نقطه شروع آشکار دارد.

چرا نیمه‌پیش‌فرض‌ها بدون تغییر متریک برنده می‌شوند

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

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

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

سه عکس بگیرید، نه یکی

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

عکس‌ها را در یک فایل با مُهرهای زمانی نگه دارید، چون پرسش جالب بعداً ترتیب است. رویداد DHCP پیش از آنکه OpenVPN مسیرش را بازتازه کند آمد یا پس از آن؟ پاسخ تعیین می‌کند چه کسی باید درستش کند. مُهر زمانی از ساعت اشتباه بدتر از نبودنش است، پس آن را از میزبان مالک جدول مسیریابی بگیرید.

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

تصمیم بگیرید کدام مؤلفه استثنا را بازتازه می‌کند

در سامانه dhcpcd، قلاب‌ها از پوشه قلاب و از قلاب خروج اجرا می‌شوند، و حالت مدیر از نظر دامنه با حالت هر رابط تفاوت دارد. هر کاری که قلاب می‌کند باید خودتوان باشد، چون تمدیدها می‌توانند دسته‌دسته برسند.

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

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

چرخه عمر را بیازمایید، نه فقط اتصال دوباره را

با dhcpcd -n eth0 یا با آزاد کردن و گرفتن دوباره اجاره، تمدید را تحمیل کنید، سپس ip route get را دوباره برای نقطه پایانی بررسی کنید. دو بار انجامش دهید، چون اجرای دوم قلاب‌هایی را می‌گیرد که مسیرهای تکراری اضافه می‌کنند. سپس راه‌اندازی مجدد کنید، چون پایداری ویژگی دیگری جز درستی است.

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