สคริปต์ up ของ OpenVPN ทำงานเร็วเกินไป หรือมันไม่เคยพร้อมเลย?

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

การทดสอบในเชลล์สำเร็จเพราะมันทำงานหลังจากทุกอย่างเข้าที่แล้ว ฮุกทำงาน ณ ช่วงเวลาหนึ่งโดยเฉพาะ

up อยู่ตรงไหนในลำดับการเริ่มต้น

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

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

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

ฮุกรับช่วงอะไรมาจริงๆ

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

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

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

ทำไมการเพิ่มการหน่วงจึงไม่ใช่การตรวจสอบความพร้อม

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

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

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

การทำความสะอาดและการเชื่อมต่อใหม่สมควรได้รับความเอาใจใส่เช่นเดียวกัน

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

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

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

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