OpenVPN ที่เริ่มทำงานก่อนเครือข่ายพร้อมไม่ใช่ความล้มเหลว

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

ความเชื่อผิด: บริการที่เริ่มแล้วหมายถึงอุโมงค์ที่ทำงานได้

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

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

อ่านเจอร์นัลของอินสแตนซ์นั้นแทนสถานะของยูนิต บรรทัดเหตุผลอยู่ในบันทึก ไม่ใช่ในป้ายสถานะ

ความเชื่อผิด: การตั้งค่าลองใหม่ครอบคลุมทุกความล้มเหลว

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

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

การลองใบรับรองที่ไม่ได้รับอนุมัติไปตลอดไม่ใช่เหตุผลที่จะถอดการตรวจสอบออก แต่เป็นเหตุผลให้อ่านข้อผิดพลาด

ความเชื่อผิด: ตัวเรียกใช้ตัวเดียวก็พอ จึงเพิ่มอีกตัว

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

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

เจ้าของยังกำหนดว่าการลองใหม่และข้อมูลรับรองมาจากไหน จึงต้องตัดสินเรื่องนี้ก่อนปรับแต่งใด ๆ ความเป็นเจ้าของมาก่อนด้วยเหตุผลนั้นเอง

อะไรที่ต้องการลำดับจริง ๆ

ลำดับรอที่อยู่ที่กำหนดค่าไว้ได้ และนั่นคือทั้งหมดที่รับประกัน network-online.target เลื่อนการเปิดใช้งานจนตัวจัดการถือว่าเครือข่ายพร้อม และนิยามของพร้อมขึ้นกับตัวจัดการ มันไม่บอกว่าชื่อโฮสต์ VPN แปลงได้หรือไม่ ตัวรับฟังตอบหรือไม่ หรือพอร์ทัลกับดักอนุญาตอุปกรณ์เข้ามาแล้วหรือยัง

อ่านยูนิตที่ติดตั้งและ drop-in ใด ๆ ก่อนเพิ่ม dependency After= ที่กว้างบนทุกบริการเครือข่ายทำให้บูตช้าลงโดยไม่สร้างการเชื่อมต่อที่คุณต้องการจริง ๆ

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

เกิดอะไรขึ้นหลังอุโมงค์ขึ้นครั้งแรก

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

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

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