VPN หลุดเมื่อหน้าจอมืด: ล็อก จอดับ หรือพักเครื่อง?

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

ตรวจข้อหนึ่ง: แยกล็อกออกจากการปิดจอและการหลับ

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

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

ตรวจข้อสอง: วางเหตุการณ์ด้านพลังงานและเครือข่ายบนเส้นเวลาเดียวกัน

อ่านบันทึกสำหรับช่วงเวลาจำกัดแทนการบูตทั้งหมด และใส่ทั้งตัวจัดการล็อกอินและเจ้าของการเชื่อมต่อ

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

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

บรรทัดที่หายไปไม่ใช่ผลลบ หากบันทึกของยูนิตที่เลือกไม่ปรากฏต่อบัญชีของคุณ การไม่มีบันทึกการหลับไม่ได้พิสูจน์อะไร และการสรุปว่า «มันไม่เคยหลับเลย» จากตัวกรองว่างคือเส้นทางที่ผู้คนใช้เวลาหนึ่งสัปดาห์ปรับแต่งสัญญาณคงการเชื่อมต่อ

ตรวจข้อสาม: หากมันหลับ ให้ตัดสินว่าเจตนาหรือไม่

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

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

ตรวจข้อสี่: หากมันยังตื่นอยู่ ให้ดูที่เครือข่ายและไคลเอนต์

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

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

รายงานที่มีประโยชน์ควรมีอะไร

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

หากแถวใดหายไป นั่นคือสิ่งที่ต้องวัดต่อไป ไม่ใช่สิ่งที่ต้องเปลี่ยนต่อไป เส้นเวลาที่มีช่องว่างให้ข้อมูลมากกว่าการเปลี่ยนการตั้งค่าที่ทำตามความรู้สึก