Apakah throughput VPN rendah masalah entropi? Biasanya bukan
Macet saat startup yang menunggu angka acak dan terowongan lambat adalah dua kesalahan berbeda. Ukur mana yang Anda alami sebelum mengubah seeding atau buffer.
Throughput lambat melalui terowongan dan mesin yang macet menunggu angka acak menghasilkan pengalaman yang sangat berbeda, namun keduanya dicatat di bawah keluhan yang sama. Yang satu muncul sebagai jeda sebelum apa pun berfungsi. Yang lain muncul sebagai koneksi yang berfungsi dan memindahkan data dengan lambat selama Anda mengamatinya. Menentukan mana yang Anda alami membutuhkan sepuluh menit dan menghemat satu minggu dugaan.
Dua gejala yang tampak serupa
Layanan yang menggantung setelah boot baru, sebelum menerima satu koneksi pun, sedang menunggu sesuatu. Terowongan yang terbentuk cepat lalu mentransfer dengan sebagian kecil dari laju yang diharapkan dibatasi oleh hal lain. Kata enkripsi muncul di kedua cerita, karena itu keduanya digabungkan. Pisahkan keduanya sebelum Anda menyentuh file konfigurasi.
Pasang stempel waktu di sekitar startup, autentikasi, negosiasi ulang kunci, dan transfer itu sendiri. Penundaan panjang sebelum terowongan dapat digunakan bukanlah laju rendah yang stabil, dan merata-ratakan keduanya menjadi satu angka menghancurkan bukti.
systemd-analyze blame | head -10 journalctl -u [email protected] -o short-precise | head -40 cat /proc/sys/kernel/random/entropy_avail
Dua perintah pertama menempatkan pekerjaan startup pada garis waktu. Yang ketiga mencetak nilai akuntansi entropi kernel, yang berguna sebagai satu titik data dan tidak berguna sebagai pengukur bandwidth.
Seperti apa sebenarnya menunggu angka acak
Permintaan byte acak yang aman dapat terblokir sampai kernel menginisialisasi sumber acaknya. Itu paling penting pada mesin virtual dan papan tertanam kecil di awal boot, ketika sedikit kebisingan lingkungan yang terkumpul. Dari situ tidak berarti setiap byte terenkripsi mengonsumsi entropi baru.
Generator modern di-seed sekali lalu menghasilkan keluaran dari konstruksi deterministik, dan melakukan seed ulang sesuai jadwalnya sendiri. Transfer massal tidak menguras kumpulan byte demi byte, jadi nilai kumpulan yang rendah selama transfer lambat tidak membuktikan apa pun tentang penyebabnya.
strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20 dmesg | grep -i 'random\|crng'
Perintah pertama menunjukkan apakah proses sedang berada dalam panggilan angka acak saat Anda mengamati. Yang kedua menunjukkan pesan inisialisasi kernel sendiri, dan di situlah kemacetan boot awal terlihat.
Catat versi kernel dan pustaka yang benar-benar ditautkan oleh layanan, karena perilakunya berbeda antarimplementasi dan antarilisan. Jejak yang diambil setelah pemulihan biasanya melewatkan jeda sepenuhnya.
Seperti apa sebenarnya lambat yang berkelanjutan
Terowongan yang mentransfer lambat sepanjang waktu dibatasi oleh jalur data. Satu utas yang jenuh, kehilangan paket luar, transmisi ulang, atau antrean soket penuh masing-masing menghasilkan pola itu, dan masing-masing punya perbaikannya sendiri. Persentase CPU agregat menyembunyikan satu utas yang sibuk, dan itulah salah baca yang paling umum. Lihat waktu per utas sebelum melihat beban total.
Ukur di kedua arah dengan basis pembanding, dan pantau penghitung antarmuka alih-alih laporan aplikasi itu sendiri.
ss -tin dst 203.0.113.10 nstat -az | grep -i 'drop\|retrans' ethtool -S eth0 | grep -i 'drop\|error'
Perintah pertama menunjukkan status antrean dan kongesti untuk satu peer. Yang kedua dan ketiga melaporkan penurunan dan transmisi ulang di tumpukan dan di antarmuka, di situlah penyebabnya biasanya muncul pertama.
Pilih koreksi untuk penghambat yang Anda ukur
Jika bukti mengarah ke inisialisasi boot awal, lihat jalur seeding yang didukung platform, yang pada mesin virtual dapat mencakup perangkat acak yang disediakan host. Citra seed yang disalin tanpa perubahan ke banyak tamu bukan pengganti inisialisasi mandiri.
Jika bukti mengarah ke jalur data, setel apa yang ditunjukkan penghitung. Ukuran buffer membantu ketika antrean meluap dan tidak melakukan apa pun ketika satu utas jenuh. Memasang daemon entropi untuk menaikkan penghitung bukan perbaikan throughput, dan mengubah asumsi seeding agar grafik terlihat lebih baik menukar properti keamanan dengan sebuah angka.
Terima perubahan hanya ketika pengukuran yang sama membaik pada kondisi yang sama. Penghitung yang lebih besar bukan hasil; tunggu terukur yang lebih pendek atau transfer yang lebih cepat dengan penyebab teridentifikasi adalah hasilnya.