آیا پایین بودن توان عملیاتی VPN مشکل آنتروپی است؟ معمولاً نه
گیر کردن در هنگام راه‌اندازی به‌انتظار اعداد تصادفی و تونل کند دو نقص متفاوت‌اند. پیش از تغییر بذر یا بافرها اندازه بگیرید کدام را دارید.
توان عملیاتی کند از میان تونل و دستگاهی که در انتظار اعداد تصادفی گیر کرده است، تجربه‌های بسیار متفاوتی می‌سازند، اما هر دو زیر یک شکایت ثبت می‌شوند. یکی به‌صورت مکثی پیش از آنکه چیزی کار کند ظاهر می‌شود. دیگری به‌صورت اتصالی ظاهر می‌شود که کار می‌کند و تا وقتی نگاهش می‌کنید داده را کند جابه‌جا می‌کند. تشخیص اینکه کدام را دارید ده دقیقه وقت می‌گیرد و یک هفته حدس زدن را صرفه‌جویی می‌کند.
دو نشانه که شبیه هم به نظر می‌رسند
سرویسی که پس از راه‌اندازی تازه، پیش از پذیرش حتی یک اتصال، معلق می‌ماند منتظر چیزی است. تونلی که سریع برقرار می‌شود و سپس با کسری از نرخ انتظاری انتقال می‌دهد، توسط چیز دیگری محدود می‌شود. واژه رمزنگاری در هر دو روایت می‌آید و همین باعث می‌شود با هم یکی شوند. پیش از دست زدن به فایل پیکربندی آن‌ها را جدا کنید.
زمان‌سنج‌ها را پیرامون راه‌اندازی، احراز هویت، مذاکره دوباره کلید و خود انتقال بگذارید. تأخیر طولانی پیش از آنکه تونل قابل استفاده شود نرخ پایدار پایین نیست، و میانگین گرفتن از این دو در یک عدد شواهد را نابود می‌کند.
systemd-analyze blame | head -10 journalctl -u [email protected] -o short-precise | head -40 cat /proc/sys/kernel/random/entropy_avail
دو فرمان نخست کار راه‌اندازی را روی یک خط زمانی می‌گذارند. فرمان سوم مقدار حسابداری آنتروپی هسته را چاپ می‌کند که به‌عنوان یک نقطه داده سودمند و به‌عنوان سنجه پهنای باند بی‌فایده است.
انتظار برای اعداد تصادفی در واقع چگونه است
درخواست بایت‌های تصادفی امن می‌تواند مسدود شود تا زمانی که هسته منبع تصادفی خود را راه‌اندازی کند. این موضوع بیشترین اهمیت را در ماشین‌های مجازی و بردهای تعبیه‌شده کوچک در اوایل راه‌اندازی دارد، وقتی نویز محیطی کمی جمع شده است. از این نتیجه نمی‌شود که هر بایت رمزگذاری‌شده آنتروپی تازه مصرف می‌کند.
مولدهای نوین یک بار بذر می‌گیرند و سپس از یک ساختار قطعی خروجی تولید می‌کنند و طبق برنامه خودشان دوباره بذر می‌گیرند. انتقال انبوه استخر را بایت به بایت تخلیه نمی‌کند، بنابراین مقدار پایین استخر در حین انتقال کند چیزی درباره علت اثبات نمی‌کند.
strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20 dmesg | grep -i 'random\|crng'
فرمان نخست نشان می‌دهد آیا فرایند در حین تماشای شما در یک فراخوان عدد تصادفی نشسته است. فرمان دوم پیام‌های راه‌اندازی خود هسته را نشان می‌دهد و همان‌جاست که گیر راه‌اندازی اولیه دیده می‌شود.
نسخه هسته و کتابخانه‌ای را که سرویس واقعاً به آن پیوند می‌خورد ثبت کنید، چون رفتار میان پیاده‌سازی‌ها و میان انتشارها تفاوت دارد. ردیابی که پس از بازیابی گرفته شود معمولاً مکث را کاملاً از دست می‌دهد.
کندی پایدار در واقع چگونه است
تونلی که در تمام مدت کند انتقال می‌دهد توسط مسیر داده محدود می‌شود. یک ریسه اشباع‌شده، افت بسته‌های بیرونی، بازفرست‌ها یا صف‌های پر سوکت هر یک این الگو را می‌سازند و هر یک اصلاح خودش را دارد. درصد تجمعی CPU یک ریسه مشغول را پنهان می‌کند و این رایج‌ترین قرائت نادرست است. پیش از نگاه به بار کل، زمان هر ریسه را ببینید.
در هر دو جهت با یک خط پایه قابل مقایسه اندازه بگیرید و به شمارنده‌های واسط نگاه کنید نه به گزارش خود برنامه.
ss -tin dst 203.0.113.10 nstat -az | grep -i 'drop\|retrans' ethtool -S eth0 | grep -i 'drop\|error'
فرمان نخست وضعیت صف و ازدحام را برای یک همتا نشان می‌دهد. فرمان دوم و سوم افت‌ها و بازفرست‌ها را در پشته و در واسط گزارش می‌کنند و همان‌جاست که علت معمولاً اول ظاهر می‌شود.
اصلاح مناسب برای گلوگاهی را که اندازه گرفتید انتخاب کنید
اگر شواهد به راه‌اندازی اولیه اشاره کند، مسیر بذر پشتیبانی‌شده پلتفرم را ببینید که در ماشین مجازی می‌تواند شامل یک دستگاه تصادفی ارائه‌شده توسط میزبان باشد. تصویر بذری که بدون تغییر در مهمان‌های بسیاری کپی شود جایگزین راه‌اندازی مستقل نیست.
اگر شواهد به مسیر داده اشاره کند، چیزی را که شمارنده‌ها نشان می‌دهند تنظیم کنید. اندازه بافرها وقتی صف‌ها سرریز می‌کنند کمک می‌کند و وقتی یک ریسه اشباع است کاری نمی‌کند. نصب یک دیمن آنتروپی برای بالا بردن یک شمارنده تعمیر توان عملیاتی نیست، و تغییر فرض‌های بذر برای بهتر دیده شدن یک نمودار یک ویژگی امنیتی را با یک عدد معاوضه می‌کند.
تغییر را فقط وقتی بپذیرید که همان اندازه‌گیری در همان شرایط بهتر شود. شمارنده بزرگ‌تر نتیجه نیست؛ انتظار اندازه‌گیری‌شده کوتاه‌تر یا انتقال سریع‌تر با علت مشخص نتیجه است.