SSH ไม่รับฟังหลังรีบูต: ที่อยู่ VPN มาช้า

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

ข้อผิดพลาดในการผูกบอกอะไรจริง ๆ

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

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

โปรเซสใดเป็นเจ้าของพอร์ต

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

ทำให้ความพร้อมชัดเจน ไม่ใช่การหลับ

การหน่วงเวลาคงที่เป็นการเดาที่ปฏิบัติต่อฮาร์ดแวร์เร็วและเครือข่ายช้ากับเหมือนกัน จงแสดงความขึ้นต่อกันแทน รอที่อยู่แล้วจึงเริ่ม

ip -4 addr show dev tun0
systemctl edit ssh.service

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

ทดสอบการบูตที่สะอาดและการเชื่อมต่อใหม่

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

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

เกณฑ์ความสำเร็จคือตัวรับฟังที่ปรากฏภายใต้ความขึ้นต่อกันที่บันทึกไว้ ไม่ใช่ตัวที่ใครจำได้ให้รีสตาร์ต