เจอ nf_conntrack table full ใน Log? วิธีแก้ไม่ให้เซิร์ฟเวอร์ drop packet
ถ้าเคยเห็นข้อความ nf_conntrack: table full, dropping packet โผล่ใน Log ของเซิร์ฟเวอร์ อย่าเพิ่งตกใจ ปัญหานี้พบได้บ่อยในเซิร์ฟเวอร์ Linux ที่มีทราฟฟิกสูง และแก้ได้ไม่ยาก บทความนี้จะพาทำความเข้าใจสาเหตุและวิธีแก้ไขทุกขั้นตอน
nf_conntrack ทำงานอย่างไร
nf_conntrack เป็นโมดูลของ Netfilter ใน Linux Kernel ที่ติดตามสถานะการเชื่อมต่อเครือข่ายทุกรายการ ทั้ง TCP, UDP และ ICMP ระบบเก็บข้อมูลแต่ละ Connection ไว้ในตาราง conntrack เพื่อให้ Firewall ตัดสินใจได้ว่าแต่ละ Packet เป็นส่วนหนึ่งของ Connection ที่อนุญาตแล้วหรือไม่
ตาราง conntrack มีขนาดจำกัด ค่าเริ่มต้นบน CentOS หรือ RHEL อยู่ที่ประมาณ 65,536 รายการ เพียงพอสำหรับใช้งานทั่วไป แต่สำหรับ VPS ที่รันหลายบริการ หรือเว็บเซิร์ฟเวอร์ที่มีผู้เข้าชมมาก ตารางอาจเต็มได้ง่าย
สาเหตุที่ตาราง conntrack เต็ม
สาเหตุหลักมีหลายอย่าง ทราฟฟิกจำนวนมาก Database Server ที่มี Connection เยอะ Reverse Proxy ที่รับภาระหนัก ค่า Timeout ของ Connection ที่ยาวเกินไปทำให้ Connection เก่าค้างนาน และการโจมตีแบบ DDoS หรือ SYN Flood ก็ทำให้ตารางเต็มได้รวดเร็ว
หากต้องการเพิ่มความปลอดภัยของเซิร์ฟเวอร์ บริการ Security ของ DriteStudio ช่วยลดความเสี่ยงจากการโจมตีเหล่านี้ได้
ตรวจสอบสถานะ conntrack
ก่อนแก้อะไร ตรวจสอบสถานะก่อน
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
ถ้า count ใกล้เคียงหรือเท่ากับ max แสดงว่าตารางเต็มจริง Packet ใหม่จะถูก drop ทันที
ดูรายละเอียด Connection แต่ละรายการได้ด้วย
conntrack -L | head -20
แก้ไขแบบชั่วคราว
เพิ่มค่า nf_conntrack_max ได้ทันที แต่ค่าจะหายเมื่อรีบูต
echo 262144 > /proc/sys/net/netfilter/nf_conntrack_max
echo 65536 > /sys/module/nf_conntrack/parameters/hashsize
แนะนำให้ใช้อัตราส่วน conntrack_max / hashsize = 4
แก้ไขแบบถาวร
แก้ไข /etc/sysctl.conf เพื่อให้ค่าคงอยู่หลังรีบูต
net.netfilter.nf_conntrack_max = 262144
net.nf_conntrack_max = 262144
ใช้คำสั่ง sysctl -p ให้มีผลทันที สำหรับ hashsize สร้างไฟล์
echo "options nf_conntrack hashsize=65536" > /etc/modprobe.d/nf_conntrack.conf
ปรับ Timeout ลด Connection ค้าง
ค่าเริ่มต้น TCP established timeout อยู่ที่ 432,000 วินาที (5 วัน) ซึ่งนานเกินไป ลดลงมาช่วยได้มาก
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
เพิ่มใน /etc/sysctl.conf แล้วรัน sysctl -p
ปิด Connection Tracking สำหรับทราฟฟิกบางส่วน
ถ้าเซิร์ฟเวอร์ไม่ได้ใช้ Stateful Firewall หรือ NAT ปิด Tracking สำหรับทราฟฟิกบางส่วนได้ด้วย NOTRACK
iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -p tcp --dport 443 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp --sport 80 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp --sport 443 -j NOTRACK
ระวังว่า Firewall Rule ที่ใช้ State Matching จะไม่ทำงานกับทราฟฟิกเหล่านี้
ตั้ง Monitoring เฝ้าระวัง
ตั้ง Monitoring เตือนเมื่อ Connection ใกล้ถึงค่าสูงสุด เขียนสคริปต์ร่วมกับ Cron Job ตรวจสอบเปอร์เซ็นต์การใช้งานและส่งแจ้งเตือนเมื่อเกินเกณฑ์
สำหรับ Dedicated Server ของ DriteStudio การตั้ง Monitoring แบบนี้ช่วยดูแลเซิร์ฟเวอร์ได้ง่ายและป้องกันปัญหาก่อนกระทบผู้ใช้
คำถามที่พบบ่อย (FAQ)
ค่า conntrack_max ควรตั้งเท่าไหร่?
ขึ้นอยู่กับ RAM เป็นหลัก แต่ละ Entry ใช้ประมาณ 300 bytes ดังนั้น 262,144 entries ใช้ RAM ประมาณ 75 MB ซึ่งเหมาะกับเซิร์ฟเวอร์ทั่วไป สำหรับเซิร์ฟเวอร์ที่มี RAM เยอะสามารถเพิ่มได้อีก
ปิด conntrack ทั้งหมดได้ไหม?
ได้ แต่ไม่แนะนำ เพราะจะทำให้ Firewall ไม่สามารถใช้ State-based Rules ได้ ควรปิดเฉพาะทราฟฟิกที่ไม่จำเป็นต้องติดตาม
เพิ่ม conntrack_max แล้ว CPU พุ่ง ทำอย่างไร?
ตรวจสอบว่า hashsize เหมาะสมหรือไม่ hashsize ที่เล็กเกินทำให้ค้นหาช้า ใช้อัตราส่วน max/hashsize = 4 และพิจารณาปิด Tracking สำหรับทราฟฟิกที่ไม่จำเป็น
สรุป
ปัญหา nf_conntrack table full เกิดจาก Connection เกินขีดจำกัด แก้ได้โดยเพิ่มค่า max ปรับ hashsize ลด timeout และปิด Tracking ที่ไม่จำเป็น ตั้ง Monitoring เพื่อเฝ้าระวังไม่ให้เกิดซ้ำ สำหรับเซิร์ฟเวอร์ที่รับ Traffic หนัก VPS ของ DriteStudio มี Resource เพียงพอรองรับ ติดต่อทีมงานเพื่อรับคำปรึกษาได้เลย