UDP ไม่ได้เร็วกว่าเสมอไป: การเลือกทรานสปอร์ตของ OpenVPN

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

ทรานสปอร์ตเปลี่ยนอะไรจริง ๆ

TCP ส่งสตรีมไบต์ที่เชื่อถือได้และเรียงลำดับ และส่งซ้ำทุกอย่างที่สูญหาย ตามที่ RFC 9293 กำหนด UDP ส่งดาต้าแกรมให้เครือข่าย และ OpenVPN ทำงานชั้นความน่าเชื่อถือของตัวเองบนซ็อกเก็ตนั้น การห่อ TCP ไว้ใน TCP ซ้อนลูปการกู้คืนสองชั้น ดังนั้น เซกเมนต์ที่หายไปหนึ่งชิ้นอาจทำให้สตรีมชั้นในหยุดชะงัก จนกว่าการส่งซ้ำชั้นนอกจะมาถึง ปฏิสัมพันธ์นั้นคือข้อโต้แย้งจริงสำหรับ UDP และมันปรากฏเป็นความหน่วง ไม่ใช่ปริมาณงาน

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

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

ที่ซึ่ง TCP ได้ที่ของมัน

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

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

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

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

ตรวจสอบว่าคุณมีผู้ฟังตัวใดจริง ๆ

ก่อนเปรียบเทียบประสิทธิภาพ ให้ยืนยันว่าทั้งสองฝั่งเห็นตรงกันเรื่องทรานสปอร์ตและพอร์ต การเปลี่ยน proto udp เป็น proto tcp ในไฟล์ไคลเอนต์ไม่ได้สร้างผู้ฟังบนเซิร์ฟเวอร์ เซิร์ฟเวอร์ต้องถูกกำหนดค่าสำหรับโปรโตคอลนั้น และโปรไฟล์ต้องตรงกับมัน

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep พิมพ์สิ่งที่เซิร์ฟเวอร์ได้รับคำสั่งให้ใช้ ในขณะที่รายการซ็อกเก็ตสองรายการแสดงว่ามันผูกกับอะไร ผู้ฟัง UDP ปรากฏเฉพาะในรายการแรกและผู้ฟัง TCP เฉพาะในรายการที่สอง ดังนั้นบรรทัดที่หายไปคือวิธีที่เร็วที่สุดในการค้นหาโปรไฟล์ที่ไม่เคยถูกนำไปใช้ เปรียบเทียบพอร์ตด้วย เพราะโปรไฟล์ TCP บน 1194 ทำงานต่างจากอันบน 443 ในเครือข่ายการเข้าถึงส่วนใหญ่ รีสตาร์ทบริการหลังการเปลี่ยนแปลงและอ่านบรรทัดบันทึกที่รายงานการผูก

การยืนยันฝั่งไคลเอนต์นั้นถูก: รันการเชื่อมต่อด้วย --verb 4 แล้วอ่านบรรทัดทรานสปอร์ตในบันทึก ถ้าไคลเอนต์บอก UDP ในขณะที่เซิร์ฟเวอร์ฟังบน TCP การจับมือจะไม่เริ่มเลย และการปรับแต่งใดก็ไม่ช่วย

เปรียบเทียบภาระงาน ไม่ใช่ป้ายชื่อทรานสปอร์ต

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

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

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