Thông lượng VPN thấp có phải là vấn đề entropy? Thường là không

Thông lượng chậm qua một đường hầm và một máy bị treo khi chờ số ngẫu nhiên tạo ra những trải nghiệm rất khác nhau, nhưng cả hai đều được ghi dưới cùng một khiếu nại. Một cái xuất hiện như một khoảng dừng trước khi bất cứ thứ gì hoạt động. Cái kia xuất hiện như một kết nối hoạt động và di chuyển dữ liệu chậm chạp chừng nào bạn còn nhìn. Xác định bạn gặp cái nào mất mười phút và tiết kiệm một tuần đoán mò.

Hai triệu chứng trông giống nhau

Một dịch vụ bị treo sau khi khởi động mới, trước khi chấp nhận một kết nối nào, đang chờ đợi điều gì đó. Một đường hầm thiết lập nhanh rồi truyền với một phần nhỏ tốc độ mong đợi bị giới hạn bởi thứ khác. Từ mã hóa xuất hiện trong cả hai câu chuyện, nên chúng bị gộp lại. Hãy tách chúng ra trước khi bạn chạm vào một tệp cấu hình.

Đặt dấu thời gian quanh việc khởi động, xác thực, thương lượng lại khóa và chính việc truyền. Một độ trễ dài trước khi đường hầm dùng được không phải là tốc độ thấp ổn định, và lấy trung bình cả hai thành một con số phá hủy bằng chứng.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Hai lệnh đầu đặt công việc khởi động lên một dòng thời gian. Lệnh thứ ba in giá trị kế toán entropy của nhân, hữu ích như một điểm dữ liệu duy nhất và vô dụng như một máy đo băng thông.

Một lần chờ số ngẫu nhiên thực sự trông như thế nào

Một yêu cầu byte ngẫu nhiên an toàn có thể bị chặn cho đến khi nhân khởi tạo nguồn ngẫu nhiên của nó. Điều này quan trọng nhất trên máy ảo và bo mạch nhúng nhỏ vào đầu quá trình khởi động, khi ít nhiễu môi trường được thu thập. Từ đó không suy ra rằng mỗi byte được mã hóa tiêu thụ entropy mới.

Các bộ tạo hiện đại được tạo hạt giống một lần rồi tạo đầu ra từ một cấu trúc tất định, tự tạo lại hạt giống theo lịch của chúng. Truyền hàng loạt không làm cạn một vũng theo từng byte, nên một giá trị vũng thấp trong khi truyền chậm không chứng minh được gì về nguyên nhân.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

Lệnh đầu cho biết tiến trình có đang nằm trong một lời gọi số ngẫu nhiên trong khi bạn quan sát hay không. Lệnh thứ hai cho thấy chính các thông điệp khởi tạo của nhân, và đó là nơi tình trạng kẹt khi khởi động sớm trở nên hữu hình.

Ghi lại phiên bản nhân và thư viện mà dịch vụ thực sự liên kết, vì hành vi khác nhau giữa các cách hiện thực và giữa các bản phát hành. Một dấu vết lấy sau khi phục hồi thường bỏ lỡ hoàn toàn khoảng dừng.

Sự chậm chạp kéo dài thực sự trông như thế nào

Một đường hầm truyền chậm suốt thời gian bị giới hạn bởi đường dẫn dữ liệu. Một luồng bão hòa, mất gói bên ngoài, truyền lại hoặc hàng đợi socket đầy mỗi thứ tạo ra mẫu đó, và mỗi thứ có cách sửa riêng. Phần trăm CPU tổng hợp che giấu một luồng bận duy nhất, và đó là cách đọc sai phổ biến nhất. Hãy xem thời gian theo từng luồng trước khi xem tải tổng thể.

Đo theo cả hai hướng với một đường cơ sở tương đương, và theo dõi các bộ đếm giao diện thay vì báo cáo của chính ứng dụng.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

Lệnh đầu cho thấy trạng thái hàng đợi và tắc nghẽn cho một đối tác. Lệnh thứ hai và thứ ba báo cáo việc loại bỏ và truyền lại ở tầng ngăn xếp và ở giao diện, nơi nguyên nhân thường xuất hiện trước tiên.

Chọn cách sửa cho nút cổ chai bạn đã đo

Nếu bằng chứng chỉ vào việc khởi tạo sớm lúc khởi động, hãy xem đường dẫn tạo hạt giống được nền tảng hỗ trợ, mà trên máy ảo có thể bao gồm một thiết bị ngẫu nhiên do máy chủ cung cấp. Một ảnh hạt giống được sao chép nguyên vẹn cho nhiều khách không thay thế việc khởi tạo độc lập.

Nếu bằng chứng chỉ vào đường dẫn dữ liệu, hãy điều chỉnh điều mà các bộ đếm chỉ ra. Kích thước vùng đệm giúp khi hàng đợi tràn và không làm gì khi một luồng bão hòa. Cài một daemon entropy để nâng một bộ đếm không phải là sửa thông lượng, và thay đổi giả định tạo hạt giống để đồ thị trông đẹp hơn là đổi một thuộc tính bảo mật lấy một con số.

Chỉ chấp nhận thay đổi khi cùng một phép đo cải thiện trong cùng điều kiện. Một bộ đếm lớn hơn không phải là kết quả; một lần chờ được đo ngắn hơn hoặc một lần truyền nhanh hơn với nguyên nhân được xác định mới là kết quả.