چگونه زمان کارکرد کلاینت OpenVPN را با قلاب‌های up و down اندازه بگیریم

یک داشبورد عددی برای مدت اتصال می‌خواهد و OpenVPN آن را ارائه نمی‌دهد۔ کلاینت می‌داند تونلش کِی بالا آمده، اما تنها اگر چیزی آن لحظه را پیش از از دست رفتن وضعیت نشست ثبت کند۔ جای پشتیبانی‌شده قلاب up است، و مقداری که ارزش نگه‌داشتن دارد یک ثانیه خام epoch است نه یک رشته قالب‌بندی‌شده۔ همه‌چیز پس از آن حساب است، به‌علاوه چند قاعده ترتیب که تعیین می‌کند عدد صادق می‌ماند یا نه۔

تأیید کنید که قلاب‌ها واقعاً اجرا می‌شوند

پیش از طراحی هر چیزی پیرامونش ثابت کنید قلاب شلیک می‌شود۔ یک پیکربندی حداقلی کلاینت به script-security 2 و مسیرهای صریح up و down نیاز دارد؛ بدون خط امنیتی OpenVPN از اجرای اسکریپت سر باز می‌زند و این را صریح می‌گوید۔ هم‌زمان up-restart و down-pre را اضافه کنید تا مسیرهای بازراه‌اندازی و برچیدن قابل پیش‌بینی رفتار کنند۔

نسخه اول قلاب را طوری بسازید که محیطش را به یک فایل بیفزاید و کار دیگری نکند۔ این نام متغیرهایی را به شما می‌گوید که ساخت شما واقعاً صادر می‌کند، مانند dev و script_type، به‌جای آن‌هایی که از نسخه دیگری به یاد دارید۔ یک اتصال و یک قطع اجرا کنید و سپس فایل را بخوانید۔ اگر چیزی پدیدار نشد همین‌جا بایستید، چون طراحی مُهر زمانی روی قلابی که هرگز اجرا نمی‌شود هفته‌ها شبیه خرابی پایش به نظر می‌رسد۔

بررسی کنید قلاب با کدام کاربر اجرا می‌شود۔ با تنظیم user و group، OpenVPN پیش از اجرای اسکریپت‌ها از امتیازها دست می‌کشد، پس پوشه‌ای که root می‌تواند در آن بنویسد ممکن است برای قلاب بسته باشد۔ مسیر را از دید سرویس انتخاب کنید نه از دید پوسته خودتان۔

یک مقدار epoch ثبت کنید و آن را عامدانه پاک کنید

قلاب up به یک خط نیاز دارد، date +%s > /run/openvpn-client.started، با مسیری که برای هر نمونه تنظیم می‌شود۔ مقدار epoch بعداً از پرسش‌های زبان، منطقه زمانی و قالب جلوگیری می‌کند و همان عددی است که یک عامل پایش می‌تواند با ساعت خودش مقایسه کند۔

پاک کردن به‌اندازه نوشتن اهمیت دارد۔ قلاب down باید فایل را خالی یا حذف کند، و down-pre این کار را پیش از بسته شدن رابط انجام می‌دهد، که پنجره‌ای را برمی‌دارد که فایل در آن تونلی از پیش رفته را توصیف می‌کند۔ up-restart سپس مُهر را در بازراه‌اندازی داخلی تازه می‌کند به‌جای آنکه مقدار اولیه را سر جایش بگذارد۔ بدون این جفت، بازراه‌اندازی پس از پایان مهلت ping عددی می‌سازد که تا وقتی تونل دوباره برپا می‌شود همچنان بالا می‌رود۔

جایی با عمر درست انتخاب کنید۔ فایل زیر /run هنگام راه‌اندازی دوباره ناپدید می‌شود، که با واقعیت می‌خواند، در حالی که فایل زیر /tmp ممکن است به‌طور غیرقابل پیش‌بینی پاک شود و فایلی در پوشه پیکربندی به شکلی گمراه‌کننده باقی می‌ماند۔ مجوزها را طوری تنظیم کنید که تنها کاربر سرویس و خواننده پایش بتوانند آن را بخوانند۔

زمان کارکرد را بدون اعتماد به خطوط گزارش محاسبه کنید

ثانیه ذخیره‌شده را بخوانید، ثانیه کنونی را بخوانید، تفریق کنید۔ وقتی فایل نیست یا خالی است، پاسخ صادقانه این است که هیچ تونلی فعال نیست، نه اینکه زمان کارکرد صفر است، زیرا این دو وضعیت باید هشدارهای متفاوتی برپا کنند۔ ثانیه‌های خام را در بار داده پایش نگه دارید و روزها و ساعت‌ها را در لایه نمایش قالب کنید۔ قالب‌بندی‌کننده‌ای که درون صادرکننده گرد می‌کند دقتی را دور می‌ریزد که کسی در هنگام رخداد خواهد خواست۔

تجزیه مُهرهای زمانی گزارش میان‌بُر وسوسه‌انگیز است و از سه راه شکست می‌خورد: قالب از هر گزینه‌ای که تنظیم شده پیروی می‌کند، چرخش تاریخچه را حذف می‌کند، و اتصال‌های دوباره به‌صورت نشست‌های جداگانه پدیدار می‌شوند نه یک تونل پیوسته۔ قلاب رویداد را یک بار، در لحظه‌ای که رخ می‌دهد ثبت می‌کند۔

وقتی بررسی روی میزبان دیگری اجرا می‌شود، مُهر زمانی را بفرستید نه مدت را، تا خواننده ساعت خودش را اعمال کند۔ آنگاه نتیجه منفی کوچک به‌عنوان انحراف ساعت خوانده می‌شود نه قلاب خراب۔

اتصال‌های دوباره، بازراه‌اندازی‌ها و نمونه‌های متعدد را پوشش دهید

دو تونل روی یک میزبان دو فایل می‌خواهند، با کلید نام نمونه‌ای که سرویس از پیش به کار می‌برد۔ مسیر مشترک یعنی تازه‌ترین اتصال زمان شروع هر پروفایل را بازنویسی می‌کند، و نشانه عددی است که با آغاز تونل دوم به عقب می‌پرد۔

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

در سمت سرور، فایل وضعیت برای هر کلاینت مقدار connected-since را دارد که به پرسش دیگری پاسخ می‌دهد: سرور آخرین بار آن همتا را کِی دیده است۔ از آن برای بررسی متقابل استفاده کنید نه جایگزین، چون همراه نشستی که توصیف می‌کند ناپدید می‌شود۔ هیچ‌کدام از این دو اندازه‌گیری چیزی درباره سلامت برنامه پشت تونل نمی‌گوید۔

سه بررسی‌ای را اجرا کنید که باگ‌های ترتیب را می‌گیرند

اتصال عادی، اتصال دوباره اجباری و توقف پاک را بیازمایید و پس از هرکدام فهرست رابط‌ها و فایل را با هم بخوانید۔ مُهری که پس از توقف پاک هنوز هست، یا فایلی که تونلی را ادعا می‌کند که در فهرست رابط‌ها نیست، مستقیماً به ترتیب قلاب‌ها اشاره می‌کند۔ بررسی‌ها را به‌عنوان کاربر سرویس و با مسیرهای سرویس اجرا کنید، چون پوسته root ممکن است فایل دیگری ببیند و پاسخی مطمئن و نادرست بدهد۔ سپس یک پویشگر کند را بگذارید فایل را بخواند و تأیید کنید که هرگز در آن نمی‌نویسد۔

پویش هر شصت ثانیه هشداردهی را پوشش می‌دهد و هیچ قلابی نباید به زنده بودن آن پویشگر تکیه کند۔ این دو مسئولیت را جدا نگه دارید تا عدد هنگام استقرار دوباره هر طرف قابل اعتماد بماند۔