Apakah VPN Kehabisan Entropi? Apa yang Sebenarnya Ditunjukkan entropy_avail
Macet saat boot dan terowongan mapan yang lambat adalah dua gangguan berbeda. Baca tahapannya, makna sebenarnya penghitung, dan antreannya sebelum menyalahkan keacakan.
Kehabisan keacakan kernel adalah penjelasan yang menarik untuk VPN lambat, dan hampir selalu yang salah untuk gejala yang dilaporkan orang. Host yang menunggu keluaran acak berhenti pada momen tertentu, biasanya di awal boot atau selama penanganan kunci. Terowongan yang terhubung cepat lalu mentransfer pelan justru menggambarkan throughput. Pisahkan kedua pengamatan itu sebelum memasang daemon untuk memperbaiki angka yang belum selesai Anda baca.
Mengapa mitos ini bertahan
Kedua masalah itu nyata dan dari jauh tampak serupa. Kemacetan awal pada mesin virtual yang baru dinyalakan memang terjadi, dan terowongan mapan yang lambat sama nyatanya. Kesalahannya adalah menganggap yang kedua disebabkan yang pertama karena kriptografi muncul di suatu tempat dalam kedua cerita. Tidak ada apa pun dalam kata enkripsi yang menyiratkan bahwa setiap byte yang ditransfer memakai byte baru kebisingan lingkungan.
Bukan begitu generator ini bekerja. Pustaka kriptografi menyimpan generator berbenih dan mengambil keluaran darinya, membenihkan ulang menurut kebijakannya sendiri, jadi momen mahal adalah pembenihan, bukan transfer stabil.
Apa yang dilakukan generator per paket
Di OpenSSL 3 hierarki generator default dibangun dari instance DRBG yang membenihkan dan membenihkan ulang sesuai konfigurasi dan status. Di OpenVPN 2.6 jalur data AEAD menurunkan nonce dari nomor urut paket ditambah nilai implisit per sesi, sedangkan jalur CBC yang lebih lama mengambil IV pseudorandom per paket. Tidak ada pola yang mendukung aturan bahwa memindahkan satu gigabyte memakai satu gigabyte kebisingan kernel baru. Keduanya mendukung gagasan bahwa pembuatan kunci dan jabat tangan adalah tempat pembenihan penting.
Kasus CBC layak disebut karena tampak seperti mitos dan bukan: IV per paketnya datang dari generator pustaka menurut jadwal pembenihan ulang pustaka itu sendiri, tidak pernah dari panggilan kernel per paket. Ketika seseorang mengutip biaya entropi per byte, tanyakan versi pustaka dan jalur kode mana yang mereka ukur.
Di mana penantian sebenarnya terlihat
Letakkan stempel waktu di sekitar tahapan, bukan di sekitar sesi: startup, autentikasi, pergantian kunci, dan transfer. Menunggu sebelum terowongan bisa dipakai adalah keluhan berbeda dari laju stabil yang rendah, dan hanya satu dari keduanya menunjuk ke keacakan. Di Linux permintaan getrandom() normal dapat terblokir sampai sumber acak kernel diinisialisasi, itulah sebabnya versi saat boot dari masalah ini nyata pada mesin virtual dan papan tertanam yang punya sedikit untuk memberi makan kumpulan di awal.
| Tahap | Apa yang dijalankan | Pembacaan yang berarti menunggu | Pembacaan yang berarti throughput |
|---|---|---|---|
| Boot, sebelum terowongan apa pun | systemd-analyze critical-chain | unit yang duduk beberapa detik sebelum terowongan mulai | tidak berlaku, belum ada yang ditransfer |
| Jabat tangan | journalctl -u openvpn-server@server -b | celah panjang sebelum urutan inisialisasi selesai | tidak berlaku, terowongan belum naik |
| Transfer mapan | ss -tin di samping sar -n DEV 1 | proses terblokir dengan antrean soket kosong | antrean penuh, pengiriman ulang, dan satu thread sibuk |
Dua perintah murah berada di awal kumpulan itu, dan keduanya menyelesaikan pertanyaan mudah sebelum tabelnya bahkan diperlukan. Penghitung yang mereka baca adalah pembukuan entropi, bukan pengukur lebar pita, dan satu cuplikan tidak bisa menunjukkan bahwa suatu proses terblokir, berapa lama menunggu, atau antarmuka mana yang dipanggil pustakanya. Sampel yang diambil setelah pemulihan biasanya melewatkan kemacetan sepenuhnya, jadi simpan versi kernel di samping pembacaan.
cat /proc/sys/kernel/random/entropy_avail
uname -rCocokkan koreksi dengan pembacaan
Jika kernel benar-benar menunggu inisialisasi, lihat jalur pembenihan yang didukung platform, bukan terowongannya. Mesin virtual bisa diberi perangkat acak yang disediakan host, seperti virtio-rng, dan persiapan image penting karena benih yang disalin tanpa perubahan ke banyak tamu bukan inisialisasi independen. Jika pustaka melaporkan kegagalan pembenihan setelah boot, periksa sumber yang dikonfigurasi dan perilaku penyedianya alih-alih mengubah pengaturan kernel.
ss -tin dst 203.0.113.7
sar -n DEV 1 5Dokumentasi generator OpenSSL menjelaskan bagaimana hierarki itu memperoleh masukan dan kapan pembenihan ulang terjadi, yang merupakan klaim jauh lebih sempit daripada mitos dan hanya berlaku untuk implementasi itu. Daemon entropi bukan perbaikan kecepatan universal, dan memasangnya agar penghitung naik mengubah asumsi keamanan tanpa membuktikan penundaan. Untuk throughput, ikuti jalur data: satu thread jenuh, pengiriman ulang, kehilangan luar, dan pembuangan antrean masing-masing butuh perbaikan berbeda, dan ukuran buffer menangani buffering soket dengan bukti antreannya sendiri.