VPN có cạn entropy không? entropy_avail thực sự cho thấy điều gì

Cạn kiệt tính ngẫu nhiên của nhân là một lời giải thích hấp dẫn cho VPN chậm, và gần như luôn sai với triệu chứng mà người ta báo cáo. Một máy chờ đầu ra ngẫu nhiên sẽ khựng lại ở một thời điểm nhất định, thường là đầu quá trình khởi động hoặc khi xử lý khóa. Một đường hầm kết nối nhanh rồi truyền chậm thực ra đang mô tả thông lượng. Hãy tách hai quan sát đó trước khi cài một daemon để sửa con số mà bạn chưa đọc xong.

Vì sao huyền thoại tồn tại

Cả hai vấn đề đều có thật và nhìn từ xa thì giống nhau. Kẹt lúc khởi động trên máy ảo vừa khởi động thật sự xảy ra, và đường hầm đã thiết lập chậm cũng thật y như vậy. Sai lầm là cho rằng cái thứ hai do cái thứ nhất gây ra vì mật mã xuất hiện đâu đó trong cả hai câu chuyện. Không có gì trong từ mã hóa ngụ ý rằng mỗi byte được truyền tiêu tốn một byte nhiễu môi trường mới.

Các bộ sinh này không hoạt động như vậy. Thư viện mật mã giữ một bộ sinh có hạt giống và lấy đầu ra từ đó, gieo lại theo chính sách của nó, nên khoảnh khắc đắt giá là gieo hạt, không phải truyền đều.

Bộ sinh làm gì với mỗi gói

Trong OpenSSL 3, hệ thống phân cấp bộ sinh mặc định được xây từ các phiên bản DRBG gieo hạt và gieo lại theo cấu hình và trạng thái. Trong OpenVPN 2.6, đường dữ liệu AEAD suy ra nonce từ số thứ tự của gói kết hợp với một giá trị ngầm định cho mỗi phiên, còn đường CBC cũ lấy một IV giả ngẫu nhiên cho mỗi gói. Không mẫu nào hỗ trợ quy tắc rằng di chuyển một gigabyte tiêu tốn một gigabyte nhiễu nhân mới. Cả hai đều ủng hộ ý tưởng rằng tạo khóa và bắt tay là nơi việc gieo hạt quan trọng.

Trường hợp CBC đáng được nêu tên vì nó giống huyền thoại mà không phải: IV cho mỗi gói của nó đến từ bộ sinh của thư viện theo lịch gieo lại của chính thư viện, không bao giờ từ một lời gọi nhân cho mỗi gói. Khi ai đó nêu chi phí entropy trên mỗi byte, hãy hỏi họ đo phiên bản thư viện nào và đường mã nào.

Chỗ chờ đợi thực sự lộ ra

Đặt dấu thời gian quanh các giai đoạn chứ không phải quanh phiên: khởi động, xác thực, đổi khóa và truyền. Chờ trước khi đường hầm dùng được là một phàn nàn khác với tốc độ ổn định thấp, và chỉ một trong hai chỉ về tính ngẫu nhiên. Trên Linux, một yêu cầu getrandom() bình thường có thể bị chặn cho đến khi nguồn ngẫu nhiên của nhân được khởi tạo, đó là lý do phiên bản lúc khởi động của vấn đề này là thật trên máy ảo và bo mạch nhúng vốn có ít thứ để nuôi hồ bơi lúc đầu.

Hai lệnh rẻ nằm ở đầu bộ thu thập đó, và chúng giải quyết các câu hỏi dễ trước khi bảng còn cần đến. Bộ đếm chúng đọc là kế toán entropy, không phải đồng hồ đo băng thông, và một ảnh chụp không thể cho thấy tiến trình có bị chặn không, đã chờ bao lâu hay thư viện của nó gọi giao diện nào. Mẫu lấy sau khi phục hồi thường bỏ lỡ hoàn toàn cú khựng, nên hãy giữ phiên bản nhân bên cạnh số đọc.

cat /proc/sys/kernel/random/entropy_avail
uname -r

Khớp cách sửa với số đọc

Nếu nhân thực sự chờ khởi tạo, hãy nhìn đường gieo hạt mà nền tảng hỗ trợ chứ không phải đường hầm. Máy ảo có thể được cấp một thiết bị ngẫu nhiên do máy chủ cung cấp, chẳng hạn virtio-rng, và việc chuẩn bị ảnh quan trọng vì hạt giống được sao chép nguyên vẹn sang nhiều khách không phải là khởi tạo độc lập. Nếu thư viện báo lỗi gieo hạt sau khi khởi động, hãy kiểm tra nguồn đã cấu hình và hành vi của nhà cung cấp thay vì đổi cài đặt nhân.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Tài liệu bộ sinh OpenSSL mô tả cách hệ thống phân cấp đó nhận đầu vào và khi nào việc gieo lại xảy ra, một khẳng định hẹp hơn huyền thoại rất nhiều và chỉ đúng với cách triển khai đó. Daemon entropy không phải là bản sửa tốc độ phổ quát, và cài nó để bộ đếm tăng lên sẽ thay đổi một giả định bảo mật mà không chứng minh được độ trễ. Về thông lượng, hãy theo đường dữ liệu: một luồng bão hòa, truyền lại, mất mát bên ngoài và rơi hàng đợi mỗi thứ cần một cách sửa khác nhau, và kích thước bộ đệm xử lý việc đệm socket với bằng chứng hàng đợi riêng.