VPN เอ็นโทรปีจะหมดได้หรือ? entropy_avail บอกอะไรจริง ๆ
การค้างตอนบูตกับอุโมงค์ที่ตั้งไว้แล้วแต่ช้าเป็นความผิดพลาดคนละแบบ อ่านระยะ ตัวเลขจริงของคอนเตอร์ และคิวก่อนโทษความสุ่ม
การที่ความสุ่มของเคอร์เนลหมดเป็นคำอธิบายที่ชวนเชื่อสำหรับ VPN ที่ช้า และแทบทุกครั้งเป็นคำอธิบายที่ผิดสำหรับอาการที่ผู้ใช้รายงาน โฮสต์ที่รอผลลัพธ์สุ่มจะค้าง ณ ช่วงเวลาหนึ่ง โดยมากเป็นช่วงต้นของการบูตหรือระหว่างจัดการคีย์ อุโมงค์ที่ เชื่อมต่อได้เร็วแล้วถ่ายโอนช้า กลับกำลังอธิบายอัตราส่งข้อมูลแทน แยกข้อสังเกตสองข้อนี้ก่อนติดตั้งดีมอนเพื่อแก้ตัวเลขที่คุณยังอ่านไม่จบ
ทำไมตำนานนี้จึงอยู่รอด
ปัญหาทั้งสองเป็นของจริงและมองจากระยะไกลก็ดูคล้ายกัน การค้างตอนเริ่มบนเครื่องเสมือนที่เพิ่งบูตเกิดขึ้นจริง และอุโมงค์ที่ตั้งไว้แล้วแต่ช้าก็จริงพอ ๆ กัน ข้อผิดพลาดคือการสรุปว่าอย่างที่สองเกิดจากอย่างแรกเพราะมีการเข้ารหัสโผล่ที่ใดที่หนึ่งในทั้งสองเรื่อง ไม่มีอะไรในคำว่าเข้ารหัสที่บอกว่าไบต์ที่ถ่ายโอนทุกไบต์ต้องใช้ไบต์ใหม่ของสัญญาณรบกวนแวดล้อม
ตัวสร้างเหล่านี้ไม่ได้ทำงานแบบนั้น ไลบรารีการเข้ารหัสเก็บตัวสร้างที่มีเมล็ดและดึงผลลัพธ์ออกมา โดยใส่เมล็ดใหม่ตามนโยบายของตัวเอง ช่วงเวลาที่แพงจึงเป็นการใส่เมล็ด ไม่ใช่การถ่ายโอนอย่างต่อเนื่อง
ตัวสร้างทำอะไรต่อแพ็กเก็ต
ใน OpenSSL 3 ลำดับชั้นของตัวสร้างเริ่มต้นสร้างจากอินสแตนซ์ DRBG ที่ใส่เมล็ดและใส่เมล็ดใหม่ตามการกำหนดค่าและสถานะ ใน OpenVPN 2.6 เส้นทางข้อมูล AEAD หา nonce จากหมายเลขลำดับของแพ็กเก็ตประกอบกับค่าที่บอกเป็นนัยต่อเซสชัน ขณะที่เส้นทาง 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 อธิบายว่าลำดับชั้นนั้นได้อินพุตอย่างไรและใส่เมล็ดใหม่เมื่อใด ซึ่งเป็นข้ออ้างที่แคบกว่าตำนานมากและใช้ได้เฉพาะกับการใช้งานนั้นเท่านั้น ดีมอนเอ็นโทรปีไม่ใช่การซ่อมความเร็วสากล และการติดตั้งเพื่อให้คอนเตอร์สูงขึ้นก็เปลี่ยนสมมติฐานด้านความปลอดภัยโดยไม่แสดงความล่าช้า สำหรับอัตราส่งข้อมูล ให้ตามเส้นทางข้อมูล: เธรดที่อิ่มตัวหนึ่งเธรด การส่งซ้ำ การสูญเสียภายนอก และคิวตก แต่ละอย่างต้องแก้ต่างกัน และขนาดบัฟเฟอร์จัดการบัฟเฟอร์ซ็อกเก็ตด้วยหลักฐานคิวของตัวเอง