چرا یک OpenVPN /24 زودتر از آنچه انتظار دارید کلاینت کم می‌آورد

استخرهایی که روی یک /24 ساخته می‌شوند و حدود شصت، پذیرش کلاینت را متوقف می‌کنند، همان‌طور که طراحی شده‌اند رفتار می‌کنند و به محدودیت مجوز برنمی‌خورند. در net30 به هر کلاینت یک پیوند مجازی نقطه‌به‌نقطه داده می‌شود که چهار آدرس مصرف می‌کند، بنابراین یک زیرشبکه 256 آدرسی تقریباً یک‌چهارم آنچه پیشوند القا می‌کند را پشتیبانی می‌کند. عددی که اهمیت دارد تخصیص‌ها است، نه آدرس‌ها. خواندن پیشوند به‌عنوان تعداد کلاینت همان خطایی است که جست‌وجوی یک سقف پنهان کاربر را ایجاد می‌کند.

دو توپولوژی، دو مدل حسابی، و تنها یکی از آن‌ها با پیشوندی که مردم فرض می‌کنند می‌خواند.

net30 چهار آدرس برای هر کلاینت مصرف می‌کند

net30 برای هر کلاینت یک بلوک /30 تخصیص می‌دهد، چون هر نشست به‌صورت یک پیوند نقطه‌به‌نقطه با یک آدرس در هر سر مدل می‌شود. چهار آدرس وارد آن بلوک می‌شود و دو آدرس قابل استفاده است، به همین دلیل تعداد مؤثر کلاینت یک‌چهارم زیرشبکه است. روی یک /24 این کار 64 بلوک باقی می‌گذارد پیش از آنکه بلوک خود سرور و هر تخصیص ثابت خارج شود. سقف گزارش‌شده نزدیک 63 حسابی است که خود را نشان می‌دهد، نه یک بیشینه پیکربندی‌شده.

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

مرزهای استخر مهم‌تر از پیشوند هستند

دستور سرور ممکن است استخری باریک‌تر از زیرشبکه‌ای که نام می‌برد تعریف کند، و یک اسکریپت کمکی می‌تواند به تنظیمات بیشتری گسترش یابد که در پروفایلی که باز کرده‌اید دیده نمی‌شوند. آدرس‌های ثابت از پوشه client-config درون آن دامنه قرار دارند و دو بار قابل واگذاری نیستند. پیشوند بیشترین فضای ممکن را توصیف می‌کند؛ استخر مؤثر همان چیزی است که پیکربندی در حال اجرا واقعاً ارائه می‌دهد.

پیش از هر نتیجه‌ای درباره ظرفیت، این دو را مقایسه کنید، چون یک دامنه پیکربندی‌شده کوچک‌تر سقف را به همان خوبی توپولوژی توضیح می‌دهد.

محدودیتی را پیدا کنید که واقعاً کلاینت را رد کرد

ابتدا توپولوژی و استخر مؤثر را بخوانید، سپس تخصیص‌های ثابت و آدرس‌های رزروشده را در نظر بگیرید. همچنین max-clients و هر کنترل پذیرشی بیرون از OpenVPN را بررسی کنید پیش از آنکه فضای آدرس را مقصر بدانید. در پایان، پیام خود سرور را در لحظه رد با این نامزدها تطبیق دهید. پیام محدودیت را نام می‌برد؛ عدد تنها میدان را باریک می‌کند.

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

تغییر توپولوژی طرح آدرس را تغییر می‌دهد

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

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

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

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

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