محدودیت‌های اتصال VPN: وضعیت زنده در برابر تاریخچهٔ نگه‌داری‌شده
محدودیت سه اتصال به وضعیت زندهٔ جایگاه‌ها نیاز دارد، نه به تاریخچهٔ مرور: اینکه سازوکار چه چیزی را باید نگه دارد، چه چیزی را می‌تواند دور بریزد و آن وضعیت بعداً کجا می‌رود.
سه اتصال هم‌زمان یک تصمیم پذیرش است، و پاسخ دادن به آن مستلزم دانستن این است که کدام جایگاه‌ها همین حالا اشغال شده‌اند، نه اینکه ماه گذشته چه رخ داده است. یک سرویس می‌تواند چهارمین نشست را بر اساس جدولی کوچک از سوابق فعال رد کند و هرگز خط زمانی نسازد. این سخنی دربارهٔ سازوکار است، نه دربارهٔ اپراتور، و این تفاوت وقتی خط‌مشی حریم خصوصی می‌خوانید اهمیت دارد. مدل زیر نشان می‌دهد که تصمیم چه چیزی لازم دارد و چه چیزی را می‌تواند دور بریزد.
سازوکار: یک جدول جایگاه، نه یک گزارش
ساده‌ترین پیاده‌سازی یک اشتراک را به حداکثر سه سابقهٔ نشست فعال مرتبط می‌کند. هر نشست پذیرفته‌شده یک جایگاه می‌گیرد، و جایگاه زمانی آزاد می‌شود که سرویس تصمیم بگیرد آن نشست پایان یافته است. سابقه به هویتی نیاز دارد که به‌قدر کافی مشخص باشد تا آزاد کردن یک اتصال، جایگاه اتصال دیگری را آزاد نکند؛ به همین دلیل شناسهٔ نشست از نام حساب مهم‌تر است.
اشغال و تاریخچه دو ساختار دادهٔ متفاوت‌اند. اشغال به پرسشی بله-یا-خیر دربارهٔ زمان حال پاسخ می‌دهد و می‌تواند در همان لحظه‌ای که نشست پایان می‌یابد دور ریخته شود. تاریخچه جریانی از رویدادها است که فقط به آن افزوده می‌شود، و باقی می‌ماند چون کسی تصمیم گرفته آن را نگه دارد. یک سرویس می‌تواند یکی، هر دو یا هیچ‌کدام را داشته باشد.
این تمایز از بیرون نامرئی است. محدودیت اتصالِ قابل مشاهده با یک شمارندهٔ کوچک در حافظه، یک جدول پایگاه‌دادهٔ مشترک و یک بایگانی کامل رویداد همراه با داشبورد سازگار است. هیچ چیز در محدودیت به شما نمی‌گوید کدام‌یک در حال اجراست.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
چرا مدل زنده هنوز به هماهنگی نیاز دارد
ممکن است اتصال گم‌شده بلافاصله به‌عنوان پایان‌یافته شناخته نشود. دروازه منتظر یک مهلت زمانی، یک خطای keepalive یا یک توقف حسابداری می‌ماند، و تا رسیدن یکی از آن‌ها جایگاه اشغال باقی می‌ماند. کاربری که در این فاصله دوباره متصل می‌شود، ردی را می‌بیند که هیچ ربطی به دستگاه چهارم ندارد.
سروری که دوباره راه‌اندازی می‌شود باید وضعیت خود را تطبیق دهد، و چند دروازه که به یک حساب خدمت می‌دهند به تصمیمی مشترک نیاز دارند. در غیر این صورت یک حساب می‌تواند با اتصال به مکان‌های مختلف از سهم خود فراتر برود. وضعیت مشترک یا قابل بازیابی این را حل می‌کند، و وضعیت مشترک یک الزام طراحی است نه شاهدی بر نظارت.
هیچ‌یک از این هماهنگی به تاریخچهٔ مرور نیاز ندارد. دروازه‌ای که بسته‌ها را هدایت می‌کند برای شمردن نشست‌ها لازم نیست بداند یک نشست از کدام سایت بازدید کرده است، و این دو جریان داده معمولاً توسط اجزایی کاملاً متفاوت مدیریت می‌شوند.
نگه داشتن شمارش در حافظه هم واقعیت‌های مرتبط را ناشناس نمی‌کند. تا زمانی که سرویس اجرا می‌شود، یک سابقهٔ مرتبط با اشتراک آشکار می‌کند که حسابی اتصال‌های فعال دارد، و هم دسترسی به این وضعیت و هم مدت عمرش هر دو ارزش پرسیدن دارند.
آن وضعیت بعداً کجا می‌رود
پرسش حریم خصوصی این نیست که آیا سرور می‌تواند بشمارد. بپرسید بر سر یک نشست پایان‌یافته چه می‌آید: آیا سابقه حذف می‌شود، یا به رویدادی در یک سری پایش تبدیل می‌شود؟ سپس بپرسید کدام اجزای دیگر همان رویداد را دیده‌اند، زیرا گزارش‌های احراز هویت، سوابق حسابداری و پشتیبان‌ها هر یک می‌توانند نسخه‌ای را نگه دارند که مسیر اجرا دور ریخته است.
حسابداری RADIUS روشن‌ترین نمونه است. جفت Start و Stop برای پشتیبانی از صورت‌حساب و کنترل نشست وجود دارد، و سابقه‌ای از اتصال می‌سازد، صرف‌نظر از اینکه کسی هرگز آن را به‌عنوان تاریخچه جست‌وجو کند. سرویسی که محدودیت‌ها را از طریق حسابداری اجرا می‌کند، بنابراین به‌حکم ساختار بیش از یک جدول جایگاه نگه می‌دارد.
حذف هم شکلی دارد. سابقه‌ای که از جدول زنده حذف شده می‌تواند در پشتیبانی که یک ساعت پیش گرفته شده باقی بماند، و دورهٔ نگه‌داری آن پشتیبان اظهارنظر سیاستی خودش است. خواندن فقط انبار اصلی پاسخ ناقصی می‌دهد.
پرسش را بر حسب فیلدها بپرسید
راهنمای کمینه‌سازی دادهٔ RFC 6973 داده‌های گردآوری‌شده و ذخیره‌شده را به هدفی که خدمت می‌کند پیوند می‌دهد. با اعمال در اینجا، پرسش سودمند این است که وظیفهٔ پذیرش هم‌زمان واقعاً به کدام فیلدها نیاز دارد، و چه هدفی نگه داشتن هر یک را پس از پایان آن وظیفه توجیه می‌کند.
یک بیانیهٔ دقیق سرویس، وضعیت زندهٔ اتصال را که برای اجرای سهم استفاده می‌شود از هر سابقه‌ای که پس از خاتمه نگه داشته می‌شود جدا می‌کند، و سیستم‌های دیگر را در محدودهٔ آن وعده نام می‌برد. جمله‌ای که فقط می‌گوید سه اتصال اجرا می‌شود، نه وجود یک بایگانی را اثبات می‌کند نه نبود آن را.
وقتی چرخهٔ عمر روشن نیست، آن را به‌عنوان پرسش بی‌پاسخ نگه‌داری ثبت کنید نه به‌عنوان حکم. وجود یک محدودیت شاهدی بر تاریخچهٔ پنهان نیست، و توضیح محتمل دربارهٔ وضعیت زنده حسابرسی از ارائه‌دهنده نیست.