OpenVPN: สถาปัตยกรรม VPN ที่ใช้ TLS

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

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

การเข้ารหัสช่องข้อมูลจะเจรจาผ่านช่องควบคุม TLS OpenVPN 2.4 และรุ่นถัดมาจะใช้ AES-256-GCM เป็นค่าเริ่มต้น ซึ่งเป็นรหัสลับ AEAD ที่ให้ทั้งความลับและความถูกต้องครบถ้วนภายในการทำงานเดียว รุ่นก่อนหน้านี้ใช้ AES-256-CBC ร่วมกับ HMAC-SHA256 แยกกัน โดยทั่วไปนิยมใช้โหมด AEAD เพราะไม่จำเป็นต้องตรวจสอบ MAC แยกต่างหาก และต้านทานการโจมตีแบบช่องโหว่ตัวถอดรหัสส่วนเติมเต็ม

ตัวเลือก tls-crypt จะห่อหุ้มเซสชัน TLS ทั้งหมด รวมถึงข้อความทักทายของไคลเอ็นต์ ไว้ภายในซองข้อความสมมาตรที่ยืนยันด้วย HMAC โดยใช้กุญแจที่แบ่งปันล่วงหน้า นั่นหมายความว่าไคลเอ็นต์ที่ยังไม่ได้ยืนยันตัวตนจะไม่สามารถเริ่มการจับมือ TLS ได้ด้วยซ้ำ แพ็กเก็ตเริ่มต้นของไคลเอ็นต์จะถูกทิ้งโดยไม่มีการตอบสนอง วิธีนี้ช่วยป้องกันเซิร์ฟเวอร์ OpenVPN จากการโจมตีขยายผลแบบ DDoS ที่อาศัย TLS และซ่อนข้อเท็จจริงว่ามีเซิร์ฟเวอร์ VPN กำลังทำงานอยู่

ตัวเลือก tls-auth รุ่นเก่าจะเพิ่มแท็ก HMAC ให้กับแพ็กเก็ตช่องควบคุม TLS แต่ไม่ได้เข้ารหัสแพ็กเก็ตเหล่านั้น วิธีนี้ป้องกันการแทรกแพ็กเก็ตได้ แต่ผู้สังเกตการณ์ยังคงเห็นการจับมือ TLS tls-crypt จะเข้ารหัสและยืนยันความถูกต้องของส่วนห่อหุ้มช่องควบคุม จึงให้ทั้งการป้องกัน DoS และการต้านทานการวิเคราะห์ทราฟฟิก ปัจจุบันแนะนำให้ใช้ tls-crypt ส่วน tls-auth เลิกใช้แล้วและแทนที่ด้วย tls-crypt-v2

OpenVPN ยืนยันตัวตนไคลเอ็นต์โดยใช้ใบรับรอง X.509 ที่ลงนามโดยหน่วยงานออกใบรับรองของ VPN ไคลเอ็นต์แต่ละรายจะได้รับใบรับรองและกุญแจส่วนตัวที่ไม่ซ้ำกัน เซิร์ฟเวอร์จะตรวจสอบสายโซ่ใบรับรอง และอาจตรวจสอบรายการเพิกถอนใบรับรอง (CRL) เพื่อปฏิเสธใบรับรองที่ถูกเพิกถอน การเพิกถอนใบรับรองจะยกเลิกสิทธิ์เข้าถึงของไคลเอ็นต์รายนั้นทันที ต่างจากระบบที่ใช้ PSK ซึ่งการเปลี่ยนกุญแจจะส่งผลกระทบต่อไคลเอ็นต์ทั้งหมด

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

OpenVPN ทำงานในโหมด tun (การกำหนดเส้นทาง) หรือโหมด tap (การเชื่อมบริดจ์) โหมด tun สร้างอินเทอร์เฟซเครือข่าย IP แบบจุดต่อจุด และกำหนดเส้นทางแพ็กเก็ต IP ระหว่างไคลเอ็นต์กับเครือข่าย VPN โหมด tap สร้างอินเทอร์เฟซบริดจ์ Ethernet และส่งต่อเฟรม Ethernet ซึ่งรวมถึงการกระจายสัญญาณและโพรโทคอลที่ไม่ใช่ IP โหมด tun มีประสิทธิภาพมากกว่าและเหมาะกับกรณีใช้งาน VPN ส่วนใหญ่ ส่วนโหมด tap จำเป็นเมื่อต้องเชื่อมบริดจ์ส่วนเครือข่ายหรือใช้โพรโทคอลที่ไม่ใช่ IP

เซิร์ฟเวอร์ OpenVPN สามารถส่งคำสั่งกำหนดค่าไปยังไคลเอ็นต์ที่เชื่อมต่อโดยอัตโนมัติ คำสั่งที่ใช้บ่อย ได้แก่ push "route 10.0.0.0 255.0.0.0" (เพิ่มเส้นทางบนไคลเอ็นต์), push "dhcp-option DNS 10.0.0.1" (กำหนดเซิร์ฟเวอร์ DNS) และ push "redirect-gateway def1" (กำหนดเส้นทางทราฟฟิกทั้งหมดของไคลเอ็นต์ผ่าน VPN) วิธีนี้รวมการจัดการการกำหนดค่าไคลเอ็นต์ไว้ที่ศูนย์กลาง โดยไม่ต้องแก้ไขไฟล์กำหนดค่าของไคลเอ็นต์แต่ละราย

OpenVPN ทำให้เกิดความลับล่วงหน้าแบบสมบูรณ์ผ่าน TLS ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) ในช่องควบคุม โดยใช้คู่กุญแจแบบชั่วคราวใหม่สำหรับแต่ละเซสชัน TLS ดังนั้นจึงไม่สามารถอนุมานกุญแจเซสชันจากกุญแจส่วนตัวของใบรับรองระยะยาวของเซิร์ฟเวอร์ได้ แม้จะบันทึกทราฟฟิกที่เข้ารหัสไว้ในวันนี้แล้วได้ใบรับรองเซิร์ฟเวอร์มาในภายหลัง ก็ยังไม่สามารถถอดรหัสเซสชันที่ผ่านมาได้

OpenVPN 2.5 เลิกใช้รหัสลับ Blowfish (BF-CBC) ซึ่งในอดีตเป็นค่าเริ่มต้น BF-CBC ใช้ขนาดบล็อก 64 บิตที่เสี่ยงต่อการโจมตีแบบวันเกิด SWEET32 เมื่อใช้เซสชันเป็นเวลานาน OpenVPN รุ่นใหม่ใช้ AES-256-GCM เป็นค่าเริ่มต้น นอกจากนี้ OpenVPN 2.5 ยังเลิกใช้รหัสลับที่ไม่ใช่ AEAD ในช่องข้อมูล และเพิ่มข้อกำหนดรุ่นขั้นต่ำของ TLS โดยยกเลิกการรองรับ TLS 1.0 และ 1.1

สรุป OpenVPN: ช่องควบคุมใช้ TLS สำหรับการยืนยันตัวตนและการเจรจารหัสลับ ช่องข้อมูลใช้รหัสลับ AEAD ที่เจรจาไว้ โดยมี AES-256-GCM เป็นค่าเริ่มต้น tls-crypt ห่อหุ้ม TLS เพื่อป้องกันการจับมือที่ยังไม่ได้ยืนยันตัวตน ECDHE ให้ความลับล่วงหน้า มีการยืนยันตัวตนไคลเอ็นต์ด้วยใบรับรองและการเพิกถอนผ่าน CRL นิยมใช้ UDP มากกว่า TCP เพื่อประสิทธิภาพ และนิยมใช้โหมด tun สำหรับกรณีใช้งานที่ต้องกำหนดเส้นทาง IP