VPN หลุดเมื่อหน้าจอดับ: วงจรชีวิตแบบไหน?

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

สามความล้มเหลวที่ดูเหมือนกัน

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

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

เปรียบเทียบสถานะทำงานและไม่ได้ใช้งานภายใต้การควบคุม

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

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

อ่านนโยบายเบื้องหลังของแพลตฟอร์ม

บน Android วงจรชีวิตของบริการ VPN เป็นส่วนหนึ่งของแพลตฟอร์ม และ always-on กับ block-without-VPN เป็นสวิตช์แยกกันโดยมีผลแยกกัน ไคลเอนต์ที่ไม่ใช่ always-on อาจถูกหยุดเมื่อระบบเรียกคืนทรัพยากร และไม่มีการตั้งค่าใดในแอปที่เปลี่ยนสิ่งนั้น iOS ใช้ขีดจำกัดเบื้องหลังของตัวเองกับผู้ให้บริการอุโมงค์ และพฤติกรรมที่บันทึกไว้แตกต่างจากเดมอนเดสก์ท็อปที่เพียงทำงานต่อไป อ่านเอกสารแพลตฟอร์มสำหรับองค์ประกอบที่เกี่ยวข้อง ไม่ใช่คู่มือปรับแต่งแบตเตอรี่ทั่วไป

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

อุปกรณ์ทำอะไรหลังจากตื่น

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

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