กงสุล + iptables = :3

ในปี 2010 บริษัท wargaming มีเซิร์ฟเวอร์ 50 เครื่องและโมเดลเครือข่ายที่เรียบง่าย: แบ็กเอนด์ ฟรอนต์เอนด์ และไฟร์วอลล์ จำนวนเซิร์ฟเวอร์เพิ่มขึ้น โมเดลก็ซับซ้อนมากขึ้น: การจัดเตรียม VLAN แบบแยกด้วย ACL จากนั้น VPN ด้วย VRF, VLAN ด้วย ACL บน L2, VRF ด้วย ACL บน L3 หัวหมุนเหรอ? มันจะสนุกมากขึ้นในภายหลัง

เมื่อมีเซิร์ฟเวอร์ 16 เครื่อง มันเป็นไปไม่ได้เลยที่จะทำงานโดยไม่ขาดตอนกับเซ็กเมนต์ที่ต่างกันจำนวนมาก ดังนั้นเราจึงคิดวิธีแก้ปัญหาอื่นขึ้นมา เราใช้สแต็ก Netfilter เพิ่ม Consul ให้เป็นแหล่งข้อมูล และเราได้รับไฟร์วอลล์แบบกระจายที่รวดเร็ว พวกเขาแทนที่ ACL บนเราเตอร์และใช้เป็นไฟร์วอลล์ภายนอกและภายใน ในการจัดการเครื่องมือแบบไดนามิก เราได้พัฒนาระบบ BEFW ซึ่งถูกใช้ทุกที่ ตั้งแต่การจัดการการเข้าถึงเครือข่ายผลิตภัณฑ์ของผู้ใช้ไปจนถึงการแยกส่วนเครือข่ายออกจากกัน

เขาจะบอกคุณว่ามันทำงานอย่างไร และทำไมคุณจึงควรพิจารณาระบบนี้ให้ละเอียดยิ่งขึ้น อีวาน อการ์คอฟ (ประจำปี) เป็นหัวหน้ากลุ่มรักษาความปลอดภัยโครงสร้างพื้นฐานของแผนกบำรุงรักษาที่ศูนย์พัฒนามินสค์ของบริษัท Ivan เป็นแฟนตัวยงของ SELinux ชอบ Perl และเขียนโค้ด ในฐานะหัวหน้ากลุ่มความปลอดภัยของข้อมูล เขาทำงานเป็นประจำกับบันทึก การสำรองข้อมูล และการวิจัยและพัฒนาเพื่อปกป้อง Wargaming จากแฮกเกอร์ และรับประกันการทำงานของเซิร์ฟเวอร์เกมทั้งหมดในบริษัท

ข้อมูลทางประวัติศาสตร์

ก่อนที่ฉันจะบอกคุณว่าเราทำมันได้อย่างไร ฉันจะบอกคุณว่าเรามาถึงสิ่งนี้ได้อย่างไรตั้งแต่แรก และเหตุใดจึงจำเป็น หากต้องการทำสิ่งนี้ ย้อนกลับไป 9 ปี: 2010 World of Tanks เพิ่งปรากฏตัว Wargaming มีเซิร์ฟเวอร์ประมาณ 50 เครื่อง

แผนภูมิการเติบโตของเซิร์ฟเวอร์ของบริษัท

เรามีโมเดลเครือข่าย ในเวลานั้นมันก็เหมาะสมที่สุด

รูปแบบเครือข่ายในปี 2010

มีคนร้ายที่ส่วนหน้าต้องการทำลายเรา แต่มันมีไฟร์วอลล์ ไม่มีไฟร์วอลล์บนแบ็กเอนด์ แต่มีเซิร์ฟเวอร์ 50 เครื่อง เรารู้จักพวกเขาทั้งหมด ทุกอย่างทำงานได้ดี

ในระยะเวลา 4 ปี ฟลีตเซิร์ฟเวอร์เติบโตขึ้น 100 เท่าเป็น 5000 เครือข่ายแรกๆ ปรากฏขึ้น - อยู่ในสถานะชั่วคราว: ไม่สามารถเข้าสู่การใช้งานจริงได้ และมักมีสิ่งต่างๆ ทำงานอยู่ที่นั่นซึ่งอาจเป็นอันตรายได้

รูปแบบเครือข่ายในปี 2014

ด้วยความเฉื่อย เราใช้ฮาร์ดแวร์ชิ้นเดียวกัน และงานทั้งหมดดำเนินการบน VLAN ที่แยกได้: ACL ถูกเขียนไปยัง VLAN ซึ่งอนุญาตหรือปฏิเสธการเชื่อมต่อบางประเภท

ในปี 2016 จำนวนเซิร์ฟเวอร์สูงถึง 8000 เซิร์ฟเวอร์ Wargaming ดูดซับสตูดิโออื่นและมีเครือข่ายพันธมิตรเพิ่มเติมปรากฏขึ้น ดูเหมือนจะเป็นของเรา แต่ก็ไม่ทั้งหมด: VLAN มักจะใช้ไม่ได้กับพันธมิตร คุณต้องใช้ VPN กับ VRF การแยกจะซับซ้อนมากขึ้น ส่วนผสมฉนวน ACL เพิ่มขึ้น

รูปแบบเครือข่ายในปี 2016

ภายในต้นปี 2018 จำนวนเครื่องจักรเพิ่มขึ้นเป็น 16 เครื่อง มี 000 ส่วน และเราไม่ได้นับส่วนที่เหลือ รวมถึงส่วนปิดที่เก็บข้อมูลทางการเงินด้วย เครือข่ายคอนเทนเนอร์ (Kubernetes), DevOps, เครือข่ายคลาวด์ที่เชื่อมต่อผ่าน VPN เช่นจาก IVS ปรากฏขึ้น มีกฎมากมาย - มันเจ็บปวด

รูปแบบเครือข่ายและวิธีการแยกในปี 2018

สำหรับการแยกเราใช้: VLAN พร้อม ACL บน L2, VRF พร้อม ACL บน L3, VPN และอีกมากมาย มากเกินไป.

ปัญหา

ทุกคนอาศัยอยู่กับ ACL และ VLAN เกิดอะไรขึ้น? ฮาโรลด์จะตอบคำถามนี้โดยซ่อนความเจ็บปวดไว้

มีปัญหามากมาย แต่มีห้าปัญหาใหญ่

• การเพิ่มราคาทางเรขาคณิตสำหรับกฎใหม่. กฎใหม่แต่ละข้อใช้เวลาในการเพิ่มนานกว่ากฎก่อนหน้า เนื่องจากจำเป็นต้องดูก่อนว่ามีกฎดังกล่าวอยู่แล้วหรือไม่
• ไม่มีไฟร์วอลล์ภายในเซ็กเมนต์. ส่วนต่างๆ ถูกแยกออกจากกัน และมีทรัพยากรภายในไม่เพียงพอ
• กฎเกณฑ์ถูกใช้มาเป็นเวลานาน ผู้ปฏิบัติงานสามารถเขียนกฎท้องถิ่นฉบับหนึ่งด้วยมือได้ภายในหนึ่งชั่วโมง ระดับโลกใช้เวลาหลายวัน
• ความยากลำบากกับกฎการตรวจสอบ. แม่นยำยิ่งขึ้นมันเป็นไปไม่ได้ กฎข้อแรกเขียนย้อนกลับไปในปี 2010 และผู้เขียนส่วนใหญ่ไม่ได้ทำงานให้กับบริษัทอีกต่อไป
• การควบคุมโครงสร้างพื้นฐานระดับต่ำ. นี่คือปัญหาหลัก - เราไม่รู้ดีนักว่าเกิดอะไรขึ้นในประเทศของเรา

นี่คือสิ่งที่วิศวกรเครือข่ายดูเหมือนในปี 2018 เมื่อเขาได้ยินว่า: “ต้องการ ACL มากกว่านี้”

โซลูชั่น

เมื่อต้นปี 2018 มีการตัดสินใจที่จะทำอะไรบางอย่างเกี่ยวกับเรื่องนี้

ราคาของการบูรณาการมีการเติบโตอย่างต่อเนื่อง จุดเริ่มต้นคือศูนย์ข้อมูลขนาดใหญ่หยุดรองรับ VLAN และ ACL แบบแยกเนื่องจากอุปกรณ์มีหน่วยความจำไม่เพียงพอ

วิธีแก้ไข: เราได้ลบปัจจัยด้านมนุษย์ออกและทำให้การจัดเตรียมการเข้าถึงสูงสุดเป็นแบบอัตโนมัติ

กฎใหม่ใช้เวลานานในการบังคับใช้ วิธีแก้ไข: เร่งการใช้กฎ ให้กระจายและขนานกัน สิ่งนี้ต้องการระบบแบบกระจายเพื่อให้กฎถูกส่งด้วยตนเอง โดยไม่ต้องใช้ rsync หรือ SFTP ไปยังระบบนับพันระบบ

ไม่มีไฟร์วอลล์ภายในเซ็กเมนต์ ไฟร์วอลล์ภายในเซกเมนต์เริ่มมาหาเราเมื่อมีบริการต่าง ๆ ปรากฏขึ้นภายในเครือข่ายเดียวกัน วิธีแก้ไข: ใช้ไฟร์วอลล์ที่ระดับโฮสต์ - ไฟร์วอลล์แบบโฮสต์ เกือบทุกที่ที่เรามี Linux และทุกที่ที่เรามี iptables นี่ไม่ใช่ปัญหา

ความยากลำบากกับกฎการตรวจสอบ วิธีแก้ไข: เก็บกฎทั้งหมดไว้ในที่เดียวเพื่อตรวจสอบและจัดการ เพื่อให้เราตรวจสอบได้ทุกอย่าง

การควบคุมโครงสร้างพื้นฐานในระดับต่ำ วิธีแก้ไข: จัดทำรายการบริการทั้งหมดและเข้าถึงระหว่างบริการเหล่านั้น

นี่เป็นกระบวนการบริหารจัดการมากกว่ากระบวนการทางเทคนิค บางครั้งเรามีสินค้าออกใหม่ 200-300 รายการต่อสัปดาห์ โดยเฉพาะในช่วงโปรโมชั่นและวันหยุด ยิ่งไปกว่านั้น นี่เป็นเพียงทีม DevOps ของเราเพียงทีมเดียวเท่านั้น ด้วยการเปิดตัวจำนวนมาก จึงเป็นไปไม่ได้ที่จะเห็นว่าพอร์ต, IP และการรวมระบบใดบ้างที่จำเป็น ดังนั้นเราจึงต้องการผู้จัดการฝ่ายบริการที่ได้รับการฝึกอบรมมาเป็นพิเศษ โดยถามทีมงานว่า “มีอะไรอยู่แล้ว และทำไมคุณถึงหยิบยกเรื่องนี้ขึ้นมา”

หลังจากทุกสิ่งที่เราเปิดตัว วิศวกรเครือข่ายในปี 2019 ก็เริ่มมีหน้าตาเช่นนี้

กงสุล

เราตัดสินใจว่าเราจะนำทุกสิ่งที่เราพบด้วยความช่วยเหลือจากผู้จัดการฝ่ายบริการไปที่กงสุล และจากนั้นเราจะเขียนกฎ iptables

เราตัดสินใจทำเช่นนี้ได้อย่างไร?

• เราจะรวบรวมบริการ เครือข่าย และผู้ใช้ทั้งหมด
• มาสร้างกฎ iptables ตามพวกมันกันดีกว่า
• เราควบคุมอัตโนมัติ
• ....
• กำไร.

กงสุลไม่ใช่ API ระยะไกล สามารถทำงานบนทุกโหนดและเขียนไปยัง iptables สิ่งที่เหลืออยู่ก็คือการสร้างระบบควบคุมอัตโนมัติที่จะกำจัดสิ่งที่ไม่จำเป็นออกไป และปัญหาส่วนใหญ่จะได้รับการแก้ไข! เราจะทำงานที่เหลือในขณะที่เราไป

ทำไมต้องกงสุล?

ได้พิสูจน์ตัวเองมาดีแล้ว ในปี 2014-15 เราใช้มันเป็นแบ็กเอนด์สำหรับห้องนิรภัยซึ่งเราจัดเก็บรหัสผ่าน

ไม่สูญเสียข้อมูล. ในระหว่างการใช้งาน กงสุลไม่สูญเสียข้อมูลในระหว่างเกิดอุบัติเหตุเพียงครั้งเดียว นี่เป็นข้อดีอย่างมากสำหรับระบบการจัดการไฟร์วอลล์

การเชื่อมต่อ P2P เร่งการแพร่กระจายของการเปลี่ยนแปลง. ด้วย P2P การเปลี่ยนแปลงทั้งหมดจะเกิดขึ้นอย่างรวดเร็ว ไม่จำเป็นต้องรอนานหลายชั่วโมง

REST API ที่สะดวกสบาย นอกจากนี้เรายังพิจารณา Apache ZooKeeper แต่ไม่มี REST API ดังนั้นคุณจะต้องติดตั้งไม้ค้ำยัน

ทำงานเป็นทั้ง Key Vault (KV) และ Directory (Service Discovery). คุณสามารถจัดเก็บบริการ แค็ตตาล็อก และศูนย์ข้อมูลได้ในคราวเดียว สิ่งนี้สะดวกไม่เพียงแต่สำหรับเราเท่านั้น แต่ยังสำหรับทีมใกล้เคียงด้วย เพราะเมื่อสร้างบริการระดับโลก เราคิดการใหญ่

เขียนใน Go ซึ่งเป็นส่วนหนึ่งของกลุ่ม Wargaming เราชอบภาษานี้ เรามีนักพัฒนา Go มากมาย

ระบบ ACL อันทรงพลัง ในกงสุล คุณสามารถใช้ ACL เพื่อควบคุมว่าใครจะเขียนอะไร เรารับประกันว่ากฎไฟร์วอลล์จะไม่ทับซ้อนกับสิ่งอื่นใดและเราจะไม่มีปัญหากับเรื่องนี้

แต่กงสุลก็มีข้อเสียเช่นกัน

• ไม่ปรับขนาดภายในศูนย์ข้อมูล เว้นแต่คุณจะมีเวอร์ชันธุรกิจ สามารถปรับขนาดได้โดยสหพันธรัฐเท่านั้น
• ขึ้นอยู่กับคุณภาพของเครือข่ายและโหลดเซิร์ฟเวอร์เป็นอย่างมาก กงสุลจะทำงานไม่ถูกต้องในฐานะเซิร์ฟเวอร์บนเซิร์ฟเวอร์ที่ไม่ว่าง หากมีความล่าช้าในเครือข่าย เช่น ความเร็วไม่สม่ำเสมอ นี่เป็นเพราะการเชื่อมต่อ P2P และอัปเดตโมเดลการจัดจำหน่าย
• ความยากลำบากในการตรวจสอบความพร้อม. ในตำแหน่งกงสุลเขาพูดได้ว่าทุกอย่างเรียบร้อยดี แต่เขาเสียชีวิตไปนานแล้ว

เราแก้ไขปัญหาเหล่านี้ส่วนใหญ่ในขณะที่ใช้กงสุล ซึ่งเป็นเหตุผลที่เราเลือกมัน บริษัทมีแผนสำหรับแบ็กเอนด์ทางเลือก แต่เราได้เรียนรู้ที่จะจัดการกับปัญหาและขณะนี้อาศัยอยู่กับกงสุล

กงสุลทำงานอย่างไร

เราจะติดตั้งเซิร์ฟเวอร์สามถึงห้าเครื่องในศูนย์ข้อมูลแบบมีเงื่อนไข เซิร์ฟเวอร์หนึ่งหรือสองเครื่องจะไม่ทำงาน: พวกเขาจะไม่สามารถจัดระเบียบองค์ประชุมและตัดสินใจว่าใครถูกและใครผิดเมื่อข้อมูลไม่ตรงกัน มากกว่าห้าอันไม่สมเหตุสมผล ประสิทธิภาพการทำงานจะลดลง

ไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ในลำดับใดก็ได้: เอเจนต์เดียวกัน แต่มีแฟล็กเท่านั้น server = false.

หลังจากนี้ ไคลเอนต์จะได้รับรายการการเชื่อมต่อ P2P และสร้างการเชื่อมต่อระหว่างกัน

ในระดับโลก เราเชื่อมต่อศูนย์ข้อมูลหลายแห่ง พวกเขายังเชื่อมต่อ P2P และสื่อสารด้วย

เมื่อเราต้องการดึงข้อมูลจากศูนย์ข้อมูลอื่น คำขอจะไปจากเซิร์ฟเวอร์หนึ่งไปอีกเซิร์ฟเวอร์หนึ่ง โครงการนี้เรียกว่า โปรโตคอลเซิร์ฟเวอร์. โปรโตคอล Serf เช่นเดียวกับกงสุลได้รับการพัฒนาโดย HashiCorp

ข้อเท็จจริงสำคัญบางประการเกี่ยวกับกงสุล

กงสุลมีเอกสารอธิบายวิธีการทำงาน ฉันจะให้เฉพาะข้อเท็จจริงที่เลือกไว้ซึ่งควรค่าแก่การรู้

เซิร์ฟเวอร์กงสุลเลือกหลักจากผู้ลงคะแนน. กงสุลเลือกเซิร์ฟเวอร์หลักจากรายการเซิร์ฟเวอร์สำหรับศูนย์ข้อมูลแต่ละแห่ง และคำขอทั้งหมดจะส่งไปที่ศูนย์ข้อมูลนั้นเท่านั้น โดยไม่คำนึงถึงจำนวนเซิร์ฟเวอร์ การแช่แข็งของอาจารย์ไม่ได้นำไปสู่การเลือกตั้งใหม่ หากไม่ได้เลือกต้นแบบ จะไม่มีใครให้บริการตามคำขอ

คุณต้องการปรับขนาดแนวนอนหรือไม่? ขออภัยไม่มี

คำขอไปยังศูนย์ข้อมูลอื่นจะไปจากต้นแบบหนึ่งไปยังอีกต้นแบบ โดยไม่คำนึงถึงเซิร์ฟเวอร์ที่มา ต้นแบบที่เลือกจะได้รับ 100% ของโหลด ยกเว้นโหลดในคำขอส่งต่อ เซิร์ฟเวอร์ทั้งหมดในศูนย์ข้อมูลมีสำเนาข้อมูลที่ทันสมัย ​​แต่มีเพียงเซิร์ฟเวอร์เดียวเท่านั้นที่ตอบสนอง

วิธีเดียวที่จะปรับขนาดได้คือเปิดใช้งานโหมดเก่าบนไคลเอนต์

ในโหมดเก่า คุณสามารถตอบกลับได้โดยไม่ต้องครบองค์ประชุม นี่คือโหมดที่เราละทิ้งความสอดคล้องของข้อมูล แต่อ่านเร็วกว่าปกติเล็กน้อย และเซิร์ฟเวอร์ใดๆ ก็ตามจะตอบสนอง โดยปกติแล้วจะบันทึกผ่านอาจารย์เท่านั้น

กงสุลไม่คัดลอกข้อมูลระหว่างศูนย์ข้อมูล. เมื่อรวมสหพันธ์แล้ว แต่ละเซิร์ฟเวอร์จะมีเพียงข้อมูลของตัวเองเท่านั้น สำหรับคนอื่นเขามักจะหันไปหาคนอื่นเสมอ

ไม่รับประกันความเป็นอะตอมมิกของการดำเนินการนอกธุรกรรม. จำไว้ว่าคุณไม่ใช่คนเดียวที่สามารถเปลี่ยนแปลงสิ่งต่างๆ ได้ หากคุณต้องการให้แตกต่างออกไป ให้ทำธุรกรรมด้วยการล็อค

การบล็อคไม่รับประกันการล็อค. คำขอไปจากต้นแบบหนึ่งไปยังอีกต้นแบบ ไม่ใช่โดยตรง ดังนั้นจึงไม่มีการรับประกันว่าการบล็อกจะทำงานเมื่อคุณบล็อก เช่น ในศูนย์ข้อมูลอื่น

ACL ยังไม่รับประกันการเข้าถึง (ในหลายกรณี). ACL อาจไม่ทำงานเนื่องจากถูกจัดเก็บไว้ในศูนย์ข้อมูลสหพันธรัฐแห่งเดียว - ในศูนย์ข้อมูล ACL (Primary DC) หาก DC ไม่ตอบคุณ ACL จะไม่ทำงาน

ต้นแบบที่ถูกแช่แข็งหนึ่งตัวจะทำให้ทั้งสหพันธรัฐค้าง. ตัวอย่างเช่น มีศูนย์ข้อมูล 10 แห่งในสหพันธรัฐ และอีกแห่งมีเครือข่ายที่ไม่ดี และศูนย์หลักหนึ่งแห่งล้มเหลว ทุกคนที่สื่อสารกับเขาจะติดอยู่ในแวดวง: มีคำขอ, ไม่มีคำตอบ, เธรดค้าง ไม่มีทางรู้ได้เลยว่าสิ่งนี้จะเกิดขึ้นเมื่อใด ภายในหนึ่งหรือสองชั่วโมง สหพันธ์ทั้งหมดก็จะล่มสลาย คุณไม่สามารถทำอะไรกับมันได้

สถานะ องค์ประชุม และการเลือกตั้งจะจัดการโดยแยกหัวข้อย่อย การเลือกตั้งใหม่จะไม่เกิดขึ้น สถานะจะไม่แสดงอะไรเลย คุณคิดว่าคุณมีกงสุลอยู่และถามและไม่มีอะไรเกิดขึ้น - ไม่มีคำตอบ ในขณะเดียวกันสถานะก็แสดงว่าทุกอย่างเรียบร้อยดี

เราประสบปัญหานี้และต้องสร้างศูนย์ข้อมูลบางส่วนขึ้นใหม่เพื่อหลีกเลี่ยงปัญหานี้

Consul Enterprise เวอร์ชันธุรกิจไม่มีข้อเสียข้างต้น. มีฟังก์ชันที่มีประโยชน์มากมาย: การเลือกผู้มีสิทธิเลือกตั้ง การแจกจ่าย การปรับขนาด มีเพียง "แต่" เท่านั้น - ระบบลิขสิทธิ์สำหรับระบบแบบกระจายมีราคาแพงมาก

ชีวิตแฮ็ก: rm -rf /var/lib/consul - เป็นยารักษาทุกโรคของสาร หากมีบางอย่างใช้ไม่ได้ผลสำหรับคุณ เพียงลบข้อมูลของคุณและดาวน์โหลดข้อมูลจากสำเนา เป็นไปได้มากว่ากงสุลจะทำงาน

บีอีเอฟดับบลิว

ตอนนี้เรามาพูดถึงสิ่งที่เราได้เพิ่มให้กับกงสุลกันดีกว่า

บีอีเอฟดับบลิว เป็นตัวย่อสำหรับ Bแอ๊EndFความเดือดดาลWทั้งหมด. ฉันต้องตั้งชื่อผลิตภัณฑ์ด้วยวิธีใดวิธีหนึ่งเมื่อฉันสร้างพื้นที่เก็บข้อมูลเพื่อใส่การทดสอบครั้งแรกลงไป ชื่อนี้ยังคงอยู่

เทมเพลตกฎ

กฎถูกเขียนด้วยไวยากรณ์ iptables

• -N BEFW
• -P อินพุตลดลง
• -A INPUT -m state—สถานะที่เกี่ยวข้อง ก่อตั้งแล้ว -j ยอมรับ
• -A อินพุต -i lo -j ยอมรับ
• -A อินพุต -j BEFW

ทุกอย่างจะเข้าสู่ห่วงโซ่ BEFW ยกเว้น ESTABLISHED, RELATED และโลคัลโฮสต์ เทมเพลตสามารถเป็นอะไรก็ได้ นี่เป็นเพียงตัวอย่างเท่านั้น

BEFW มีประโยชน์อย่างไร?

บริการ

เรามีบริการซึ่งมีพอร์ตและโหนดที่จะรันอยู่เสมอ จากโหนดของเรา เราสามารถสอบถามตัวแทนในพื้นที่และพบว่าเรามีบริการบางอย่าง คุณยังสามารถใส่แท็ก

บริการใดๆ ที่ทำงานและลงทะเบียนกับกงสุลจะกลายเป็นกฎ iptables เรามี SSH - เปิดพอร์ต 22 สคริปต์ Bash นั้นเรียบง่าย: curl และ iptables ไม่ต้องการสิ่งอื่นใด

ลูกค้า

จะเปิดการเข้าถึงไม่ใช่ทุกคนได้อย่างไร แต่เป็นแบบเลือกสรร? เพิ่มรายการ IP ไปยังพื้นที่จัดเก็บ KV ตามชื่อบริการ

ตัวอย่างเช่น เราต้องการให้ทุกคนในเครือข่ายที่สิบสามารถเข้าถึงบริการ SSH_TCP_22 ได้ เพิ่มฟิลด์ TTL เล็ก ๆ หนึ่งฟิลด์? และตอนนี้เรามีใบอนุญาตชั่วคราวเช่นหนึ่งวัน

การเข้าถึง

เราเชื่อมโยงบริการและลูกค้า: เรามีบริการ พื้นที่เก็บข้อมูล KV พร้อมสำหรับแต่ละรายการ ตอนนี้เราให้การเข้าถึงไม่ใช่ทุกคน แต่เป็นแบบคัดเลือก

กลุ่ม

ถ้าเราเขียน IP นับพันเพื่อเข้าถึงทุกครั้ง เราก็จะเหนื่อย เรามาจัดกลุ่มกัน - ชุดย่อยแยกต่างหากใน KV เรียกมันว่านามแฝง (หรือกลุ่ม) และจัดเก็บกลุ่มไว้ที่นั่นตามหลักการเดียวกัน

มาเชื่อมต่อกัน: ตอนนี้เราสามารถเปิด SSH ได้ไม่เฉพาะสำหรับ P2P แต่สำหรับทั้งกลุ่มหรือหลายกลุ่ม ในทำนองเดียวกัน มี TTL - คุณสามารถเพิ่มลงในกลุ่มและลบออกจากกลุ่มได้ชั่วคราว

บูรณาการ

ปัญหาของเราคือปัจจัยมนุษย์และระบบอัตโนมัติ จนถึงตอนนี้เราได้แก้ไขมันด้วยวิธีนี้

เราทำงานร่วมกับ Puppet และถ่ายโอนทุกสิ่งที่เกี่ยวข้องกับระบบ (รหัสแอปพลิเคชัน) ให้กับพวกเขา Puppetdb (PostgreSQL ปกติ) จะจัดเก็บรายการบริการที่ทำงานอยู่ที่นั่น โดยสามารถดูได้ตามประเภททรัพยากร ที่นั่นคุณจะพบว่าใครสมัครที่ไหน นอกจากนี้เรายังมีระบบคำขอดึงและรวมสำหรับสิ่งนี้ด้วย

เราเขียน befw-sync ซึ่งเป็นโซลูชันง่ายๆ ที่ช่วยถ่ายโอนข้อมูล ขั้นแรก คุกกี้การซิงค์จะถูกเข้าถึงโดย puppetdb มีการกำหนดค่า HTTP API ที่นั่น: เราขอบริการที่เรามี สิ่งที่ต้องทำ จากนั้นจึงยื่นคำร้องต่อกงสุล

มีการบูรณาการหรือไม่? ใช่: พวกเขาเขียนกฎและอนุญาตให้ Pull Requests ได้รับการยอมรับ คุณต้องการพอร์ตที่แน่นอนหรือเพิ่มโฮสต์ให้กับกลุ่มบางกลุ่มหรือไม่? ดึงคำขอ ตรวจสอบ - ไม่ต้องค้นหา ACL อื่นอีก 200 รายการแล้วลองดำเนินการบางอย่างเกี่ยวกับเรื่องนี้

การเพิ่มประสิทธิภาพ

การ Ping localhost ด้วยห่วงโซ่กฎว่างใช้เวลา 0,075 มิลลิวินาที

มาเพิ่มที่อยู่ iptables 10 รายการให้กับเครือข่ายนี้ เป็นผลให้การ ping เพิ่มขึ้น 000 เท่า: iptables เป็นแบบเส้นตรงโดยสมบูรณ์ การประมวลผลแต่ละที่อยู่จะใช้เวลาระยะหนึ่ง

สำหรับไฟร์วอลล์ที่เราย้าย ACL นับพัน เรามีกฎมากมาย และสิ่งนี้ทำให้เกิดเวลาแฝง สิ่งนี้ไม่ดีสำหรับโปรโตคอลการเล่นเกม

แต่ถ้าเราใส่ 10 ที่อยู่ใน ipset ค่า ping ก็จะลดลงด้วย

ประเด็นก็คือ “O” (ความซับซ้อนของอัลกอริทึม) สำหรับ ipset จะเท่ากับ 1 เสมอไม่ว่าจะมีกฎกี่ข้อก็ตาม จริงอยู่มีข้อ จำกัด - ไม่สามารถมีกฎได้มากกว่า 65535 กฎ สำหรับตอนนี้เราอยู่กับสิ่งนี้: คุณสามารถรวมมัน, ขยายมัน, สร้างสอง ipsets ในหนึ่งเดียว

การเก็บรักษา

ความต่อเนื่องเชิงตรรกะของกระบวนการวนซ้ำคือการจัดเก็บข้อมูลเกี่ยวกับไคลเอนต์สำหรับบริการใน ipset

ตอนนี้เรามี SSH เดียวกันและเราไม่ได้เขียน 100 IP ในคราวเดียว แต่ตั้งชื่อของ ipset ที่เราต้องสื่อสารด้วยและกฎต่อไปนี้ DROP. เปลี่ยนเป็นกฎข้อเดียวได้ “ใครไม่อยู่ DROP” แต่จะชัดเจนกว่า

ตอนนี้เรามีกฎและชุด ภารกิจหลักคือสร้างชุดก่อนที่จะเขียนกฎ เพราะไม่เช่นนั้น iptables จะไม่เขียนกฎ

โครงการทั่วไป

ในรูปแบบแผนภาพ ทุกสิ่งที่ฉันพูดจะเป็นเช่นนี้

เราให้คำมั่นสัญญากับ Puppet ทุกอย่างจะถูกส่งไปยังโฮสต์ บริการที่นี่ ipset ที่นั่น และใครก็ตามที่ไม่ได้ลงทะเบียนจะไม่ได้รับอนุญาต

อนุญาตและปฏิเสธ

เพื่อที่จะกอบกู้โลกอย่างรวดเร็วหรือปิดการใช้งานใครบางคนอย่างรวดเร็ว ที่จุดเริ่มต้นของเครือข่ายทั้งหมด เราได้สร้าง ipset สองอัน: rules_allow и rules_deny. มันทำงานอย่างไร?

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

เราส่งให้กงสุล รอ 2,5 วินาที ก็เป็นอันเสร็จ เนื่องจากกงสุลกระจายสินค้าอย่างรวดเร็วผ่าน P2P จึงใช้งานได้ทุกที่และทุกส่วนของโลก

เมื่อฉันหยุด WOT โดยสิ้นเชิงเนื่องจากข้อผิดพลาดกับไฟร์วอลล์ rules_allow - นี่คือการประกันของเราต่อกรณีดังกล่าว หากเราทำผิดพลาดที่ไหนสักแห่งกับไฟร์วอลล์ มีบางอย่างถูกบล็อกที่ไหนสักแห่ง เราสามารถส่งเงื่อนไขได้ตลอดเวลา 0.0/0เพื่อหยิบทุกอย่างขึ้นมาอย่างรวดเร็ว ต่อมาเราจะแก้ไขทุกอย่างด้วยมือ

ชุดอื่นๆ

คุณสามารถเพิ่มชุดอื่นในพื้นที่ได้ $IPSETS$.

เพื่ออะไร? บางครั้งมีคนต้องการ ipset เพื่อจำลองการปิดระบบบางส่วนของคลัสเตอร์ ใครสามารถนำชุดไหนมาตั้งชื่อได้ แล้วจะไปรับจากกงสุล ในเวลาเดียวกัน ชุดสามารถเข้าร่วมในกฎ iptables หรือทำหน้าที่เป็นทีมก็ได้ NOOP: ความสม่ำเสมอจะถูกรักษาโดย daemon

สมาชิก

ก่อนหน้านี้เป็นเช่นนี้: ผู้ใช้เชื่อมต่อกับเครือข่ายและรับพารามิเตอร์ผ่านโดเมน ก่อนการกำเนิดของไฟร์วอลล์รุ่นใหม่ Cisco ไม่รู้ว่าจะเข้าใจได้อย่างไรว่าผู้ใช้อยู่ที่ไหนและ IP อยู่ที่ไหน ดังนั้น การเข้าถึงจึงได้รับผ่านชื่อโฮสต์ของเครื่องเท่านั้น

เราทำอะไร? เราติดขัดในขณะที่เราได้รับที่อยู่ โดยปกติจะเป็น dot1x, Wi-Fi หรือ VPN - ทุกอย่างต้องผ่าน RADIUS สำหรับผู้ใช้แต่ละคน เราจะสร้างกลุ่มตามชื่อผู้ใช้และวาง IP ในกลุ่มนั้นด้วย TTL ที่เท่ากับ dhcp.lease - ทันทีที่หมดอายุ กฎจะหายไป

ตอนนี้เราสามารถเปิดการเข้าถึงบริการได้เช่นเดียวกับกลุ่มอื่นๆ โดยใช้ชื่อผู้ใช้ เราได้ขจัดความเจ็บปวดจากชื่อโฮสต์เมื่อมีการเปลี่ยน และเราแบ่งเบาภาระของวิศวกรเครือข่ายเพราะพวกเขาไม่ต้องการ Cisco อีกต่อไป ตอนนี้วิศวกรเองก็ลงทะเบียนการเข้าถึงบนเซิร์ฟเวอร์ของตนแล้ว

ฉนวนกันความร้อน

ในเวลาเดียวกันเราก็เริ่มรื้อฉนวนออก ผู้จัดการฝ่ายบริการรับรายการสินค้าและเราวิเคราะห์เครือข่ายทั้งหมดของเรา มาแบ่งพวกมันออกเป็นกลุ่มเดียวกันและบนเซิร์ฟเวอร์ที่จำเป็นก็มีการเพิ่มกลุ่มเพื่อปฏิเสธ ตอนนี้การแยกการแสดงละครแบบเดียวกันจะจบลงที่ Rules_deny ของการผลิต แต่ไม่ใช่ในตัวการผลิตเอง

โครงการนี้ทำงานได้อย่างรวดเร็วและง่ายดาย: เราลบ ACL ทั้งหมดออกจากเซิร์ฟเวอร์ ยกเลิกการโหลดฮาร์ดแวร์ และลดจำนวน VLAN ที่แยกออกมา

การควบคุมความซื่อสัตย์

ก่อนหน้านี้ เรามีทริกเกอร์พิเศษที่รายงานเมื่อมีคนเปลี่ยนกฎไฟร์วอลล์ด้วยตนเอง ฉันกำลังเขียนคำสั่งขนาดใหญ่เพื่อตรวจสอบกฎไฟร์วอลล์ มันเป็นเรื่องยาก ความสมบูรณ์ถูกควบคุมโดย BEFW แล้ว เขาตั้งใจแน่วแน่ว่ากฎเกณฑ์ที่เขาทำจะไม่เปลี่ยนแปลง หากมีใครเปลี่ยนกฎไฟร์วอลล์ ทุกอย่างจะเปลี่ยนกลับ “ฉันตั้งค่าพร็อกซีอย่างรวดเร็วเพื่อให้ทำงานจากที่บ้านได้”—ไม่มีตัวเลือกดังกล่าวอีกแล้ว

BEFW ควบคุม ipset จากบริการและรายการใน befw.conf ซึ่งเป็นกฎของบริการในห่วงโซ่ BEFW แต่จะไม่ตรวจสอบเชนและกฎอื่น ๆ และ ipset อื่น ๆ

การป้องกันการชน

BEFW จะจัดเก็บสถานะ good ที่ทราบล่าสุดไว้โดยตรงในโครงสร้างไบนารีของ state.bin หากมีสิ่งผิดปกติเกิดขึ้น ระบบจะย้อนกลับไปที่ state.bin นี้เสมอ

เป็นการประกันการดำเนินงานกงสุลที่ไม่เสถียร เมื่อไม่ได้ส่งข้อมูลหรือมีคนทำผิดและใช้กฎเกณฑ์ที่ไม่สามารถนำไปใช้ได้ เพื่อให้แน่ใจว่าเราจะไม่ถูกทิ้งไว้โดยไม่มีไฟร์วอลล์ BEFW จะย้อนกลับไปสู่สถานะล่าสุดหากมีข้อผิดพลาดเกิดขึ้นในทุกขั้นตอน

ในสถานการณ์วิกฤติ นี่เป็นการรับประกันว่าเราจะเหลือไฟร์วอลล์ที่ใช้งานได้ เราเปิดเครือข่ายสีเทาทั้งหมดโดยหวังว่าแอดมินจะมาแก้ไข สักวันหนึ่งฉันจะใส่สิ่งนี้ลงในการกำหนดค่า แต่ตอนนี้เรามีเพียงสามเครือข่ายสีเทา: 10/8, 172/12 และ 192.168/16 ภายในกงสุลของเรา นี่เป็นคุณลักษณะสำคัญที่ช่วยให้เราพัฒนาต่อไป

การสาธิต: ในระหว่างการรายงาน Ivan สาธิตโหมดสาธิตของ BEFW ดูการสาธิตได้ง่ายขึ้น วีดีโอ. มีซอร์สโค้ดสาธิต บน GitHub.

ข้อผิดพลาด

ฉันจะบอกคุณเกี่ยวกับข้อบกพร่องที่เราพบ

ipset เพิ่มชุด 0.0.0.0/0 จะเกิดอะไรขึ้นถ้าคุณเพิ่ม 0.0.0.0/0 ลงใน ipset IP ทั้งหมดจะถูกเพิ่มหรือไม่ อินเทอร์เน็ตจะสามารถใช้ได้หรือไม่?

ไม่ เราจะได้รับข้อผิดพลาดที่ทำให้เราต้องหยุดทำงานเป็นเวลาสองชั่วโมง ยิ่งไปกว่านั้น ข้อผิดพลาดนี้ไม่ได้ผลมาตั้งแต่ปี 2016 โดยอยู่ใน RedHat Bugzilla ภายใต้หมายเลข #1297092 และเราพบมันโดยบังเอิญ - จากรายงานของนักพัฒนา

ขณะนี้เป็นกฎที่เข้มงวดของ BEFW 0.0.0.0/0 กลายเป็นสองที่อยู่: 0.0.0.0/1 и 128.0.0.0/1.

ipset คืนค่าชุด <ไฟล์. ipset ทำอะไรเมื่อคุณบอกให้ restore? คุณคิดว่ามันใช้งานได้เหมือนกับ iptables หรือไม่? มันจะกู้คืนข้อมูลได้หรือไม่?

ไม่มีอะไรแบบนั้น - เป็นการรวมและที่อยู่เก่าไม่ไปไหน คุณไม่บล็อกการเข้าถึง

เราพบข้อบกพร่องเมื่อทำการทดสอบการแยก ขณะนี้มีระบบที่ค่อนข้างซับซ้อน - แทนที่จะเป็น restore ถูกจัดขึ้น create tempแล้ว restore flush temp и restore temp. ในตอนท้ายของการแลกเปลี่ยน: สำหรับอะตอมมิกซิตี้ เพราะถ้าคุณทำก่อน flush และในขณะนี้มีบางแพ็คเก็ตมาถึงก็จะถูกทิ้งและมีบางอย่างผิดปกติ มีมนตร์ดำอยู่บ้าง

กงสุล kv รับ -datacenter=other อย่างที่ฉันบอกไป เราคิดว่าเรากำลังขอข้อมูลบางอย่าง แต่เราจะได้รับข้อมูลหรือข้อผิดพลาด เราดำเนินการได้ผ่านกงสุลในพื้นที่ แต่ในกรณีนี้ ทั้งสองกรณีจะหยุดดำเนินการ

ไคลเอ็นต์กงสุลในพื้นที่เป็น wrapper บน HTTP API แต่มันค้างและไม่ตอบสนองต่อ Ctrl+C หรือ Ctrl+Z หรืออะไรก็ตามเท่านั้น kill -9 ในคอนโซลถัดไป เราพบสิ่งนี้เมื่อเราสร้างคลัสเตอร์ขนาดใหญ่ แต่เรายังไม่มีวิธีแก้ไข เรากำลังเตรียมแก้ไขข้อผิดพลาดนี้ในกงสุล

หัวหน้ากงสุลไม่ตอบสนอง ผู้เชี่ยวชาญในศูนย์ข้อมูลของเราไม่ตอบสนอง เราคิดว่า: “บางทีอัลกอริธึมการเลือกใหม่อาจจะใช้งานได้ตอนนี้?”

ไม่ มันไม่ทำงาน และการเฝ้าติดตามจะไม่แสดงอะไรเลย กงสุลจะบอกว่ามีดัชนีความมุ่งมั่น พบผู้นำแล้ว ทุกอย่างเรียบร้อยดี

เราจะจัดการกับเรื่องนี้อย่างไร? service consul restart ใน cron ทุก ๆ ชั่วโมง หากคุณมีเซิร์ฟเวอร์ 50 เครื่อง ก็ไม่ใช่เรื่องใหญ่อะไร เมื่อมีครบ 16 ตัว คุณจะเข้าใจว่ามันทำงานอย่างไร

ข้อสรุป

เป็นผลให้เราได้รับข้อดีดังต่อไปนี้:

• ครอบคลุม 100% ของเครื่อง Linux ทั้งหมด
• ความเร็ว
• ระบบอัตโนมัติ
• เราปลดปล่อยวิศวกรฮาร์ดแวร์และเครือข่ายจากการเป็นทาส
• ความเป็นไปได้ในการบูรณาการปรากฏว่าแทบจะไร้ขีดจำกัด แม้แต่กับ Kubernetes แม้แต่กับ Ansible หรือแม้แต่กับ Python ก็ตาม

cons: กงสุลซึ่งตอนนี้เราต้องอาศัยอยู่และค่าความผิดพลาดที่สูงมาก ตัวอย่างเช่นครั้งหนึ่งเวลา 6 น. (ไพรม์ไทม์ในรัสเซีย) ฉันกำลังแก้ไขบางอย่างในรายการเครือข่าย ตอนนั้นเราเพิ่งสร้างฉนวนที่ BEFW ฉันทำผิดพลาดที่ไหนสักแห่ง ดูเหมือนว่าฉันจะระบุหน้ากากผิด แต่ทุกอย่างก็พังทลายลงในสองวินาที การตรวจสอบสว่างขึ้น เจ้าหน้าที่ฝ่ายสนับสนุนก็วิ่งเข้ามา: “เรามีทุกอย่างแล้ว!” หัวหน้าแผนกกลายเป็นสีเทาเมื่อเขาอธิบายให้ธุรกิจฟังว่าทำไมสิ่งนี้จึงเกิดขึ้น

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

ราคา ฉันเขียนโค้ดเป็นเวลา 400 ชั่วโมงคนเดียว ทีมของฉันที่มีสมาชิก 4 คนใช้เวลา 10 ชั่วโมงต่อเดือนในการสนับสนุนทุกคน เมื่อเทียบกับราคาของไฟร์วอลล์รุ่นใหม่แล้ว ถือว่าฟรี

แผน แผนระยะยาวคือการหาการขนส่งทางเลือกมาทดแทนหรือเสริมกงสุล บางทีอาจจะเป็นคาฟคาหรืออะไรทำนองนั้น แต่ในปีต่อๆ ไป เราจะอาศัยอยู่กับกงสุล

แผนทันที: บูรณาการกับ Fail2ban พร้อมการตรวจสอบ ด้วย nftables ซึ่งอาจรวมถึงการแจกแจงอื่น ๆ ตัวชี้วัด การตรวจสอบขั้นสูง การเพิ่มประสิทธิภาพ การสนับสนุน Kubernetes ก็อยู่ในแผนเช่นกัน เนื่องจากตอนนี้เรามีหลายคลัสเตอร์และต้องการ

เพิ่มเติมจากแผน:

• ค้นหาความผิดปกติในการจราจร
• การจัดการแผนที่เครือข่าย
• รองรับ Kubernetes;
• ประกอบแพ็คเกจสำหรับทุกระบบ
• เว็บ-UI

เรากำลังดำเนินการขยายการกำหนดค่า เพิ่มเมตริก และการเพิ่มประสิทธิภาพอย่างต่อเนื่อง

เข้าร่วมโครงการ. โปรเจ็กต์นี้ดูเจ๋งมาก แต่น่าเสียดายที่มันยังคงเป็นโปรเจ็กต์สำหรับคนเดียว มา GitHub และพยายามทำบางสิ่งบางอย่าง: กระทำ ทดสอบ แนะนำบางสิ่งบางอย่าง ให้การประเมินของคุณ

ระหว่างนี้เรากำลังเตรียมตัว เซนต์ไฮโหลด++ซึ่งจะจัดขึ้นในวันที่ 6 และ 7 เมษายนที่เซนต์ปีเตอร์สเบิร์ก และเราขอเชิญผู้พัฒนาระบบที่มีภาระงานสูง สมัครรายงาน. วิทยากรที่มีประสบการณ์รู้อยู่แล้วว่าต้องทำอะไร แต่สำหรับผู้ที่เพิ่งเริ่มพูดเราขอแนะนำอย่างน้อยที่สุด เพื่อลอง. การเข้าร่วมการประชุมในฐานะวิทยากรมีข้อดีหลายประการ คุณสามารถอ่านอันไหนได้ในตอนท้าย ของบทความนี้.

ที่มา: will.com