GitHub เพิ่มช่วง IP สำหรับ Webhook ผู้ใช้ Allowlist แบบคงที่ต้องปรับไฟร์วอลล์

GitHub เพิ่ม IP สำหรับส่ง Webhook ใน Meta API ผู้ใช้ Allowlist แบบคงที่ต้องปรับกฎไฟร์วอลล์

GitHub ประกาศวันที่ 29 ตุลาคม 2026 ว่าเพิ่มช่วง IP สำหรับการส่ง webhook จาก github.com และใส่ช่วงเหล่านี้ไว้ในฟิลด์ hooks ของ Meta API แล้ว การเปลี่ยนแปลงนี้เป็นเรื่องเล็กในระดับ API แต่มีผลโดยตรงกับระบบรับ webhook ที่จำกัดเครือข่ายขาเข้าด้วย allowlist แบบกำหนดค่าไว้ล่วงหน้า หากรายการเดิมไม่มีช่วง IP ใหม่ คำขอ webhook ที่ถูกส่งจากแหล่งใหม่นั้นอาจถูกไฟร์วอลล์ปฏิเสธก่อนถึงแอปพลิเคชัน ทำให้ workflow ที่รอเหตุการณ์จาก GitHub หยุดหรือทำงานไม่ครบ

ช่วง CIDR ใหม่ที่ GitHub ระบุมีสามรายการ ได้แก่ 9.234.98.160/28, 9.234.98.176/28 และ 9.234.106.48/28 ทั้งหมดใช้กับการส่ง webhook บน github.com ในทุกแพ็กเกจ รวมถึง GitHub Enterprise Cloud ผู้ดูแลที่เก็บ allowlist แบบคงที่ควรเพิ่มทั้งสามช่วงควบคู่กับช่วงเดิม ไม่ใช่แทนรายการเดิมด้วยสามช่วงใหม่นี้ เพราะประกาศระบุว่าเป็น additional ranges และ Meta API ยังเป็นแหล่งข้อมูลสำหรับรายการปัจจุบันทั้งหมด

วิธีประเมินผลกระทบเริ่มจากหาว่า endpoint รับ webhook ขององค์กรเปิดรับจากอินเทอร์เน็ตทั่วไป หรือมีกฎ network allowlist อยู่ที่ CDN, WAF, load balancer, firewall หรือ reverse proxy บางระบบมีการกรองหลายชั้น แม้อัปเดตชั้นหน้าสุดแล้ว ชั้นภายในอาจยังปฏิเสธคำขอจากช่วงใหม่ได้ ควรไล่เส้นทางรับคำขอจริงตั้งแต่ขอบเครือข่ายถึงตัวบริการ และตรวจว่ากฎใดอ้างอิงชุด IP ของ GitHub แบบคงที่

หากองค์กรมีงานอัตโนมัติที่ดึง Meta API แล้วอัปเดต allowlist อยู่แล้ว GitHub ระบุว่าไม่ต้องเปลี่ยนการตั้งค่าสำหรับการเพิ่มครั้งนี้ แต่ควรตรวจว่างานดังกล่าวยังรันสำเร็จและนำข้อมูลฟิลด์ hooks ไปใช้จริง การมีสคริปต์อยู่ในคลังโค้ดไม่พอหาก cron job ล้มเหลว การแปลง JSON ผิด หรือกฎปลายทางไม่ถูก deploy ส่วนทีมที่แก้รายการด้วยมือควรตรวจข้อมูลล่าสุดจาก Meta API ก่อนแก้ เพื่อไม่พลาดการเปลี่ยนแปลงอื่นที่เกิดขึ้นระหว่างการอัปเดต

สำหรับการเปลี่ยนกฎ production ควรบันทึก allowlist เดิมไว้ จากนั้นเพิ่ม CIDR ใหม่โดยยังคงช่วงเดิม ทดสอบการอ่านค่ากฎและตรวจ log การรับส่งหลัง deploy หากมีเหตุการณ์ webhook ที่ส่งไม่สำเร็จ ให้ดูทั้งสถานะการส่งใน GitHub และ log ของอุปกรณ์เครือข่ายเพื่อตรวจว่าคำขอถูกปฏิเสธที่จุดใด งานที่ขึ้นกับ webhook เช่น CI, deployment, การซิงก์ issue หรือการแจ้งเตือน อาจไม่แสดงข้อผิดพลาดในแอปพลิเคชันเลยหากแพ็กเก็ตถูกบล็อกก่อนถึง endpoint

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

ข่าวนี้ยังสะท้อนข้อจำกัดของ allowlist แบบคงที่: ช่วง IP ของบริการภายนอกเปลี่ยนได้ และการอัปเดตช้าอาจกลายเป็น incident ที่ดูเหมือน webhook หายโดยไม่มีสาเหตุ ทีมที่ต้องใช้การกรองระดับเครือข่ายควรวางรอบการดึง Meta API พร้อมการตรวจความต่างและขั้นตอนอนุมัติการปรับกฎให้ชัด ขณะเดียวกันต้องมีการเฝ้าดู webhook delivery failures เพื่อพบความผิดปกติเร็ว การปรับครั้งนี้จึงเป็นทั้งงานแก้ CIDR สามรายการและโอกาสทบทวนว่ากระบวนการดูแล allowlist มีเจ้าของและหลักฐานการทำงานครบหรือไม่

ที่มา: GitHub Changelog — Webhook IP ranges added to the Meta API ประกาศวันที่ 29 ตุลาคม 2026; GitHub Docs: Meta API