رویدادهای قلاب OpenVPN: چرا نام و برچسب زمانی کلید نیستند

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

از این شروع کنید که متغیرهای قطع اتصال واقعاً چه معنایی دارند. تنها پس از آن است که انتخاب شناسه معنا پیدا می‌کند.

قلاب قطع اتصال واقعاً چه چیزی حمل می‌کند

در Community OpenVPN 2.6، مرجع قلاب time_unix را به‌عنوان لحظه‌ای تعریف می‌کند که کلاینت متصل شد؛ پیش از اجرای قلاب اتصال تنظیم می‌شود و وقتی قلاب قطع اتصال بعداً فعال شود دوباره تعریف نمی‌شود. time_duration طول آن نشست را بر حسب ثانیه می‌دهد، بنابراین پایان تقریباً زمان اتصال به‌علاوه مدت است. هر دو ثانیه‌های کامل هستند و هیچ‌کدام لحظه‌ای نیست که پایگاه داده شما رویداد را پردازش کرده است. جدا نگه داشتن این سه زمان است که باعث می‌شود یک همبستگی پایدار بماند، نه اینکه فقط در هنگام آزمایش درست به نظر برسد.

این حساب ارزش نوشتن دارد، چون تنها زمان پایانی است که خود قلاب ارائه می‌دهد. تأخیر پردازش و تفاوت ساعت‌ها میان میزبان‌ها هنوز بیرون از آن می‌مانند.

چرا جفت واضح یکتا نیست

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

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

هویت پایدار از کجا می‌آید

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

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

بازنشستگی را شرطی و خودتوان کنید

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

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

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

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