ifconfig-noexec نشست SSH شما را نجات نمی‌دهد: چه کاری می‌کند
این گزینه تنظیم آدرس رابط خودِ OpenVPN را سرکوب می‌کند. نه مسیر پاسخ SSH را رزرو می‌کند، نه هر تغییر مسیر را غیرفعال می‌کند و نه آدرس گم‌شده را فراهم می‌آورد.
جایی در یک رشته انجمن، ifconfig-noexec به‌عنوان راه‌حلی پیشنهاد می‌شود که هنگام بالا آمدن تونل، نشست SSH را زنده نگه می‌دارد. استدلال تا وقتی معقول به نظر می‌رسد که بررسی کنید این گزینه به چه چیزی دست می‌زند. مانع می‌شود که OpenVPN آدرس رابط تونل را تنظیم کند و آن مقادیر را در عوض به اسکریپت‌ها می‌سپارد؛ درباره اینکه پاسخ‌های اتصال مدیریتی شما کجا می‌روند چیزی نمی‌گوید. باور به خلاف این، تونلی بدون آدرس قابل استفاده و نشست SSHای که همچنان می‌میرد تولید می‌کند.
این گزینه در واقع چه چیزی را واگذار می‌کند
به‌طور پیش‌فرض، کارخواه دستگاه تونل را بالا می‌آورد و آدرس‌های محلی و راه دوری را که کارساز به آن داده است تخصیص می‌دهد. با تنظیم ifconfig-noexec، آن مرحله رد می‌شود و مقادیر توافق‌شده به محیط اسکریپت صادر می‌شوند تا چیز دیگری آن‌ها را اعمال کند.
مالکیت جابه‌جا می‌شود. چیزی به جای آن از خود ساخته نمی‌شود.
پس پرسشی که این گزینه پاسخ می‌دهد این است که چه کسی رابط را تنظیم می‌کند، و پرسشی که پاسخ نمی‌دهد این است که بسته‌ها چگونه راه بازگشت به شما را پیدا می‌کنند. این دو را جدا نگه دارید، وگرنه شبی را صرف ویرایش مسیرها می‌کنید تا رابطی بدون آدرس را جبران کنید.
سه گزینه مشابه با کارهای متفاوت
این خانواده به‌راحتی اشتباه می‌شوند، چون نام‌ها با یک واژه تفاوت دارند و نشانه‌ها هم‌پوشانی دارند. پیش از انتخاب هر کدام، بخوانید که هر یک چه چیزی را سرکوب می‌کند.
| گزینه | چه چیزی دیگر رخ نمی‌دهد |
|---|---|
ifconfig-noexec | تنظیم آدرس تونل توسط خود OpenVPN؛ مقادیر در عوض به اسکریپت‌ها می‌روند |
route-noexec | افزودن و حذف خودکار مسیرها؛ جزئیات مسیر به یک اسکریپت می‌رود |
route-nopull | مسیرهایی که کارساز هل می‌دهد و گزینه‌های مرتبط مانند DNS رد می‌شوند |
این‌ها جایگزین‌هایی برای درک جداگانه هستند، نه مجموعه‌ای برای چسباندن به هم. سرکوب تنظیم آدرس، تغییر مسیرها، قواعد دیوار آتش یا گزینه‌های هل‌داده‌شده‌ای را که DNS حمل می‌کنند سرکوب نمی‌کند. اسکریپت واگذارشده نیز آزاد است مسیرها را تغییر دهد، و این تصمیمی است که به جای اجتناب، آن را تحویل می‌دهید.
اگر کارخواه یک فروشنده موتور را بپوشاند، از یکپارچگی پشتیبانی‌شده‌اش استفاده کنید، نه اینکه یک دستور سطح پایین را در نمایه بیندازید و امیدوار باشید پوشش به آن احترام می‌گذارد. پوشش‌ها اغلب نمایه را هنگام اتصال بازتولید می‌کنند، پس ویرایش دستی بدون خطا ناپدید می‌شود. پیش از گذراندن یک شب روی پرونده، بررسی کنید کارخواه تنظیماتش را کجا نگه می‌دارد. این برای هر سطر جدول صدق می‌کند، نه فقط سطری که برایش آمده‌اید.
نشست SSH که قصد داشتید محافظت کنید
یک اتصال SSH آدرس مبدأ، آدرس مقصد و مسیر پاسخ دارد. روی کارسازی که همین حالا پیش‌فرض تونل کامل را نصب کرده، پاسخ به آدرس عمومی شما با تونل منطبق می‌شود و درگاه VPN آن را دور می‌اندازد.
هیچ چیز در تنظیم آدرس رابط تونل آن را تغییر نمی‌دهد.
آنچه این را درست می‌کند یک مسیر مشخص‌تر برای آدرس مدیریتی شما از طریق درگاه پیش از تونل است، یا یک قاعده سیاست که آن ترافیک را هدایت می‌کند، به‌همراه تنظیمات پالایشی که میزبان شما اعمال می‌کند. دو مشکل گاهی با هم ظاهر می‌شوند، و این‌گونه است که یکی درمان دیگری پنداشته می‌شود. آن‌ها را جدا آزمایش کنید: تونل را بدون گزینه بالا بیاورید، به آدرس رابط و مسیر پاسخ نگاه کنید و سپس تصمیم بگیرید کدام یک واقعاً خراب است.
اسکریپت واگذارشده چه چیزی را باید بر عهده بگیرد
اگر واقعاً می‌خواهید مالک دیگری رابط را تنظیم کند، کار را برشمارید: آدرس محلی و راه دور را اعمال کنید، دستگاه را بالا بیاورید، هنگام برچیدن آدرس‌دهی را بازگردانید یا حذف کنید، و پس از اتصال دوباره همین کار را تکرار کنید. مقادیر یک نشست موفق نباید سخت‌کد شوند، چون کارساز ممکن است بار بعد جفت دیگری بدهد.
متغیرهای محیطی که کارخواه صادر می‌کند تنها ورودی پشتیبانی‌شده برای این کار هستند.
env | grep -E '^ifconfig_|^route_'درون یک اسکریپت route-up آن متغیرها در دسترس هستند؛ از یک کار cron یا پوسته دستی نه. تأیید کنید نسخه شما از کدام قلاب چرخه عمر استفاده می‌کند و تأیید کنید که قلاب با اختیار کافی برای تغییر رابط اجرا می‌شود، چون کارخواه ممکن است از پیش به کاربری بدون اختیار افتاده باشد.
کل چرخه عمر را آزمایش کنید، نه یک نشست را
تونل را بالا بیاورید، آدرس را روی دستگاه بررسی کنید، سپس دوباره وصل شوید و آن را بازبینی کنید. تنظیمی که یک بار کار می‌کند و در تلاش دوم شکست می‌خورد معمولاً یعنی مرحله واگذارشده فقط در نخستین اتصال اجرا می‌شود.
سپس هر دو معیار پذیرش را با هم آزمایش کنید: اتصال SSH تازه از مسیر مدیریتی موردنظر کار می‌کند، و برنامه‌ای مجاز تونل را به‌درستی استفاده می‌کند.
نشست SSH قدیمی‌ای که تصادفاً زنده می‌ماند در حالی که تونل هیچ آدرسی ندارد موفقیت نیست، و دقیقاً همان حالتی است که این گزینه وقتی هیچ‌کس کار را بر عهده نمی‌گیرد تولید می‌کند. نخست آدرس رابط را بررسی کنید، سپس مسیر پاسخ مدیریتی، سپس برنامه. اگر دو مورد از سه مورد اشتباه باشد، گزینه کار را جابه‌جا کرده بدون اینکه برایش مالکی بگذارد.