แบนด์วิดท์ VPN ต่ำเป็นปัญหาเอนโทรปีหรือไม่? โดยปกติไม่ใช่

แบนด์วิดท์ที่ช้าผ่านอุโมงค์กับเครื่องที่ค้างรอตัวเลขสุ่มให้ประสบการณ์ที่ต่างกันมาก แต่กลับถูกบันทึกภายใต้ข้อร้องเรียนเดียวกัน อย่างหนึ่งปรากฏเป็นการหยุดชั่วครู่ก่อนที่อะไรจะทำงาน อีกอย่างปรากฏเป็นการเชื่อมต่อที่ทำงานและเคลื่อนข้อมูลช้าๆ ตราบเท่าที่คุณเฝ้าดู การตัดสินว่าคุณมีแบบไหนใช้เวลาสิบนาทีและประหยัดการเดาไปหนึ่งสัปดาห์

สองอาการที่ดูคล้ายกัน

บริการที่ค้างหลังการบูตใหม่ ก่อนที่จะยอมรับการเชื่อมต่อแม้แต่ครั้งเดียว กำลังรออะไรบางอย่าง อุโมงค์ที่สร้างเสร็จอย่างรวดเร็วแล้วส่งข้อมูลด้วยอัตราเพียงเศษเสี้ยวของที่คาดไว้ถูกจำกัดด้วยอย่างอื่น คำว่า encryption ปรากฏในทั้งสองเรื่อง จึงทำให้ถูกรวมเข้าด้วยกัน แยกทั้งสองออกจากกันก่อนที่คุณจะแตะไฟล์กำหนดค่า

ใส่เวลาไว้รอบการเริ่มต้น การพิสูจน์ตัวตน การเจรจาคีย์ใหม่ และการส่งข้อมูลเอง ความล่าช้ายาวนานก่อนที่อุโมงค์จะใช้งานได้ไม่ใช่อัตราต่ำที่คงที่ และการเฉลี่ยทั้งสองเป็นตัวเลขเดียวก็ทำลายหลักฐาน

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

สองคำสั่งแรกวางงานเริ่มต้นบนเส้นเวลา คำสั่งที่สามพิมพ์ค่าบัญชีเอนโทรปีของเคอร์เนล ซึ่งมีประโยชน์เป็นจุดข้อมูลจุดเดียวและไร้ประโยชน์เป็นเครื่องวัดแบนด์วิดท์

การรอตัวเลขสุ่มเป็นอย่างไรจริงๆ

คำขอไบต์สุ่มที่ปลอดภัยอาจบล็อกจนกว่าเคอร์เนลจะเริ่มต้นแหล่งสุ่มของมัน สิ่งนี้สำคัญที่สุดบนเครื่องเสมือนและบอร์ดฝังตัวขนาดเล็กในช่วงต้นของการบูต เมื่อมีสัญญาณรบกวนจากสภาพแวดล้อมสะสมน้อย จากตรงนั้นไม่ได้หมายความว่าไบต์ที่เข้ารหัสทุกไบต์ใช้เอนโทรปีใหม่

เครื่องสร้างสมัยใหม่ถูก seed ครั้งเดียวแล้วสร้างผลลัพธ์จากโครงสร้างที่กำหนดได้ และ seed ใหม่ตามตารางของตัวเอง การส่งข้อมูลจำนวนมากไม่ได้ระบายพูลทีละไบต์ ดังนั้นค่าพูลต่ำระหว่างการส่งข้อมูลช้าจึงไม่ได้พิสูจน์อะไรเกี่ยวกับสาเหตุ

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

คำสั่งแรกแสดงว่ากระบวนการกำลังอยู่ในระบบเรียกใช้ตัวเลขสุ่มขณะที่คุณเฝ้าดูหรือไม่ คำสั่งที่สองแสดงข้อความเริ่มต้นของเคอร์เนลเอง และนั่นคือที่ที่การค้างช่วงต้นของการบูตปรากฏให้เห็น

บันทึกเวอร์ชันเคอร์เนลและไลบรารีที่บริการลิงก์อยู่จริง เพราะพฤติกรรมแตกต่างกันระหว่างการใช้งานและระหว่างรุ่น สแนปช็อตที่เก็บหลังการกู้คืนมักพลาดการหยุดชั่วครู่ไปทั้งหมด

ความช้าที่ต่อเนื่องเป็นอย่างไรจริงๆ

อุโมงค์ที่ส่งข้อมูลช้าตลอดเวลาถูกจำกัดด้วยเส้นทางข้อมูล เธรดเดียวที่อิ่มตัว การสูญเสียแพ็กเก็ตภายนอก การส่งซ้ำ หรือคิวซ็อกเก็ตที่เต็ม แต่ละอย่างสร้างรูปแบบนั้น และแต่ละอย่างมีการแก้ไขของตัวเอง เปอร์เซ็นต์ CPU แบบรวมซ่อนเธรดที่ยุ่งอยู่เพียงหนึ่งเดียว ซึ่งเป็นการอ่านผิดที่พบบ่อยที่สุด ดูเวลาต่อเธรดก่อนที่จะดูภาระโดยรวม

วัดทั้งสองทิศทางด้วยเส้นฐานที่เทียบเคียงได้ และเฝ้าดูตัวนับของอินเทอร์เฟซแทนรายงานของแอปพลิเคชันเอง

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

คำสั่งแรกแสดงสถานะคิวและความแออัดสำหรับเพื่อนหนึ่งราย คำสั่งที่สองและสามรายงานการทิ้งและการส่งซ้ำที่สแตกและที่อินเทอร์เฟซ ซึ่งเป็นที่ที่สาเหตุมักปรากฏก่อน

เลือกการแก้ไขสำหรับคอขวดที่คุณวัดได้

ถ้าหลักฐานชี้ไปที่การเริ่มต้นช่วงต้นของการบูต ให้ดูเส้นทางการ seed ที่แพลตฟอร์มรองรับ ซึ่งบนเครื่องเสมือนอาจรวมถึงอุปกรณ์สุ่มที่โฮสต์จัดให้ อิมเมจ seed ที่คัดลอกโดยไม่เปลี่ยนแปลงไปยังเกสต์จำนวนมากไม่ใช่สิ่งทดแทนการเริ่มต้นที่เป็นอิสระ

ถ้าหลักฐานชี้ไปที่เส้นทางข้อมูล ให้ปรับสิ่งที่ตัวนับชี้ให้เห็น ขนาดบัฟเฟอร์ช่วยเมื่อคิวล้นและไม่ทำอะไรเลยเมื่อเธรดเดียวอิ่มตัว การติดตั้ง daemon เอนโทรปีเพื่อเพิ่มตัวนับไม่ใช่การซ่อมแซมแบนด์วิดท์ และการเปลี่ยนสมมติฐานการ seed เพื่อให้กราฟดูดีขึ้นแลกคุณสมบัติด้านความปลอดภัยกับตัวเลข

ยอมรับการเปลี่ยนแปลงก็ต่อเมื่อการวัดเดียวกันดีขึ้นภายใต้เงื่อนไขเดียวกัน ตัวนับที่ใหญ่ขึ้นไม่ใช่ผลลัพธ์ การรอที่วัดได้สั้นลงหรือการส่งข้อมูลที่เร็วขึ้นโดยมีสาเหตุที่ระบุได้ต่างหากคือผลลัพธ์