WireGuard ล้มเหลวหลังไม่มีการใช้งาน: ทดสอบทิศทางก่อน

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

ทิศทางไหนล้มเหลว

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

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

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

รันทั้งสามคำสั่งก่อนและหลังช่วงเงียบ เพราะแต่ละคำสั่งตอบคำถามคนละส่วน แสตมป์เวลาของ handshake ที่ไม่ขยับบอกว่าทั้งสองฝ่ายหยุดคุยกัน ขณะที่ ปลายทางที่เปลี่ยนไป บอกว่าการแมปย้ายที่แทนที่จะตาย ตัวนับการรับส่งแสดงว่ามีอะไรมาถึงบ้างไหม และนั่นคือความต่างระหว่างการแมปเก่ากับแอปที่เงียบ บันทึกตัวเลขทั้งสองจุด เพราะการเปรียบเทียบคือหลักฐาน

การหลับ วิทยุ และสถานะแอป

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

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

keepalive ทำอะไรจริง ๆ

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

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

รอให้พ้นช่วงเวลาที่เคยล้มเหลว

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

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