آیا VPN از انتروپی تمام می‌شود؟ entropy_avail واقعاً چه چیزی را نشان می‌دهد
توقف هنگام بوت و تونل برقرارشدهٔ کند دو خرابی متفاوت‌اند. پیش از مقصر دانستن تصادفی‌بودن، مرحله، معنای واقعی شمارنده و صف را بخوانید.
تمام شدن تصادفی‌بودن هسته توضیحی گیرا برای VPN کند است و تقریباً همیشه توضیح نادرست برای نشانه‌ای است که مردم گزارش می‌دهند. میزبانی که منتظر خروجی تصادفی است در لحظه‌ای معین متوقف می‌شود، معمولاً در اوایل بوت یا هنگام پردازش کلیدها. تونلی که سریع وصل می‌شود و سپس آهسته انتقال می‌دهد در عوض دربارهٔ توان عبوری حرف می‌زند. این دو مشاهده را جدا کنید پیش از نصب یک سرویس پس‌زمینه برای اصلاح عددی که خواندنش را تمام نکرده‌اید.
چرا این افسانه دوام می‌آورد
هر دو مشکل واقعی‌اند و از دور شبیه هم به نظر می‌رسند. توقف‌های آغاز به کار روی ماشین مجازی تازه‌بوت‌شده واقعاً رخ می‌دهند و تونل برقرارشدهٔ کند هم به همان اندازه واقعی است. خطا این است که فرض کنیم دومی از اولی ناشی می‌شود چون رمزنگاری جایی در هر دو داستان ظاهر می‌شود. هیچ چیز در واژهٔ رمزگذاری به این معنا نیست که هر بایت منتقل‌شده یک بایت تازه از نوفهٔ محیطی مصرف می‌کند.
این مولدها این‌گونه کار نمی‌کنند. کتابخانهٔ رمزنگاری یک مولد بذردار نگه می‌دارد و از آن خروجی می‌گیرد و بر اساس سیاست خودش دوباره بذرپاشی می‌کند، پس لحظهٔ گران بذرپاشی است نه انتقال پیوسته.
مولد برای هر بسته چه می‌کند
در OpenSSL 3 سلسله‌مراتب مولد پیش‌فرض از نمونه‌های DRBG ساخته می‌شود که بر اساس پیکربندی و وضعیت بذرپاشی و دوباره بذرپاشی می‌کنند. در OpenVPN 2.6 مسیر دادهٔ AEAD نانس خود را از شمارهٔ ترتیب بسته به‌همراه یک مقدار ضمنی برای هر نشست به‌دست می‌آورد، در حالی که مسیر قدیمی‌تر CBC برای هر بسته یک IV شبه‌تصادفی می‌گیرد. هیچ‌یک از این دو الگو از این قاعده پشتیبانی نمی‌کند که جابه‌جا کردن یک گیگابایت، یک گیگابایت نوفهٔ تازهٔ هسته مصرف می‌کند. هر دو از این ایده پشتیبانی می‌کنند که تولید کلید و دست‌دادن‌ها جایی است که بذرپاشی اهمیت دارد.
مورد CBC ارزش نام بردن دارد چون شبیه افسانه است و نیست: IV هر بستهٔ آن از مولد کتابخانه بر اساس زمان‌بندی دوباره بذرپاشی خود کتابخانه می‌آید، هرگز از یک فراخوان هسته برای هر بسته. وقتی کسی هزینهٔ انتروپی به‌ازای هر بایت را نقل می‌کند، بپرسید کدام نسخهٔ کتابخانه و کدام مسیر کد را اندازه گرفته‌اند.
انتظار در کجا واقعاً دیده می‌شود
مهرهای زمانی را دور مراحل بگذارید نه دور نشست: آغاز به کار، احراز هویت، تغییر کلید و انتقال. انتظار پیش از قابل استفاده شدن تونل شکایتی متفاوت از نرخ ثابت پایین است و تنها یکی از آن‌ها به تصادفی‌بودن اشاره می‌کند. در Linux یک درخواست عادی getrandom() می‌تواند مسدود شود تا منبع تصادفی هسته مقداردهی اولیه شود، و به همین دلیل نسخهٔ هنگام بوت این مشکل روی ماشین‌های مجازی و بردهای توکار که در ابتدا چیز کمی برای تغذیهٔ استخر دارند واقعی است.
| مرحله | چه چیزی اجرا شود | خواندنی که یعنی انتظار | خواندنی که یعنی توان عبوری |
|---|---|---|---|
| بوت، پیش از هر تونلی | systemd-analyze critical-chain | واحدی که چند ثانیه پیش از شروع تونل می‌نشیند | قابل اعمال نیست، هنوز چیزی منتقل نمی‌شود |
| دست‌دادن | journalctl -u openvpn-server@server -b | فاصلهٔ طولانی پیش از کامل شدن توالی مقداردهی اولیه | قابل اعمال نیست، تونل بالا نیست |
| انتقال برقرارشده | ss -tin در کنار sar -n DEV 1 | فرایند مسدود با صف‌های سوکت خالی | صف‌های پر، ارسال‌های دوباره و یک رشتهٔ مشغول |
دو فرمان ارزان به آغاز آن مجموعه تعلق دارند و پرسش‌های آسان را پیش از آنکه جدول حتی لازم شود حل می‌کنند. شمارنده‌ای که می‌خوانند حسابداری انتروپی است نه سنجهٔ پهنای باند، و یک عکس لحظه‌ای نمی‌تواند نشان دهد که فرایندی مسدود است، چقدر منتظر مانده یا کتابخانه‌اش کدام واسط را صدا می‌زند. نمونه‌ای که پس از بازیابی گرفته شود معمولاً توقف را کاملاً از دست می‌دهد، پس نسخهٔ هسته را کنار خواندن نگه دارید.
cat /proc/sys/kernel/random/entropy_avail
uname -rاصلاح را با خواندن هماهنگ کنید
اگر هسته واقعاً منتظر مقداردهی اولیه است، به مسیر بذرپاشی پشتیبانی‌شدهٔ پلتفرم نگاه کنید نه به تونل. می‌توان به ماشین مجازی یک دستگاه تصادفی که میزبان فراهم می‌کند داد، مانند virtio-rng و آماده‌سازی تصویر اهمیت دارد چون بذری که بدون تغییر در مهمان‌های زیادی کپی شود مقداردهی اولیهٔ مستقل نیست. اگر کتابخانه‌ای پس از بوت از شکست بذرپاشی خبر دهد، منبع پیکربندی‌شده و رفتار تأمین‌کنندهٔ آن را بررسی کنید نه اینکه تنظیمات هسته را تغییر دهید.
ss -tin dst 203.0.113.7
sar -n DEV 1 5مستندات مولد OpenSSL توضیح می‌دهد که این سلسله‌مراتب چگونه ورودی می‌گیرد و دوباره بذرپاشی چه زمانی رخ می‌دهد، که ادعایی بسیار باریک‌تر از افسانه است و فقط برای همان پیاده‌سازی صادق است. سرویس پس‌زمینهٔ انتروپی یک تعمیر سرعت همگانی نیست و نصب آن برای بالا بردن یک شمارنده، یک فرض امنیتی را بدون نشان دادن تأخیری تغییر می‌دهد. برای توان عبوری، مسیر داده را دنبال کنید: یک رشتهٔ اشباع‌شده، ارسال‌های دوباره، افت بیرونی و ریزش صف هرکدام اصلاح متفاوتی می‌خواهند و اندازه‌های بافر با شواهد صف خودشان به بافرینگ سوکت می‌پردازند.