คู่มือเกมแลค › L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
ตารางเซสชันของไฟร์วอลล์เต็ม Firewall session table exhaustion
ID สาเหตุ dc-firewall · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ไฟร์วอลล์บันทึกทุกการเชื่อมต่อที่ปล่อยผ่านไว้ในตารางเซสชันเพื่อติดตาม เมื่อตารางเต็มก็รับการเชื่อมต่อใหม่ไม่ได้
ทำไม จำนวนเซสชันชนขีดจำกัดเพราะการเชื่อมต่อทะลักหรือถูกโจมตี → ผลคือ ไม่มีช่องว่างให้บันทึกการเชื่อมต่อใหม่ จึงถูกปฏิเสธ → บนหน้าจอ คนที่พยายามเข้าใหม่เข้าเกมไม่ได้หรือโหลดไม่จบ และการเชื่อมต่อเดิมบางส่วนก็หลุด
- อาการ
- เข้าเกมไม่ได้/โหลดไม่จบ, หลุด
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- หลังล็อกอิน/หลังปิดปรับปรุง, ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- เซิร์ฟเวอร์: ใช้ระบบคิวล็อกอินคุมการเชื่อมต่อที่ทะลักเข้ามาพร้อมกัน, ใช้การเชื่อมต่อซ้ำเพื่อไม่ให้เปิดการเชื่อมต่อสั้น ๆ ซ้ำไปมา, เก็บกวาดการเชื่อมต่อที่ heartbeat ขาดไปก่อน (เพื่อไม่ให้การเชื่อมต่อที่ตายแล้วกินที่ในตารางเซสชันนาน) ไคลเอนต์: ส่ง heartbeat ทุกช่วงไม่เกินครึ่งหนึ่งของ idle timeout ที่สั้นที่สุด, เชื่อมต่อใหม่อัตโนมัติเมื่อหลุด โดยค่อย ๆ เพิ่มช่วงห่างของการลองใหม่และกระจายแบบสุ่ม (เพื่อไม่ให้แห่กลับมาพร้อมกันอีก)
- งานฝั่งทีมอินฟรา
- เพิ่มขนาดตารางเซสชัน, เก็บกวาดการเชื่อมต่อที่จบเร็วให้ไว (ลดไทม์เอาต์ของเซสชันที่ปิดแล้ว), ถ้าจะลด idle timeout ของเซสชัน ให้แจ้งค่านั้นแก่ทีมพัฒนาเกมเพื่อปรับช่วง heartbeat ให้ตรงกัน, บล็อกการโจมตี, ตั้ง alert อัตราการใช้งานของจำนวนเซสชัน
- บนกราฟ
- ชนเพดานแล้วแบนราบ · จำนวนเซสชันของไฟร์วอลล์, จำนวนการเชื่อมต่อใหม่ที่ล้มเหลว
- จุดที่ต้องดู
- ดูกราฟจำนวนเซสชันพร้อมกันของไฟร์วอลล์คู่กับขีดจำกัดเซสชัน และหาใน log ของอุปกรณ์ว่ามีการทิ้งเพราะสร้างเซสชันไม่ได้หรือไม่ ถ้าเป็นไฟร์วอลล์ Linux ให้เทียบ nf_conntrack_count กับ nf_conntrack_max และดู “nf_conntrack: table full, dropping packet” ใน dmesg ถ้าเป็นอินสแตนซ์ AWS ให้ดู conntrack_allowance_exceeded ใน ethtool -S
- สัญญาณว่าใช่
- ตั้งแต่จำนวนเซสชันแบนราบที่ขีดจำกัด การเชื่อมต่อใหม่ที่ล้มเหลวก็เพิ่มขึ้น พร้อมกับ log ที่สร้างเซสชันไม่สำเร็จหรือตัวนับการทิ้งที่เพิ่มขึ้น
- สัญญาณว่าไม่ใช่
- ถ้าจำนวนเซสชันยังห่างจากขีดจำกัดมากแต่เข้าเกมไม่ได้ น่าจะเป็น “คิวรอเชื่อมต่อ (backlog) ล้น” หรือฝั่งเซิร์ฟเวอร์ล็อกอิน ถ้าหลุดเฉพาะการเชื่อมต่อที่ idle น่าจะเป็น “connection tracking ของ security group บนคลาวด์หมดอายุ”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Netfilter Conntrack Sysfs variables Linux kernel
จำนวนรายการสูงสุดในตาราง connection tracking (nf_conntrack_max), เวลาเก็บการเชื่อมต่อที่กำลังปิด (TIME_WAIT และ FIN_WAIT ค่าเริ่มต้น 120 วินาที), TCP ที่เชื่อมต่อแล้วค่าเริ่มต้น 5 วัน, จำนวนรายการปัจจุบัน (nf_conntrack_count) - Amazon EC2 security group connection tracking AWS
ถ้าเกินจำนวนการเชื่อมต่อที่ติดตามได้ต่ออินสแตนซ์ แพ็กเก็ตของการเชื่อมต่อใหม่จะถูกทิ้ง, การเชื่อมต่อที่ idle อาจทำให้ตารางติดตามเต็ม - Infrastructure layer attacks AWS
การโจมตีอย่าง SYN flood จับทรัพยากรของเซิร์ฟเวอร์ ไฟร์วอลล์ และโหลดบาลานเซอร์ไว้ - net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
เมื่อตาราง connection tracking เต็ม จะบันทึก “nf_conntrack: table full, dropping packet” แล้วทิ้งแพ็กเก็ตของการเชื่อมต่อใหม่ - Monitor network performance for ENA settings on your EC2 instance AWS
conntrack_allowance_exceeded: จำนวนแพ็กเก็ตที่ถูกทิ้งเพราะเกินขีดจำกัด connection tracking ของอินสแตนซ์ ดูได้ด้วย ethtool -S
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (เข้าเกมไม่ได้/โหลดไม่จบ)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง