keepalive ไม่ใช่การเชื่อมต่อใหม่: เลือกตามความล้มเหลวที่คุณมี

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

เมื่อแมปปิ้งคือปัญหา

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

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

เมื่อความสัมพันธ์หายไป

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

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

สิ่งที่ทั้งสองอย่างไม่ได้พิสูจน์

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

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

การบล็อกทราฟฟิกโดยตรงเป็นการตัดสินใจแยกต่างหาก

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

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

เขียนนโยบาย ไม่ใช่แค่ตัวเลข

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

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