คู่มือปฏิบัติ: การรับลูกค้า OpenVPN สองรายแยกจากกัน

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

กำหนดการ์ดทรัพยากรที่สมบูรณ์ให้ลูกค้าแต่ละราย

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

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

เก็บวัสดุความเชื่อใจไว้ภายในลูกค้าแต่ละราย

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

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

แยกเครือข่ายเช่นเดียวกับโปรเซส

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

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

ส่งการเพิกถอนก่อนการส่งมอบ

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

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

จากนั้นรันคู่การยอมรับ: ไคลเอนต์ที่ได้รับอนุญาตเข้าถึงบริการของตนเอง และข้อมูลรับรองของ A ถูกปฏิเสธโดยตัวรับฟังของ B นั่นคือขอบเขตที่แสดงออกมาเป็นการทดสอบ