VPN ของคุณใช้งานได้หลังล็อกอินเท่านั้น เพราะพวงกุญแจ

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

ทำไมการล็อกอินจึงทำให้มันทำงาน

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

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

ตัดสินใจว่าเจ้าของใดเริ่มอุโมงค์

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

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

อย่ารันเจ้าของทั้งสองกับคอนฟิกเดียวกัน ถ้า NetworkManager จัดการอินเทอร์เฟซและ unit ก็ยกมันขึ้นมาด้วย ทั้งสองจะแย่งเส้นทางและ DNS และสถานะสุดท้ายขึ้นกับว่าใครเสร็จทีหลัง

วางความลับไว้ที่ที่บริการอ่านได้

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

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

ทดสอบเหตุการณ์ที่เกิดขึ้นจริง

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

ตรวจเส้นทางและ DNS ไม่ใช่แค่อินเทอร์เฟซ

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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