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

การตรวจที่หนึ่ง: การหลุดตามช่วงไม่มีการใช้งานหรือไม่?

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

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

การตรวจที่สอง: เป็นทราฟฟิก VPN เท่านั้นหรือไม่?

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

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

การตรวจที่สาม: อ่านสถานะประหยัดพลังงาน

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

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

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

บน Windowspowercfg /q SCHEME_CURRENTจะพิมพ์สคีมาที่ใช้งานอยู่ และกิ่งย่อยของอะแดปเตอร์ไร้สายแสดงว่าสามารถสั่งให้อะแดปเตอร์ประหยัดพลังงานได้หรือไม่ ตัวเลือกเดียวกันยังอยู่ใน Device Manager ที่แท็บจัดการพลังงานของอะแดปเตอร์ บน macOS การประหยัดพลังงาน 802.11 ต่ออินเทอร์เฟซไม่ถูกเปิดเผยให้คุณเห็น จึงให้ดูpmset -gพฤติกรรมการพักและการสแตนด์บายแทน ที่นั่นความล้มเหลวมักกลายเป็นเส้นทางการพักและการตื่น ไม่ใช่พฤติกรรมไม่มีการใช้งานของวิทยุ

การตรวจที่สี่: เปลี่ยนอย่างเดียวแล้วทดสอบซ้ำ

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

การคงการเชื่อมต่อให้มีชีวิตเป็นตัวแปรอิสระอีกตัวและมักถูกสับสนกับการประหยัดพลังงาน ค่าPersistentKeepalive = 25ของ WireGuard ทำให้การแมป NAT อุ่นอยู่;OpenVPNที่ปลายทั้งสองkeepaliveและping-restartใช้งาน การทั้งสองสร้างทราฟฟิกบนอุโมงค์ที่ปกติเงียบ ดังนั้นการคงชีวิตที่ดูเหมือนแก้การหลุดอาจกำลังซ่อนปัญหาวิทยุแทนที่จะแก้ไข ให้ทดสอบแยกกันทีละอย่าง:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

การตรวจที่ห้า: เมื่อวิทยุไม่ผิด

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

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

ก่อนจะทำให้ถาวร

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

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

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

บทความที่เกี่ยวข้อง