VPN ผ่าน UDP หยุดเมื่อไม่ได้ใช้งาน: ไฟร์วอลล์ลืมโฟลว์ของคุณ

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

อาการสม่ำเสมอพอที่จะวินิจฉัยได้: เกิดขึ้นหลังจากไม่มีการใช้งาน ไม่ใช่ตอนมีโหลด

การหยุดเพราะไม่มีการใช้งานหน้าตาเป็นอย่างไร

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

ทั้งสองอย่างเกี่ยวกับการไม่ใช้งาน และต้องแก้ต่างกัน

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

หาเครื่องที่ลืม

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

อย่าสันนิษฐานว่าค่าเริ่มต้นที่มีเอกสารคือเวลาหมดอายุบนเส้นทางของคุณ มันเป็นค่าเริ่มต้นของอุปกรณ์ตัวเดียว

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

ตรวจไทม์เมอร์บนเส้นทางจริง

บน Linux ไทม์เมอร์ติดตามของ netfilter มองเห็นและปรับได้: sysctl net.netfilter.nf_conntrack_udp_timeout และ net.netfilter.nf_conntrack_udp_timeout_streamตัวที่สองมีผลเมื่อเห็นทราฟฟิกทั้งสองทิศทางแล้ว จึงเป็นเหตุผลว่าอุโมงค์ที่สร้างไว้แล้วจึงอยู่ได้นานกว่าการทดสอบเปล่า ๆ

RFC 4787 กำหนดพฤติกรรมของ UDP NAT และค่าต่ำสุดที่แนะนำ เป็นเอกสารอ้างอิงที่ควรอ้างเมื่อค่าเริ่มต้นของผู้ขายดูสั้นผิดปกติ

Keepalive และการเชื่อมต่อใหม่เป็นเครื่องมือที่ต่างกัน

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

การตรวจสอบที่ถี่เกินไปเพิ่มงานโดยไม่แก้ขอบเขตที่ผิด

ตรวจสอบด้วยคำขอใหม่ ไม่ใช่การโหลดหน้าใหม่

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

ถ้าการหยุดยังคงอยู่ ให้ขยับออกไปหนึ่งฮอปและตรวจตารางสถานะของอุปกรณ์นั้น