OpenVPN ผูกที่อยู่ภายในล้มเหลวตอนบูต: รอหรือลองใหม่

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

ทั้งสองทางดีกว่าการหน่วงเวลาคงที่ ซึ่งไม่ได้รออะไรเลยและไม่รายงานว่ากำลังรออะไรอยู่

ตัวเลือก local ต้องการอะไรจริง ๆ

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

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

การรอที่อยู่กับการลองผูกใหม่

การรอหมายถึง ExecStartPre ที่คอยตรวจจนกว่าที่อยู่จะปรากฏ โดยมีจำนวนครั้งจำกัดและออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อหมดเวลา การลองใหม่หมายถึงปล่อยให้โปรเซสหลักล้มเหลวแล้วขอให้ตัวจัดการบริการเริ่มมันใหม่ เช่น Restart=on-failure พร้อม RestartSec=5 วิธีแรกรายงานเงื่อนไขที่ขาดหายในฐานะ unit ที่ล้มเหลว ส่วนวิธีหลังรายงานเป็นชุดการรีสตาร์ตที่ในที่สุดก็หยุด ซึ่งเสียงดังกว่าใน journal แต่ทนต่อที่อยู่ที่มาช้าเพราะเหตุผลที่คุณคาดเดาไม่ได้

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

ทำไม network-online.target จึงไม่พอ

network-online.target สัญญาเพียงสิ่งที่การทำงานของเครือข่ายที่ใช้งานอยู่หมายถึงคำว่า online และไม่มีอะไรมากกว่านั้น ภายใต้ systemd-networkd systemd-networkd-wait-online เป็นตัวตัดสินว่าเป้าหมายนั้นบรรลุเมื่อใด และแนวคิด online ตามค่าเริ่มต้นของมันอาจถูกทำให้พอใจก่อนที่ที่อยู่เฉพาะของคุณจะเกิดขึ้น ภายใต้ NetworkManager บริการ wait-online ใช้กฎของตัวเอง การจัดลำดับให้อยู่หลังเป้าหมายเป็นพื้นฐานที่มั่นคง ไม่ใช่การรับประกันว่าที่อยู่ใดที่อยู่หนึ่ง คำตอบ DNS หรือ peer ปลายทางจะพร้อมแล้ว

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

ตรวจสอบการผูกหลังการบูตเย็น

ตรวจสอบด้วยการบูตเย็นจริง ไม่ใช่การรีสตาร์ตบริการ เพราะการรีสตาร์ตสืบทอดที่อยู่ที่ลำดับการบูตต้องสร้างขึ้น หลังบูต ss -lntp หรือ ss -lunp จะแสดงที่อยู่ภายในที่แต่ละตัวรับฟังผูกไว้จริง และ journalctl -b -u openvpn-server@server จะแสดงว่าความพยายามครั้งแรกล้มเหลวหรือไม่ เปรียบเทียบที่อยู่ที่ผูกไว้กับที่อยู่ในโปรไฟล์ แล้วทำการเปรียบเทียบซ้ำหลังเชื่อมต่อเครือข่ายใหม่

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

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