Access Server สูญเสียการผูกกับที่อยู่หลังจากเปลี่ยนชื่ออินเทอร์เฟซเครือข่าย: แก้ไขคีย์

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

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

อาการบอกอะไรจริง ๆ

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

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

สอบถามการกำหนดค่าก่อนแก้ไข

Access Server เปิดเผยการกำหนดค่าผ่าน CLI ของตัวเอง มุมมองที่มีเอกสารคือ:

sacli ConfigQuery

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

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

ระบุว่าผู้รับฟังตัวใดเสีย

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

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

เปลี่ยนการตั้งค่าที่ระบุชื่อ ไม่ใช่แถวที่ตรงกัน

บทเรียนบันทึก ConfigPut บนคีย์เฉพาะ เช่น vpn.daemon.0.server.ip_address และ vpn.daemon.0.listen.ip_address ใช้วิธีการของผลิตภัณฑ์เองกับชื่อคีย์และค่าใหม่ ในไวยากรณ์ที่เอกสารของเวอร์ชันคุณระบุ และเปลี่ยนเฉพาะคีย์ของผู้รับฟังที่คุณวินิจฉัย

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

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

นำไปใช้ แล้วพิสูจน์ว่าเส้นทางทำงาน

หลังจากแก้ค่าแล้ว นำไปใช้ผ่านวงจรชีวิตที่มีเอกสารของผลิตภัณฑ์ ( วงจรชีวิต ) บทเรียนใช้ sacli start หลังจากตั้งคีย์ ซึ่งไม่ใช่การรีบูตโฮสต์เต็มรูปแบบหรือการรีเซ็ตฐานข้อมูล

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

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