ให้บริการ OpenVPN ผ่าน TCP และ UDP จากโฮสต์เดียว
ก่อน 2.7 หนึ่งโพรเซสผูกได้เพียงหนึ่งทรานสปอร์ต เปรียบเทียบคู่ TAP ที่ทำบริดจ์ สองซับเน็ต TUN และพูลที่แชร์ร่วมกัน แล้วจับคู่แต่ละโปรไฟล์กับตัวรับฟังของมัน
เครือข่ายที่อนุญาตเฉพาะ TCP 443 อยู่ร่วมกับเครือข่ายที่ปล่อย UDP ผ่านได้อย่างไม่มีปัญหา และเซิร์ฟเวอร์หนึ่งเครื่องต้องให้บริการทั้งสองกลุ่ม โปรไฟล์ที่มี proto udp ตอบกลุ่มที่สองและล้มเหลวในกลุ่มแรก และการแก้ไขคอนฟิกูเรชันเดียวกันให้เป็น proto tcp ไม่ได้สร้างตัวรับฟังตัวที่สอง คำสั่งนี้เลือกทรานสปอร์ตเดียวต่อหนึ่งโพรเซส ทุกอย่างที่เหลือตามมาจากข้อจำกัดนั้น
ไม่ก็รันมากกว่าหนึ่งโพรเซส หรือไม่ก็รันเวอร์ชันที่ผูกหลายซ็อกเก็ตได้พร้อมกัน
ก่อน 2.7 หนึ่งโพรเซสผูกได้เพียงหนึ่งทรานสปอร์ต
OpenVPN ของชุมชนผูกซ็อกเก็ตที่ proto อธิบาย และคำสั่งนั้นเลือกทรานสปอร์ตเดียวให้กับอินสแตนซ์ TCP กับ UDP เป็นสแตกที่แยกจากกัน หมายเลขพอร์ตเดียวกันจึงถูกครอบครองโดยทั้งสองพร้อมกันได้ แต่ไม่ใช่โดยโพรเซสเดียว ดังนั้นสาย 2.6 จึงให้หนึ่งทรานสปอร์ตต่อเดมอน OpenVPN 2.7 ยกเลิกข้อจำกัดนั้นสำหรับเซิร์ฟเวอร์ ซึ่งผูกหลายซ็อกเก็ตได้ผ่านคำสั่ง --local หลายคำสั่งในโพรเซสเดียว
ตรวจสอบเวอร์ชันก่อนออกแบบโดยอิงคำตอบใดคำตอบหนึ่ง เพราะการจัดวางแบบ 2.7 เป็นโมเดลปฏิบัติการอีกแบบที่มีไวยากรณ์คอนฟิกูเรชันของตัวเอง คู่มือที่เขียนสำหรับ 2.6 อธิบายสองโพรเซสแม้จะไม่ได้บอกไว้
สามวิธีในการรันสองอินสแตนซ์
ด้วยอินเทอร์เฟซ TAP ให้รันหนึ่งอินสแตนซ์ต่อทรานสปอร์ตและทำบริดจ์อุปกรณ์ tap สองตัวบนโฮสต์ กลุ่มไคลเอนต์ทั้งสองอยู่ในโดเมนบรอดแคสต์เดียวกัน ทำให้พูลแอดเดรสเดียวครอบคลุมทั้งสองกลุ่มได้ และโปรโตคอลที่พึ่งพาการกระจายสัญญาณยังทำงานอยู่ ด้วย TUN การทำบริดจ์ทำไม่ได้ การแบ่งที่ง่ายที่สุดจึงให้แต่ละอินสแตนซ์มีซับเน็ตของตัวเองและให้เราเตอร์แยกสองกลุ่มไคลเอนต์ออกจากกัน ทางเลือกที่สามคงพูลเดียวไว้โดยให้แต่ละอินสแตนซ์เรียกสคริปต์ learn-address ซึ่งติดตั้งเส้นทาง /32 ให้ไคลเอนต์ผ่านอุปกรณ์ของอินสแตนซ์นั้น
การจัดวางแบบที่สามคือสิ่งที่คนต้องการและเป็นแบบที่ต้องระวังที่สุด เพราะสคริปต์กลายเป็นส่วนหนึ่งของเส้นทางข้อมูลและต้องจัดการเหตุการณ์เพิ่ม อัปเดต และลบอย่างถูกต้อง
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
แยกสองอินสแตนซ์ออกจากกัน
แต่ละอินสแตนซ์ยังต้องมีพอร์ตหรือแอดเดรสแยก ไฟล์สถานะแยก และปลายทางล็อกแยก เดมอนสองตัวที่เขียนไฟล์สถานะเดียวกันจะสร้างเอาต์พุตที่อ่านไม่ได้เมื่อเกิดเหตุ ซึ่งเป็นเวลาที่คุณต้องการมันที่สุด ถ้าอินสแตนซ์ที่สองผูกแอดเดรสเฉพาะ แอดเดรสนั้นต้องมีอยู่บนโฮสต์ตอนโพรเซสเริ่มทำงาน ไม่เช่นนั้นมันจะจบด้วยการผูกไม่สำเร็จก่อนจะพูดอะไรเกี่ยวกับคีย์
ตั้งชื่อยูนิตและโปรไฟล์ให้เห็นทรานสปอร์ตได้จากชื่อไฟล์ ผู้ดูแลคนต่อไปไม่ควรต้องเปิดคอนฟิกูเรชันเพื่อรู้ว่าตัวไหนเป็น TCP
จับคู่โปรไฟล์กับตัวรับฟัง
เซิร์ฟเวอร์ที่รัน proto tcp คาดหวังโปรไฟล์ไคลเอนต์ที่มี proto tcp-client และโปรไฟล์ที่ยังมี proto udp เมื่อเจอตัวรับฟังนั้น จะหมดเวลาโดยไม่มีข้อผิดพลาดที่ผู้ใช้จะจัดการได้ เก็บโปรไฟล์ไว้สองชุดถ้าการติดตั้งมีทั้งสองทรานสปอร์ต และติดป้ายให้ทีมซัพพอร์ตรู้ว่าลองชุดไหนแล้ว หมายเลขพอร์ตอย่างเดียวไม่ได้บอกทรานสปอร์ต
กฎไฟร์วอลล์ก็แบ่งแบบเดียวกัน กฎสำหรับ UDP 1194 ไม่ได้บอกอะไรเกี่ยวกับ TCP 1194 และกฎสำหรับแอดเดรสหนึ่งไม่ได้ครอบคลุมตัวรับฟังอีกตัว
อ่านมุมมองของเซิร์ฟเวอร์ก่อน
เริ่มด้วย ss -lntup บนเซิร์ฟเวอร์และยืนยันว่ามีทั้งตัวรับฟัง TCP และ UDP จากนั้นเชื่อมไคลเอนต์ประเภทละหนึ่งตัวและตรวจเอาต์พุตสถานะว่ามีสองรายการที่แอดเดรสต่างกัน ถ้าซ็อกเก็ตมีอยู่แต่ไม่มีไคลเอนต์เข้ามา แสดงว่าเส้นทางหรือไฟร์วอลล์ปฏิเสธแพ็กเก็ตก่อนที่เดมอนจะเห็น
ซ็อกเก็ตที่ไม่เคยปรากฏคือปัญหาคอนฟิกูเรชันหรือการผูก และซ็อกเก็ตที่ปรากฏแต่ไม่เคยบันทึกการเชื่อมต่อคือปัญหาการกรอง สองอย่างนี้ดูเหมือนกันจากฝั่งไคลเอนต์ จึงต้องดูมุมมองของเซิร์ฟเวอร์เองก่อน จำไว้ว่า TCP มีการบล็อกหัวคิว ดังนั้นการให้บริการจึงเป็นมาตรการด้านการเข้าถึง ไม่ใช่การอัปเกรดสำหรับไคลเอนต์ที่มีเส้นทาง UDP ปลอดโปร่ง