ไล่ไคลเอนต์ OpenVPN หนึ่งตัวออก: kill, deny หรือเพิกถอนใบรับรอง?
การกระทำสามอย่างของ OpenVPN ลบไคลเอนต์ แต่แต่ละอย่างจบสิ่งต่างกัน: เซสชันที่กำลังทำงาน ความพยายามล็อกอินหนึ่งครั้ง หรือสิทธิ์ในการเชื่อมต่อใหม่ เลือกตามตัวตน
คุณมี common name และที่อยู่ในบันทึก และมีสามคำสั่งที่ดูเหมือนลบไคลเอนต์ทั้งหมด มีเพียงคำสั่งเดียวที่ทำสิ่งที่คุณต้องการ และการเลือกขึ้นอยู่กับว่าคุณต้องจบเซสชันที่กำลังทำงานอยู่ตอนนี้ ปฏิเสธการล็อกอินครั้งถัดไป หรือริบสิทธิ์ในการเชื่อมต่อทั้งหมด อ่านตัวตนที่คุณมีจริงก่อนจะแตะอะไร เพราะพูลของ OpenVPN จะมอบที่อยู่ทันเนลเดียวกันให้เซสชันอื่นในภายหลัง
จริง ๆ แล้วคุณมีตัวตนใด
ไฟล์สถานะเวอร์ชัน 3 คือจุดเริ่มต้นปกติ ส่วน CLIENT_LIST มี common name ที่อยู่จริง ตัวนับไบต์ และเวลาที่เชื่อมต่อ ส่วน ROUTING TABLE จับคู่ที่อยู่เสมือนกับ common name พร้อมตราเวลาของการอ้างอิงครั้งล่าสุด common name คือตัวตนที่มั่นคง ที่อยู่เสมือนเป็นการจัดสรร และที่อยู่จริงหลัง NAT อาจเปลี่ยนระหว่างเซสชันโดยไม่มีอะไรเปลี่ยนบนเซิร์ฟเวอร์
อินเทอร์เฟซการจัดการแสดงมุมมองคล้ายกันผ่านคำสั่ง status และเพิ่ม ID ไคลเอนต์ต่อเซสชัน client-kill รอ ID นั้น และมันไม่ใช่ที่อยู่ทันเนล หากคุณต้องรู้ว่า common name ใดได้รับที่อยู่ใดตอนเชื่อมต่อ สภาพแวดล้อมของสคริปต์ client-connect มีทั้งสองอย่างพร้อมที่อยู่ภายนอกที่เชื่อถือได้ แต่สคริปต์นั้นทำงานในฐานะผู้ใช้ OpenVPN และต้องมีพาธบันทึกที่เขียนได้
| What you hold | Where it came from | What it can act on |
|---|---|---|
| Common name | CLIENT_LIST, or the auth hook | kill, and credential revocation |
| Client ID | status on the management socket | client-kill, that one session |
| Tunnel address | ROUTING TABLE, client-connect environment | Nothing durable, the address is recycled |
ฆ่าตอนนี้ ปฏิเสธตอนล็อกอิน เพิกถอนตลอดไป
คำสั่งลบทั้งสองในอินเทอร์เฟซการจัดการเป็นการกระทำต่อเซสชัน kill รับ common name หรือที่อยู่จริงและพอร์ต client-kill รับ ID ไคลเอนต์และจบอินสแตนซ์นั้นทันที ทั้งสองไม่ใช่การบล็อก ไคลเอนต์ที่ถูกไล่ออกซึ่งมีใบรับรองและรหัสผ่านที่ใช้ได้จะเชื่อมต่อใหม่ภายในไม่กี่วินาที ซึ่งดีเมื่อคุณนำ peer ทดสอบกลับมาใช้และไร้ประโยชน์เมื่อแล็ปท็อปถูกขโมย
client-deny เป็นการตัดสินใจอีกชนิด โดยปกติออกจากฮุก authentication หรือ client-connect และปฏิเสธเซสชันพร้อมเหตุผล จึงเหมาะกับนโยบายที่ปฏิเสธการล็อกอินมากกว่านโยบายที่ตัดการเชื่อมต่อ เอกสารยังเตือนว่าการปฏิเสธที่ออกระหว่างการเจรจา TLS ใหม่จะทำให้คีย์ที่เจรจาใหม่เป็นโมฆะ ขณะที่เซสชันที่มีอยู่สามารถทำงานต่อได้จนหน้าต่างการเปลี่ยนผ่านปิดลง หากข้อกำหนดคือให้ไคลเอนต์หายไปตอนนี้ คำตอบตามเอกสารคือ client-kill
การลบถาวรอยู่ใต้ทั้งหมดนี้ เพิกถอนใบรับรองและตรวจสอบว่า crl-verify ชี้ไปยังรายการที่เซิร์ฟเวอร์โหลดซ้ำจริง ปิดใช้งานไฟล์กำหนดค่าที่เฉพาะเจาะจงไคลเอนต์ในไดเรกทอรี ccd หรือปิดใช้งานบัญชีใน backend ที่ฮุก authentication สอบถาม การเพิกถอนก็ไม่ทันทีเช่นกัน ด้วยการตั้งค่า reneg-sec เริ่มต้น เซสชันที่สร้างแล้วอาจทำงานต่อไปจนกว่าจะเจรจาใหม่ ดังนั้นการกระทำต่อเซสชันและการกระทำต่อข้อมูลรับรองจึงเสริมกัน ไม่ใช่ทางเลือกแทนกัน
ซ็อกเก็ตการจัดการว่างหรือไม่
อินเทอร์เฟซการจัดการให้บริการไคลเอนต์ทีละตัว หาก GUI หรือแดมอนตรวจสอบถือการเชื่อมต่ออยู่แล้ว สคริปต์ของคุณจะเกาะข้างไม่ได้ และขึ้นอยู่กับไคลเอนต์คุณอาจดันตัวที่มีอยู่ออกแทนที่จะล้มเหลวอย่างสะอาด รหัสผ่านของมันเดินทางเป็นข้อความธรรมดาบนซ็อกเก็ตนั้น จึงควรอยู่บนที่อยู่ท้องถิ่นหรือซ็อกเก็ต unix ไม่เคยบนอินเทอร์เฟซสาธารณะ
เมื่อคุณใช้ซ็อกเก็ตไม่ได้ คุณยังมีทางเลือก และทั้งหมดช้ากว่า ปล่อยเซสชันของ GUI ก่อนหากคุณควบคุมมัน หรือยอมรับเส้นทางผ่านชั้นข้อมูลรับรองและรอการเจรจาใหม่ครั้งถัดไป สิ่งที่คุณไม่ควรทำคือรีสตาร์ตบริการเพื่อกำจัดไคลเอนต์หนึ่งตัว เพราะนั่นจบเซสชันอื่นทั้งหมดและทำลายหลักฐานในไฟล์สถานะของเซสชันนี้
ลำดับที่ฉันรันบนเซิร์ฟเวอร์จริง
เชื่อมต่อ อ่านสถานะปัจจุบัน ลงมือกับ ID ที่เพิ่งอ่าน แล้วอ่านอีกครั้ง ค่าที่คัดลอกจากเอกสารคือวิธีที่พบบ่อยที่สุดในการฆ่าคนผิด
status # note the client ID and common name
client-kill 3 # end that session now
kill Test-Client # alternative: by common name
status # confirm the session is goneชื่อและหมายเลขข้างบนเป็นตัวยึดตำแหน่ง และ ID ถูกนำกลับมาใช้หลังไคลเอนต์อื่นตัดการเชื่อมต่อ ยืนยันว่าไม่มีแถวนั้นก่อนจะบันทึกว่าเสร็จ และตรวจว่าจำนวนไคลเอนต์ที่เชื่อมต่อขยับไปหนึ่งไม่ใช่หลายตัว
ยืนยันว่ามันอยู่ห่างไป
บันทึก common name ที่อยู่ทันเนล ที่อยู่ภายนอก และนาทีที่ลบ หาก common name เดิมปรากฏอีกครั้งในอีกหนึ่งนาที แสดงว่าการกระทำต่อเซสชันได้ผลแต่ชั้นข้อมูลรับรองไม่ได้ผล ซึ่งเป็นการซ่อมแซมที่ต่างจากการที่คำสั่งไม่เคยมีผลเลย
จากนั้นทดสอบจากฝั่งไคลเอนต์ ใบรับรองที่ถูกเพิกถอนควรล้มเหลวในการจับมือครั้งถัดไป หากยังเชื่อมต่อได้ แสดงว่า CRL ไม่ถูกอ่านเลย และนั่นคือสิ่งที่ควรรายงาน เลือกการกระทำตามสิ่งที่คุณต้องจบ ยืนยันด้วย status ครั้งที่สอง และแก้ชั้นข้อมูลรับรองเมื่อคำตอบต้องอยู่ได้นานกว่าเซสชัน