เส้นทางของอุปกรณ์ OpenVPN: เจ้าของการกำหนดค่าหรือสคริปต์เริ่มระบบ?
เส้นทางสาขาที่รอดจากการรีบูตหนึ่งครั้งยังอาจหายไปหลังการบันทึกจาก GUI หรือการอัปเดตเฟิร์มแวร์ เปรียบเทียบเจ้าของการกำหนดค่าที่รองรับกับสคริปต์แพตช์
คุณเพิ่มเส้นทางสาขา มันทำงานได้ แล้วการอัปเดตเฟิร์มแวร์หรือการบันทึกจากเว็บ UI ก็ลบมันออก ในขณะนั้นการแก้ไขสองวิธีดูสมเหตุสมผลเท่ากัน: วางเส้นทางไว้ในแหล่งการกำหนดค่าที่รองรับของอุปกรณ์ หรือเพิ่มเส้นทางลงในไฟล์ที่สร้างขึ้นจากสคริปต์เริ่มระบบ ทั้งสองทำงานเหมือนกันหนึ่งสัปดาห์และแตกต่างกันในการอัปเกรดครั้งที่สอง บทความนี้เปรียบเทียบว่าแต่ละวิธีเป็นเจ้าของอะไรจริง ๆ
ผู้สมัครสองรายเป็นเจ้าของสิ่งที่ต่างกัน
แหล่งการกำหนดค่าที่รองรับคือทุกสิ่งที่อุปกรณ์ถือเป็นอินพุต: ฟิลด์ GUI โปรไฟล์ที่นำเข้า ไดเรกทอรีที่จัดทำเอกสารต่อไคลเอนต์ ฐานข้อมูลการตั้งค่าที่แพ็กเกจการจัดการอ่าน ไฟล์ server.conf ที่สร้างขึ้นคือเอาต์พุต การแก้ไขเอาต์พุตใช้งานได้จนกว่าตัวสร้างจะทำงานอีกครั้ง ซึ่งเกิดขึ้นเมื่อบันทึก เมื่อรีบูต และเมื่ออัปเกรด
วิธีสคริปต์จะแพตช์เอาต์พุตนั้นหลังตัวสร้างทำงานเสร็จ เป็นเทคนิคที่ชอบด้วยกฎหมายสำหรับห้องแล็บ และเป็นการตั้งค่าเริ่มต้นที่ผิดสำหรับสำนักงานสาขา เพราะทำให้เส้นทางขึ้นอยู่กับการจับคู่ข้อความแทนฟิลด์ที่จัดทำเอกสาร
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
อุปกรณ์สร้างอะไรใหม่ และเมื่อใด
แพ็กเกจการจัดการมักเก็บการตั้งค่าไว้ในฐานข้อมูลหรือชุดเทมเพลตและสร้างการกำหนดค่าของดีมอนเมื่อเริ่มระบบ การบันทึกจากเว็บ UI มักเขียนไฟล์ทั้งหมดใหม่แทนการแพตช์หนึ่งบรรทัด หากการเปลี่ยนแปลงของคุณอยู่ในไฟล์นั้น ตอนนี้มันหายไปแล้ว และไม่มีอะไรบันทึกคำเตือน เพราะจากมุมมองของอุปกรณ์ไม่มีอะไรสูญหาย
ตัวห่อเริ่มระบบมีโหมดล้มเหลวแบบที่สอง grep สำหรับคำสั่งที่มีการเว้นวรรคเฉพาะจะหยุดจับคู่หลังการเปลี่ยนเทมเพลต และสคริปต์ก็เงียบ ๆ ไม่ทำอะไร แย่กว่านั้น การอัปเดตเฟิร์มแวร์อาจแทนที่ตัวห่อด้วยเวอร์ชันใหม่ พาแพตช์ไปด้วย คุณจึงมีเส้นทางที่มีอยู่หนึ่งปีและหายไประหว่างการบำรุงรักษาที่ไม่มีใครเชื่อมโยงกับการกำหนดเส้นทาง
เจ้าของที่รองรับต้องแสดงอะไร
คำนำหน้าสาขาต้องการสามข้อความ ไม่ใช่หนึ่ง ไคลเอนต์ต้องเรียนรู้เส้นทาง เซิร์ฟเวอร์ต้องรู้ว่าไคลเอนต์ที่ผ่านการยืนยันตัวตนรายใดเป็นเจ้าของคำนำหน้า และฝั่งสาขาต้องส่งทราฟฟิกกลับไปยังที่อยู่ทันเนลที่ได้รับ ในแง่ของ OpenVPN นั่นหมายถึง route ที่พุชไป ความสอดคล้อง iroute ที่ผูกกับไคลเอนต์ และเส้นทางกลับในอีกด้านหนึ่ง
นี่คือจุดที่ UI ของอุปกรณ์ทำให้เข้าใจผิด กล่องกาเครื่องหมายที่ระบุว่า “อนุญาตให้ไคลเอนต์เข้าถึง LAN ของเซิร์ฟเวอร์” อธิบายทราฟฟิกไปยังเครือข่ายของเซิร์ฟเวอร์เอง สาขาของคุณเป็นทิศทางตรงกันข้าม: เครือข่ายที่อยู่หลังไคลเอนต์หนึ่งราย เข้าถึงได้จากฝั่งเซิร์ฟเวอร์ ป้ายเดียวกันไม่ได้หมายถึงการรองรับสิ่งนั้น และคำสั่งที่ถูกต้องในไฟล์ก็ไม่ใช่คำสัญญาว่าแพ็กเกจจะรักษาไว้
เมื่อไม่มีการควบคุมที่รองรับ
บางครั้งรีลีสที่ติดตั้งไว้ไม่สามารถแสดงเส้นทางเฉพาะคู่ได้จริง ๆ ตัวเลือกที่ซื่อตรงคือเกตเวย์อื่นที่คุณควบคุม หรือโหมดไซต์ถึงไซต์ที่รองรับทั้งสองด้าน ปลายทั้งสองต้องพูดภาษาเดียวกัน หน้าผลิตภัณฑ์ที่บอกว่าไซต์ถึงไซต์ไม่ได้ทำให้โปรไฟล์ OpenVPN ใด ๆ แลกเปลี่ยนได้กับทันเนลของโปรโตคอลอื่น และการบังคับคู่นั้นมักสร้างทันเนลที่เชื่อมต่อครึ่งเดียวซึ่งดูดีในหน้าสถานะ
เลือกตัวเลือกที่คุณอธิบายได้ในหนึ่งประโยคให้กับผู้ที่รับช่วงเครือข่าย หากคำตอบต้องกล่าวถึงเส้นทางสคริปต์และรูปแบบข้อความ การออกแบบก็เปราะบางอยู่แล้ว
ทำให้เจตนาตรวจสอบได้
บันทึกสัญญาไว้นอกอุปกรณ์: ตัวตนไคลเอนต์ที่แท้จริง คำนำหน้า เกตเวย์ขากลับ และฟิลด์ที่รองรับซึ่งจัดหาแต่ละอย่าง ส่งออกการกำหนดค่าผ่านกลไกที่รองรับเพื่อให้การสร้างใหม่มีข้อมูลอ้างอิง และตรวจสอบบริการหลังการเชื่อมต่อใหม่ การรีสตาร์ต และการอัปเกรด ไม่ใช่หลังการเปลี่ยนแปลงเท่านั้น
เมื่อมีบางอย่างเสีย ให้เปรียบเทียบผลลัพธ์ที่สร้างขึ้นกับบันทึกนั้น แทนการคืนบรรทัดที่อธิบายไม่ได้และหวังข้อมูลอ้างอิง OpenVPN 2.6 คือจุดที่ใช้ยืนยันว่า route และ iroute โต้ตอบกันอย่างไรก่อนที่คุณจะโต้แย้งกับ UI
รายการตรวจสอบสำหรับการเปลี่ยนแปลงครั้งถัดไป: ระบุชื่อเจ้าของ ระบุสัญญาสามส่วน ส่งออกเจตนา และทดสอบซ้ำหลังเหตุการณ์วงจรชีวิตของอุปกรณ์เอง ไม่ใช่หลังการแก้ไขของคุณ