คู่มือเกมแลค › L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
การอ้อมผ่านระบบป้องกัน DDoS และ false positive DDoS scrubbing latency, false positives
ID สาเหตุ dc-ddos · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
เมื่อเบี่ยงทราฟฟิกไป scrubbing center เพื่อกันการโจมตี เส้นทางจะยาวขึ้น และบางครั้งระบบเข้าใจผิดว่าผู้เล่นปกติเป็นการโจมตีแล้วบล็อก
ทำไม หลังตรวจพบการโจมตี (หรือตลอดเวลา) ทราฟฟิกขาเข้าถูกเบี่ยงไป scrubbing center → ผลคือ เส้นทางยาวขึ้น และแพ็กเก็ตปกติบางส่วนถูกตัดสินว่าเป็นการโจมตี → บนหน้าจอ ปิงสูงขึ้นทั้งหมด, เฉพาะบางพื้นที่หรือบาง ISP ที่เข้าเกมไม่ได้
อาการ อินพุตดีเลย์ , เข้าเกมไม่ได้/โหลดไม่จบ , วาร์ป ปัจจัย ความหน่วง, แพ็กเก็ตหาย
ใครเจอ ทั้งเซิร์ฟเวอร์, บางพื้นที่/บาง ISP
เกิดเมื่อไร ตอนคนแห่มารวมกัน, สุ่มเป็นครั้งคราว
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม สรุปรูปแบบทราฟฟิกของเกม (พอร์ต, ขนาดแพ็กเก็ต, จำนวนแพ็กเก็ตต่อวินาที) แชร์ให้ทีมอินฟรา, รักษาขนาดแพ็กเก็ต UDP ไว้ไม่เกิน 1,200 ไบต์
งานฝั่งทีมอินฟรา ตั้งกฎป้องกันให้ตรงกับรูปแบบทราฟฟิกของเกม, มีจุด scrubbing แยกตามภูมิภาค, ลดขนาดแพ็กเก็ต TCP ในช่วง tunnel (ปรับ MSS), ตรวจ false positive จากอัตราการเชื่อมต่อล้มเหลวแยกตามพื้นที่และ ISP
ตัวเลขที่ควรรู้ ถ้าจุด scrubbing อยู่ในประเทศเดียวกัน จะเพิ่มไม่กี่ ms ถ้าผ่านจุดในประเทศอื่น จะเพิ่ม 30–100 ms ขึ้นไป ปกติเฉพาะขาเข้าที่อ้อม ส่วนการตอบกลับของเซิร์ฟเวอร์ออกไปตรง ๆ ถ้ารับทราฟฟิกที่กรองแล้วกลับมาทาง tunnel ขนาดที่ส่งได้ในครั้งเดียว (MTU) ก็ลดลง และอาจกลายเป็นปัญหาที่เฉพาะแพ็กเก็ตใหญ่หายไป
บนกราฟ จุดที่ต้องดู วางประวัติการเริ่มและหยุดเบี่ยงทราฟฟิก (scrubbing) และ log การบล็อกของอุปกรณ์หรือบริการป้องกัน ไว้บนแกนเวลาเดียวกับกราฟ RTT และอัตราการเชื่อมต่อล้มเหลวแยกตามพื้นที่และ ISP แล้วใช้ mtr หรือ traceroute จากพื้นที่ที่มีปัญหาดูว่ามีจุด scrubbing แทรกอยู่ในเส้นทางหรือไม่ สัญญาณว่าใช่ เมื่อเปิดการเบี่ยงทราฟฟิก RTT ขึ้นไปหนึ่งขั้นและอยู่ระดับนั้น แล้วกลับมาเมื่อปิด หรือ log การบล็อกมี IP ของผู้เล่นปกติ และอัตราการเชื่อมต่อล้มเหลวสูงขึ้นเฉพาะพื้นที่หรือ ISP นั้น สัญญาณว่าไม่ใช่ ถ้า RTT สูงขึ้นในเวลาที่ไม่มีประวัติการเบี่ยงหรือบล็อก น่าจะเป็น “เส้นทางวิ่งอ้อม” หรือ “เส้นทาง BGP เปลี่ยนและ converge ใหม่” ถ้าหายเฉพาะแพ็กเก็ตใหญ่ น่าจะเป็น “MTU ไม่ตรงกัน (เฉพาะแพ็กเก็ตใหญ่ที่หาย)” วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง Maximum transmission unit and maximum segment size Cloudflare ทราฟฟิกขาเข้าถูกกรองแล้วส่งต่อผ่าน GRE tunnel (MTU 1,476), การตอบกลับขาออกส่งออกอินเทอร์เน็ตตรง (DSR), แนะนำให้จำกัด TCP MSS ไว้ไม่เกิน 1,436 ถ้าไม่ปรับ แพ็กเก็ตใหญ่จะถูกทิ้งหรือถูก fragment Azure network round-trip latency statistics Microsoft Azure ระดับความหน่วงไปกลับตามตำแหน่งของจุด scrubbing: โซล–พื้นที่ปูซาน 8 ms, โซล–โตเกียว 30 ms, โซล–สิงคโปร์ 68 ms สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง