×
ข้ามไปยังเนื้อหาหลัก

การตั้งค่า Connection Timeout และ Persistent Connection บน Sangfor Athena NGFW

ปรับปรุงเมื่อ

บทความนี้อธิบายวิธีตั้งค่า Connection Timeout (ระยะเวลาที่ไฟร์วอลล์จะปิด Session ที่ไม่มีการใช้งาน) และ Persistent Connection (การกำหนดให้ Connection ไม่ถูกตัดตาม Timeout) บน Sangfor Athena NGFW พร้อมความเสี่ยงที่ต้องระวังเมื่อเปิด Persistent Connection อย่างไม่เหมาะสม ซึ่งอาจทำให้เกิด Session ค้างสะสมจนอุปกรณ์ค้าง/ไม่ตอบสนอง และเมื่อใช้ร่วมกับ NAT อาจทำให้เกิด Port Exhaustion เหมาะสำหรับผู้ดูแลระบบที่ต้องรองรับแอปพลิเคชันที่มี Connection ค้างนาน เช่น VoIP/SIP, ระบบฐานข้อมูล หรือระบบเฉพาะทางที่ต้องคง Connection ไว้ตลอดเวลา

ทำความเข้าใจ Connection Timeout และ Persistent Connection

Sangfor Athena NGFW เป็น Stateful Firewall ที่เก็บสถานะการเชื่อมต่อทั้งหมดไว้ใน Session Table โดยแต่ละ Session จะมีตัวจับเวลา (idle timer) หากไม่มีทราฟฟิกวิ่งผ่านภายในระยะเวลาที่กำหนด Session นั้นจะถูกลบออก (aged out) และแพ็กเก็ตถัดไปของการเชื่อมต่อเดิมจะถูก drop ทำให้แอปพลิเคชันมองเห็นเป็นอาการ "connection reset" หรือค้าง

Persistent Connection คือการสั่งให้ NGFW ยกเว้นการนับ Timeout สำหรับการเชื่อมต่อที่ตรงกับนโยบาย โดยจะคง Session ไว้ตามระยะเวลาที่กำหนด (1–15 วัน) แม้จะไม่มีทราฟฟิกก็ตาม

รูปแบบ การทำงาน เหมาะกับ
Default Timeout ปิด Session อัตโนมัติเมื่อไม่มีทราฟฟิกตามเวลาที่กำหนด ทราฟฟิกทั่วไปเกือบทั้งหมด
Persistent Connection ไม่ปิด Session ตาม Timeout คงไว้ตามเวลาที่ตั้ง (1–15 วัน) แอปที่มี Connection ค้างนานและไม่มีกลไก keepalive/reconnect

เมื่อ ไม่ได้ กำหนด Persistent Connection ไว้ NGFW จะใช้ค่า Default Timeout ด้านล่างในการตัด Session ที่ค้าง (stale/idle)

1. การตั้งค่า Default Connection Timeout (System > Network)

ค่านี้เป็นค่ากลางที่ใช้กับทุก Session ที่ไม่ได้เปิด Persistent Connection ตั้งได้ที่เมนู System > Network (General Settings > Network) ค่าเริ่มต้นของอุปกรณ์เป็นดังนี้

พารามิเตอร์ ค่าเริ่มต้น ความหมาย
TCP Conn Timeout 1800 วินาที (30 นาที) เวลาสูงสุดที่ Session TCP จะคงอยู่เมื่อไม่มีทราฟฟิก
UDP Conn Timeout 180 วินาที (3 นาที) เวลาสูงสุดที่ Session UDP จะคงอยู่เมื่อไม่มีทราฟฟิก
ICMP Timeout 30 วินาที เวลาสูงสุดของ Session ICMP

  1. ไปที่เมนู System > Network (แถบ General Settings > Network)

  2. ปรับค่า TCP / UDP / ICMP Conn Timeout ตามความเหมาะสม

    หน้าตั้งค่า Connection Timeout ที่ System > Network บน Sangfor Athena NGFW

  3. กด Save เพื่อบันทึก

หมายเหตุ: ตารางด้านล่างในหน้าเดียวกัน (FTP, RTSP, SQLNet, TFTP, PPTP, H.323) คือพอร์ตของโปรโตคอลที่ไฟร์วอลล์ใช้ตรวจจับ (ALG) ซึ่งเกี่ยวข้องกับงาน VoIP (H.323/RTSP) และฐานข้อมูล (SQLNet) การตั้ง Timeout ให้สูงเกินไปจะทำให้ Session ค้างนานและกินทรัพยากร ส่วนต่ำเกินไปจะตัด Connection ที่ควรคงอยู่ จึงควรปรับเฉพาะเมื่อจำเป็น

2. การเปิดใช้ Persistent Connection รายนโยบาย (Access Control)

Persistent Connection ตั้งค่าแยกในแต่ละนโยบายของ Access Control ที่เมนู Policies > Access Control > Application Control โดยอยู่ในส่วน Advanced ของนโยบาย

  1. ไปที่ Policies > Access Control > Application Control

  2. กด Add เพื่อสร้างนโยบายใหม่ หรือ Edit นโยบายที่ต้องการ (แนะนำให้สร้างนโยบาย แยกเฉพาะ สำหรับ IP ของระบบที่ต้องการ — ดูหัวข้อความเสี่ยงด้านล่าง)

  3. เลื่อนลงด้านล่างสุดของนโยบาย แล้วคลิก Advanced > Settings

  4. ติ๊ก Enable persistent connection แล้วเลือกระยะเวลาที่ต้องการคง Connection (เลือกได้ 1 / 3 / 7 / 10 / 15 วัน)

    ตัวเลือก Enable persistent connection ในส่วน Advanced ของนโยบาย Access Control

  5. กด Save ทั้งหน้าต่าง Advanced และหน้าต่างนโยบาย

คำอธิบายอย่างเป็นทางการจากตัวอุปกรณ์ (tooltip):
"Only recommended for hosts that send and receive multiple requests and responses. Timeout restriction set on firewall will be invalid for the connection. Enabling this feature is not recommended unless it is necessary, because it may take longer time to release a connection."

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

ความเสี่ยงและข้อควรระวัง (สำคัญมาก)

การเปิด Persistent Connection แบบไม่เหมาะสมเป็นสาเหตุที่พบบ่อยของปัญหาต่อไปนี้:

  • Session ค้างสะสม (stale) จนอุปกรณ์ค้าง: Session ที่ไม่ถูกตัดจะสะสมจน Session Table เต็ม ทำให้ไม่สามารถสร้าง Connection ใหม่ได้ และอุปกรณ์ใช้ CPU/Memory สูงจนตอบสนองช้าหรือค้าง (hang)
  • NAT / PAT Port Exhaustion: เมื่อใช้ร่วมกับ NAT แต่ละ Public IP มีพอร์ตต้นทางได้ประมาณ 64,000 พอร์ต Persistent Connection จะยึดพอร์ตไว้โดยไม่คืน ทำให้พอร์ตหมดและ Connection ใหม่ออกอินเทอร์เน็ตไม่ได้ ทั้งที่ Bandwidth และ CPU ยังปกติ

แนวทางที่ปลอดภัย (ต้องปฏิบัติ):

  • เปิด Persistent Connection ผ่าน นโยบายแยกเฉพาะ (dedicated policy) ที่ระบุ เฉพาะ IP ของ asset ที่จำเป็นเท่านั้น
  • ห้ามเปิดบนนโยบาย default หรือนโยบายที่ครอบคลุมผู้ใช้ทุกคน (all users) เพราะจะทำให้ทุก Connection ไม่ถูกตัดตาม Timeout และนำไปสู่ปัญหาข้างต้นทั้งระบบ
  • ตรวจสอบจำนวน Session ปัจจุบันทั้งก่อนและหลังปรับตั้งค่า เพื่อเฝ้าระวังการสะสมของ Session (ดูวิธีตรวจสอบได้ที่หัวข้อ บทความที่เกี่ยวข้อง)

3. การป้องกันด้วย Connection Control

เพื่อป้องกันไม่ให้ host ใด host หนึ่งสร้าง Connection มากเกินไปจน Session Table หรือพอร์ต NAT หมด สามารถใช้ฟีเจอร์ Connection Control ที่ Policies > Access Control > Connection Control เพื่อจำกัดจำนวน Connection ต่อ IP

  1. ไปที่ Policies > Access Control > Connection Control แล้วกด Add เลือกชนิด (Src IP / Dst IP / Bidirectional IP Connection Control)

  2. กำหนดค่าในส่วน Rule Settings แล้วกด OK

    หน้าตั้งค่า Connection Control จำกัด Concurrent Sessions และ New Connections Per Second ต่อ IP
พารามิเตอร์ ค่าเริ่มต้น ความหมาย
New Connections Per Second — จำกัดอัตราการสร้าง Connection ใหม่ต่อวินาที (ป้องกันการเปิด Connection ถี่ผิดปกติ)
Concurrent Sessions 32768 จำนวน Session พร้อมกันสูงสุดต่อ IP
Action Discard sessions and give alerts การกระทำเมื่อเกินลิมิต: แจ้งเตือน / ตัด Session และแจ้งเตือน / บล็อก IP และแจ้งเตือน
ควรใช้ Connection Control ควบคู่กับ Persistent Connection เสมอ เพื่อจำกัดผลกระทบไม่ให้ host เดียวกินทรัพยากรจนกระทบทั้งระบบ

กรณีพิเศษ: SIP/VoIP และระบบเฉพาะทาง

บางระบบมี Connection ที่ค้างนานหรือเป็นช่วงเงียบระหว่างการใช้งาน จึงอาจต้องปรับ Timeout หรือเปิด Persistent Connection เฉพาะจุด

  • VoIP / SIP (สายหลุดเป็นช่วง ๆ หรือเสียงขาดหาย): มักเกิดจากไฟร์วอลล์ปิด Session/binding ของ UDP ตาม Timeout ระหว่างที่สายยังใช้งานอยู่ แนวทางแก้: เพิ่มค่า UDP Conn Timeout ให้เหมาะสม หรือเปิด Persistent Connection บนนโยบายที่ระบุ เฉพาะ IP ของ VoIP Server / IP-PBX
  • ฐานข้อมูลและ ERP (เช่น Oracle SQLNet): Connection ที่ idle นานอาจถูกตัด แนะนำให้ตั้งค่า keepalive ที่ฝั่งแอปพลิเคชันก่อน (ให้ค่า keepalive สั้นกว่า Timeout ของไฟร์วอลล์) หากปรับที่แอปไม่ได้จึงค่อยเปิด Persistent Connection เฉพาะ IP ของเซิร์ฟเวอร์นั้น
  • ระบบเฉพาะทางที่ไม่มีกลไก reconnect อัตโนมัติ: พิจารณาเปิด Persistent Connection เฉพาะ IP ที่จำเป็นเท่านั้น
ค่าที่เหมาะสมขึ้นกับพฤติกรรมจริงของแต่ละแอปพลิเคชัน แนะนำให้ทดสอบและเฝ้าดูจำนวน Session หลังปรับตั้งค่าเสมอ

สรุปแนวทางปฏิบัติที่แนะนำ

  • คงค่า Default Timeout (System > Network) ให้เหมาะสม ไม่ตั้งสูงเกินความจำเป็น
  • เปิด Persistent Connection เฉพาะเมื่อจำเป็น และผ่านนโยบายแยกที่ระบุ IP เฉพาะเท่านั้น
  • ห้าม เปิด Persistent Connection บนนโยบาย default หรือนโยบายที่ครอบคลุมผู้ใช้ทุกคน
  • ใช้ Connection Control จำกัด Concurrent Sessions / New Connections Per Second เพื่อกันทรัพยากรหมด
  • พิจารณาใช้ application keepalive ก่อนตัดสินใจขยาย Timeout ที่ไฟร์วอลล์
  • เฝ้าดูจำนวน Session ปัจจุบันอย่างสม่ำเสมอ

ข้อคิดเห็น

0 ข้อคิดเห็น

โปรด ลงชื่อเข้าใช้ เพื่อแสดงข้อคิดเห็น