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

دو ماشین، دو پرسشی که باید اول پاسخ داده شوند

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

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

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

گزینه سمت سرور: یک رویداد به‌ازای هر اتصال

یک اسکریپت client-connect وقتی کلاینت احرازشده‌ای متصل می‌شود در بستر فرایند سرور اجرا می‌شود، و جزئیات مستند اتصال مانند common name و نشانی تخصیص‌یافته را دریافت می‌کند. جای درستی است برای نوشتن یک قطعه پیکربندی به‌ازای هر کلاینت، اعمال یک تصمیم سیاستی، یا ثبت وضعیتی که سرور مالک آن است.

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

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

گزینه سمت کلاینت: کاری که باید محلی اجرا شود

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

کمک‌کننده باید روی همان کلاینت وجود داشته باشد، برای حسابی که کلاینت را اجرا می‌کند خواندنی و اجراپذیر باشد، و با تنظیم صریح script-security مجاز شده باشد. اسکریپتی که وقتی کلاینت را به‌عنوان مدیر اجرا می‌کنید کار می‌کند، هیچ چیزی درباره یک سرویس پیش از ورود یا نشست کاربری دیگر به شما نمی‌گوید.

نام‌گذاری هم مهم است. قلاب up متناظر با ایجاد دستگاه است و route-up متناظر با نصب مسیرها، اما وظیفه‌ای که به در دسترس بودن یک شبکه خصوصی نیاز دارد باید دسترس‌پذیری را بررسی کند، نه اینکه فرض کند ایجاد دستگاه یعنی هر مسیر، ورودی resolver و برنامه آماده است.

چرا فرستادن کد اجراپذیر در فهرست گزینه‌ها نیست

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

فعال کردن اجرای اسکریپت به‌صورت محلی این را تغییر نمی‌دهد. تنظیم script-security شما اسکریپت‌های محلی‌ای را که خودتان انتخاب کرده‌اید مجاز می‌کند؛ به سرور اجازه نمی‌دهد اسکریپت‌های تازه تأمین کند.

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

پیش از اعتماد به هر یک از دو قلاب چه چیزی را بررسی کنید

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

آن را با همان حسابی آزمایش کنید که واقعاً اجرایش می‌کند، در همان لحظه‌ای که واقعاً اجرا می‌شود. راهنمای openvpn(8) هر دو خانواده قلاب و محدودیت‌های push را مستند می‌کند؛ پلتفرمی که روی آن مستقر می‌شوید مستند می‌کند که آیا اصلاً آنها را ارائه می‌دهد. اسکریپتی که در یک ترمینال تعاملی مدیر موفق می‌شود یک فرضیه است، نه یک بررسی.

مقالات مرتبط