2010 ۾ ڪمپني اتي 50 سرور هئا ۽ هڪ سادي نيٽ ورڪ ماڊل: پس منظر، فرنٽ اينڊ ۽ فائر وال. سرورن جو تعداد وڌندو ويو، ماڊل وڌيڪ پيچيده ٿي ويو: اسٽيجنگ، الڳ ٿيل VLANs ACLs سان، پوءِ VPNs سان VRFs، VLANs سان ACLs سان L2 تي، VRFs سان ACLs سان L3 تي. سر گھمائي رهيو آهي؟ اهو بعد ۾ وڌيڪ مزو ٿيندو.
جڏهن اتي 16 سرور هئا، اهو ناممڪن ٿي ويو ته ڳوڙها کان سواء ڪم ڪرڻ ڪيترن ئي مختلف حصن سان. تنهنڪري اسان هڪ ٻيو حل کڻي آيا آهيون. اسان ورتو Netfilter اسٽيڪ، ان ۾ قونصل شامل ڪيو ڊيٽا ماخذ جي طور تي، ۽ اسان کي هڪ تيز ورهايل فائر وال مليو. انهن روٽرن تي ACLs کي تبديل ڪيو ۽ انهن کي خارجي ۽ اندروني فائر وال طور استعمال ڪيو. اوزار کي متحرڪ طور تي منظم ڪرڻ لاءِ، اسان BEFW سسٽم تيار ڪيو، جيڪو هر هنڌ استعمال ڪيو ويو: صارف جي رسائي کي منظم ڪرڻ کان وٺي پراڊڪٽ نيٽ ورڪ تائين نيٽ ورڪ حصن کي هڪ ٻئي کان ڌار ڪرڻ تائين.
هو توهان کي ٻڌائيندو ته اهو سڀ ڪجهه ڪيئن ڪم ڪري ٿو ۽ توهان کي هن سسٽم تي ويجهي نظر وجهڻ گهرجي. Ivan Agarkov () ڪمپني جي منسک ڊولپمينٽ سينٽر ۾ مينٽيننس ڊويزن جي انفراسٽرڪچر سيڪيورٽي گروپ جو سربراهه آهي. Ivan هڪ SELinux پرستار آهي، پرل سان پيار ڪندو آهي، ۽ ڪوڊ لکي ٿو. معلوماتي سيڪيورٽي گروپ جي سربراهه جي حيثيت سان، هو باقاعدي لاگ، بيڪ اپ ۽ آر اينڊ ڊي سان ڪم ڪري ٿو وارگيمنگ کي هيڪرز کان بچائڻ ۽ ڪمپني ۾ سڀني گيم سرورز جي آپريشن کي يقيني بڻائڻ لاءِ.
تاريخي پس منظر
ان کان اڳ جو مان توهان کي ٻڌايان ته اسان اهو ڪيئن ڪيو، مان توهان کي ٻڌايان ٿو ته اسان پهرين جڳهه تي ڪيئن آيا ۽ ان جي ضرورت ڇو هئي. هن کي ڪرڻ لاء، اچو ته واپس وڃو 9 سال: 2010، ورلڊ آف ٽينڪس صرف ظاهر ٿيو. Wargaming لڳ ڀڳ 50 سرور هئا.
ڪمپني سرور جي ترقي چارٽ.
اسان وٽ هڪ نيٽ ورڪ ماڊل هو. ان وقت لاءِ اهو ئي مناسب هو.
نيٽ ورڪ ماڊل 2010 ۾.
سامهون آخر ۾ خراب ماڻهو آهن جيڪي اسان کي ٽوڙڻ چاهين ٿا، پر ان ۾ هڪ فائر وال آهي. پس منظر تي ڪو به فائر وال ناهي، پر اتي 50 سرور آهن، اسان انهن سڀني کي ڄاڻون ٿا. سڀ ڪجھ سٺو ڪم ڪري ٿو.
4 سالن ۾، سرور جي فليٽ 100 ڀيرا وڌي 5000 ٿي وئي. پهريون الڳ نيٽ ورڪ ظاهر ٿيو - اسٽيجنگ: اهي پيداوار ڏانهن نه ٿي سگهيا، ۽ اتي اڪثر شيون هلنديون هيون جيڪي خطرناڪ ٿي سگهن ٿيون.
نيٽ ورڪ ماڊل 2014 ۾.
inertia ذريعي، اسان هارڊويئر جا ساڳيا ٽڪرا استعمال ڪيا، ۽ سڄو ڪم الڳ ٿيل VLANs تي ڪيو ويو: ACLs VLANs ڏانهن لکيل آهن، جيڪي ڪنهن قسم جي ڪنيڪشن جي اجازت ڏين ٿا يا رد ڪن ٿا.
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 جي شروعات ۾، ان جي باري ۾ ڪجهه ڪرڻ جو فيصلو ڪيو ويو.
انضمام جي قيمت مسلسل وڌي رهي آهي. شروعاتي نقطو اهو هو ته وڏن ڊيٽا سينٽرن الڳ ٿيل VLANs ۽ ACLs کي سپورٽ ڪرڻ بند ڪيو ڇاڪاڻ ته ڊوائيس ميموري کان ٻاهر ڀڄي ويا.
حل: اسان انساني عنصر کي هٽايو ۽ وڌ ۾ وڌ رسائي جي روزي کي خودڪار ڪيو.
نون ضابطن کي لاڳو ٿيڻ ۾ گهڻو وقت لڳندو آهي. حل: ضابطن جي ايپليڪيشن کي تيز ڪريو، ان کي ورهايو ۽ متوازي ڪريو. ان لاءِ ورهايل سسٽم جي ضرورت آهي ته جيئن ضابطا پاڻ کي پهچائي وڃن، بغير rsync يا SFTP جي هڪ هزار سسٽم تائين.
حصن جي اندر فائر وال ناهي. حصن جي اندر هڪ فائر وال اسان وٽ اچڻ شروع ڪيو جڏهن مختلف خدمتون هڪ ئي نيٽ ورڪ ۾ ظاهر ٿيا. حل: ميزبان سطح تي فائر وال استعمال ڪريو - ميزبان تي ٻڌل فائر والز. تقريبن هر جڳهه اسان وٽ لينڪس آهي، ۽ هر جڳهه اسان وٽ iptables آهن، اهو مسئلو ناهي.
آڊيٽنگ قاعدن سان مشڪلاتون. حل: سڀني قاعدن کي ھڪڙي جڳھ تي نظرثاني ۽ انتظام لاء رکو، تنھنڪري اسين سڀ ڪجھ آڊٽ ڪري سگھون ٿا.
زيربناء تي ڪنٽرول جي گھٽ سطح. حل: سڀني خدمتن جي هڪ فهرست وٺو ۽ انهن جي وچ ۾ رسائي.
هي هڪ ٽيڪنيڪل عمل کان وڌيڪ انتظامي عمل آهي. ڪڏهن ڪڏهن اسان وٽ هفتي ۾ 200-300 نوان رليز ٿيندا آهن، خاص ڪري پروموشنز ۽ موڪلن جي دوران. ان کان علاوه، اهو صرف اسان جي DevOps جي هڪ ٽيم لاء آهي. ڪيتريون ئي رليز سان، اهو ڏسڻ ناممڪن آهي ته ڪهڙي بندرگاهن، IPs، ۽ انضمام جي ضرورت آهي. تنهن ڪري، اسان کي خاص طور تي تربيت ڏيندڙ سروس مينيجرز جي ضرورت هئي جيڪي ٽيمن کان پڇن ٿا: "هتي ڇا آهي ۽ توهان ان کي ڇو آندو؟"
هر شي کان پوءِ اسان لانچ ڪيو ، 2019 ۾ هڪ نيٽ ورڪ انجنيئر هن طرح ڏسڻ شروع ڪيو.
قونصل
اسان فيصلو ڪيو ته سروس مئنيجرن جي مدد سان جيڪو ڪجهه مليو سو قونصل ۾ رکنداسين ۽ اتان iptables قاعدا لکنداسين.
اسان اهو ڪيئن ڪرڻ جو فيصلو ڪيو؟
- اسان سڀني خدمتن، نيٽ ورڪ ۽ صارفين کي گڏ ڪنداسين.
- اچو ته انهن جي بنياد تي iptables ضابطا ٺاهي.
- اسان خودڪار ڪنٽرول.
- ....
- منافعو.
Consul هڪ ريموٽ API نه آهي، اهو هر نوڊ تي هلائي سگهي ٿو ۽ iptables ڏانهن لکي سگهي ٿو. اهو سڀ ڪجهه رهي ٿو پاڻمرادو ڪنٽرول سان گڏ جيڪو غير ضروري شين کي صاف ڪري ڇڏيندو، ۽ اڪثر مسئلا حل ٿي ويندا! باقي اڳتي هلي ڪم ڪنداسين.
قونصل ڇو؟
پاڻ کي چڱي طرح ثابت ڪيو آهي. 2014-15 ۾، اسان ان کي والٽ لاءِ پس منظر طور استعمال ڪيو، جنهن ۾ اسان پاسورڊ محفوظ ڪندا آهيون.
ڊيٽا نه وڃايو. استعمال جي وقت دوران، قونصلر ھڪڙي حادثي دوران ڊيٽا کي وڃائي نه ڇڏيو. هي فائر وال مينيجمينٽ سسٽم لاءِ هڪ وڏو پلس آهي.
P2P ڪنيڪشن تبديلي جي پکيڙ کي تيز ڪري ٿو. P2P سان، سڀ تبديليون جلدي اچن ٿيون، ڪلاڪن جو انتظار ڪرڻ جي ڪا ضرورت ناهي.
آسان REST API. اسان Apache ZooKeeper کي پڻ سمجهيو، پر ان ۾ REST API نه آهي، تنهنڪري توهان کي ڪرچس نصب ڪرڻو پوندو.
ٻنهي جي طور تي ڪم ڪري ٿو هڪ Key Vault (KV) ۽ هڪ ڊائريڪٽري (Service Discovery). توھان ذخيرو ڪري سگھو ٿا خدمتون، فهرست، ۽ ڊيٽا مرڪز ھڪڙي وقت ۾. اهو نه رڳو اسان لاءِ، پر پاڙيسري ٽيمن لاءِ به آسان آهي، ڇاڪاڻ ته جڏهن هڪ عالمي خدمت ٺاهي، اسان وڏي سوچون ٿا.
گو ۾ لکيل آهي، جيڪو وارگيمنگ اسٽيڪ جو حصو آهي. اسان کي هن ٻولي سان پيار آهي، اسان وٽ ڪيترائي گو ڊولپر آهن.
طاقتور ACL سسٽم. قونصل ۾، توهان ACLs استعمال ڪري سگھو ٿا ڪنٽرول ڪرڻ لاءِ ڪير لکي ٿو ڇا. اسان ضمانت ڏيون ٿا ته فائر وال ضابطا ڪنهن به شيءِ سان اوورليپ نه ٿيندا ۽ اسان کي ان سان ڪو مسئلو نه هوندو.
پر قونصل پڻ ان جي خرابي آهي.
- ڊيٽا سينٽر جي اندر پيماني تي نه آهي جيستائين توهان وٽ ڪاروباري ورزن نه آهي. اهو صرف وفاق طرفان اسپيبل آهي.
- نيٽ ورڪ ۽ سرور لوڊ جي معيار تي تمام گهڻو منحصر آهي. Consul هڪ مصروف سرور تي سرور جي طور تي صحيح ڪم نه ڪندو جيڪڏهن نيٽ ورڪ ۾ ڪي به دير آهن، مثال طور، اڻ برابر رفتار. اهو سبب آهي P2P ڪنيڪشن ۽ تازه ڪاري ورهائڻ جا ماڊل.
- دستيابي جي نگراني ۾ مشڪل. قونصل جي حيثيت ۾ هو چئي سگهي ٿو ته سڀ ڪجهه ٺيڪ آهي، پر هو گهڻو وقت اڳ مري ويو.
اسان انهن مسئلن مان اڪثر حل ڪيو جڏهن قونصل استعمال ڪيو، ڇو ته اسان ان کي چونڊيو. ڪمپنيءَ وٽ هڪ متبادل پسمنظر لاءِ منصوبا آهن، پر اسان سکيو آهي مسئلن کي منهن ڏيڻ ۽ هن وقت قونصل سان گڏ رهي رهيا آهيون.
ڪئين قونصل ڪم ڪري ٿو
اسان هڪ مشروط ڊيٽا سينٽر ۾ ٽي کان پنج سرور نصب ڪنداسين. هڪ يا ٻه سرور ڪم نه ڪندا: اهي هڪ ڪورم کي منظم ڪرڻ جي قابل نه هوندا ۽ فيصلو ڪري سگهندا ته ڪير صحيح آهي ۽ ڪير غلط آهي جڏهن ڊيٽا نه ملندي. پنجن کان وڌيڪ ڪو به مطلب ناهي، پيداوار گهٽجي ويندي.
ڪلائنٽ ڪنهن به ترتيب ۾ سرور سان ڳنڍيندا آهن: ساڳيا ايجنٽ، صرف پرچم سان server = false.
انهي کان پوء، گراهڪ P2P ڪنيڪشن جي هڪ فهرست وصول ڪن ٿا ۽ پاڻ ۾ ڪنيڪشن ٺاهي رهيا آهن.
عالمي سطح تي، اسان ڪيترن ئي ڊيٽا مرڪزن کي ڳنڍيندا آهيون. اهي پڻ P2P سان ڳنڍيندا آهن ۽ گفتگو ڪندا آهن.
جڏهن اسان چاهيون ٿا ڊيٽا ٻيهر حاصل ڪرڻ لاءِ ڪنهن ٻئي ڊيٽا سينٽر کان، درخواست سرور کان سرور تائين وڃي ٿي. هن منصوبي کي سڏيو ويندو آهي سرف پروٽوڪول. Serf پروٽوڪول، قونصل وانگر، HashiCorp پاران ترقي ڪئي وئي آھي.
قونصل بابت ڪجھ اهم حقيقتون
قونصل وٽ دستاويز آھن جيڪي بيان ڪن ٿا ته اھو ڪيئن ڪم ڪري ٿو. مان صرف چونڊيل حقيقتون ڏيندس جيڪي ڄاڻڻ جي لائق آهن.
قونصل سرور ووٽرن مان هڪ ماسٽر چونڊيو. ڪنسل هر ڊيٽا سينٽر لاءِ سرورز جي لسٽ مان هڪ ماسٽر چونڊيندو آهي، ۽ سڀ درخواستون صرف ان ڏانهن وينديون آهن، سرور جي تعداد کان سواءِ. ماسٽر منجمد ٿيڻ سان ٻيهر اليڪشن نه ٿي ٿئي. جيڪڏهن ماسٽر چونڊيو نه آهي، درخواستون ڪنهن جي طرفان خدمت نه ڪئي وينديون آهن.
ڇا توهان افقي اسڪيلنگ چاهيو ٿا؟ معاف ڪجو، نه.
ٻئي ڊيٽا سينٽر ڏانهن هڪ درخواست ماسٽر کان ماسٽر تائين وڃي ٿي، قطع نظر ته اهو ڪهڙي سرور تي آيو آهي. منتخب ٿيل ماسٽر لوڊ جو 100٪ وصول ڪري ٿو، سواءِ اڳتي جي درخواستن تي لوڊ جي. ڊيٽا سينٽر ۾ سڀني سرورن وٽ ڊيٽا جي تازه ڪاري ڪاپي آهي، پر صرف هڪ جواب ڏئي ٿو.
ماپ ڪرڻ جو واحد طريقو ڪلائنٽ تي اسٽيل موڊ کي فعال ڪرڻ آهي.
اسٽيل موڊ ۾، توهان بغير ڪورم جي جواب ڏئي سگهو ٿا. هي هڪ طريقو آهي جنهن ۾ اسان ڊيٽا جي تسلسل کي ڇڏي ڏيو ٿا، پر عام کان ٿورو تيز پڙهي، ۽ ڪو به سرور جواب ڏيندو. قدرتي طور، رڪارڊنگ صرف ماسٽر ذريعي.
قونصل ڊيٽا سينٽرن جي وچ ۾ ڊيٽا کي نقل نٿو ڪري. جڏهن هڪ وفاق گڏ ڪيو ويندو، هر سرور وٽ صرف ان جي پنهنجي ڊيٽا هوندي. ٻين لاء، هو هميشه ڪنهن ٻئي ڏانهن موٽندو آهي.
عملن جي ايٽمي جي ضمانت نه آهي ٽرانزيڪشن کان ٻاهر. ياد رکو ته توهان صرف هڪ ئي نه آهيو جيڪو شيون تبديل ڪري سگهي ٿو. جيڪڏھن توھان چاھيو ٿا مختلف طرح، ھڪڙي ٽرانزيڪشن کي تالا سان.
بلاڪنگ عملن کي بند ڪرڻ جي ضمانت نه آهي. درخواست ماسٽر کان ماسٽر تائين وڃي ٿي، ۽ سڌو نه، تنهنڪري اتي ڪا به ضمانت ناهي ته بلاڪنگ ڪم ڪندي جڏهن توهان بلاڪ ڪيو، مثال طور، ڪنهن ٻئي ڊيٽا سينٽر ۾.
ACL پڻ رسائي جي ضمانت نٿو ڏئي (ڪيترن ئي ڪيسن ۾). ACL ڪم نه ڪري سگھي ٿو ڇو ته اھو ھڪڙي فيڊريشن ڊيٽا سينٽر ۾ ذخيرو ٿيل آھي - ACL ڊيٽا سينٽر (پرائمري ڊي سي) ۾. جيڪڏهن ڊي سي توهان کي جواب نه ڏيندو، ACL ڪم نه ڪندو.
هڪ منجهيل ماسٽر سڄي وفاق کي منجمد ڪري ڇڏيندو. مثال طور، هڪ فيڊريشن ۾ 10 ڊيٽا مرڪز آهن، ۽ هڪ خراب نيٽ ورڪ آهي، ۽ هڪ ماسٽر ناڪام آهي. هرڪو جيڪو هن سان ڳالهائيندو، هڪ دائري ۾ ڦاسي ويندو: اتي هڪ درخواست آهي، ان جو ڪو جواب ناهي، موضوع منجمد ٿي ويو آهي. خبر ناهي اهو ڪڏھن ٿيندو، بس ھڪ ٻن ڪلاڪن ۾ سڄي وفاق جو تختو اونڌو ٿي ويندو. ڪجھ به نه آھي توھان ان بابت ڪري سگھو ٿا.
اسٽيٽس، ڪورم ۽ چونڊون الڳ ٿريڊ ذريعي هلايون وڃن ٿيون. ٻيهر اليڪشن نه ٿيندي، اسٽيٽسڪو ڪجهه به نه ڏيکاريندو. توهان سوچيو ته توهان وٽ هڪ زنده قونصل آهي، توهان پڇو، ۽ ڪجهه به نه ٿيندو - ڪو به جواب ناهي. ساڳئي وقت، حالت ڏيکاري ٿو ته هر شيء ٺيڪ آهي.
اسان هن مسئلي کي منهن ڏنو آهي ۽ ان کان بچڻ لاءِ ڊيٽا سينٽرن جي مخصوص حصن کي ٻيهر ٺاهڻو پيو.
قونصل انٽرپرائز جي ڪاروباري ورزن ۾ مٿي ڏنل ڪجھ نقصانات نه آھن. ان ۾ ڪيترائي مفيد ڪم آھن: ووٽرن کي چونڊڻ، تقسيم ڪرڻ، اسڪيلنگ. هتي صرف هڪ آهي "پر" - ورهايل نظام لاءِ لائسنس جو نظام تمام مهانگو آهي.
زندگي هيڪنگ rm -rf /var/lib/consul - ايجنٽ جي سڀني بيمارين لاء هڪ علاج. جيڪڏهن ڪجھ توهان لاء ڪم نٿو ڪري، صرف پنهنجي ڊيٽا کي حذف ڪريو ۽ ڪاپي مان ڊيٽا ڊائون لوڊ ڪريو. گهڻو ڪري، قونصل ڪم ڪندو.
BEFW
هاڻي اچو ته ان بابت ڳالهايون جيڪو اسان قونصل ۾ شامل ڪيو آهي.
لاء هڪ مخفف آهي BackEndFمندرWسڀ. مون کي ڪنهن نه ڪنهن طرح پراڊڪٽ جو نالو ڏيڻو هو جڏهن مون ان ۾ پهريون ٽيسٽ ڪمٽ رکڻ لاءِ مخزن ٺاهيو. اهو نالو رهي ٿو.
ضابطن جا نمونا
ضابطا iptables نحو ۾ لکيل آهن.
- -اين بي ايف ڊبليو
- -P ان پٽ ڊراپ
- -A INPUT -m رياست- رياست سان لاڳاپيل، قائم ڪيل -جي قبول
- -A INPUT -i lo -j قبول ڪريو
- -A INPUT -j BEFW
هر شي BEFW زنجير ۾ وڃي ٿي، سواء ESTABLISHED, RELATED ۽ localhost. ٽيمپليٽ ڪجهه به ٿي سگهي ٿو، اهو صرف هڪ مثال آهي.
BEFW ڪيئن مفيد آهي؟
خدمتون
اسان وٽ هڪ خدمت آهي، اهو هميشه هڪ بندرگاهه آهي، هڪ نوڊ جنهن تي اهو هلندو آهي. اسان جي نوڊ مان، اسان مقامي طور تي ايجنٽ کان پڇي سگھون ٿا ۽ معلوم ڪري سگھون ٿا ته اسان وٽ ڪجھ قسم جي خدمت آھي. توهان پڻ ٽيگ لڳائي سگهو ٿا.
ڪا به خدمت جيڪا هلائي رهي آهي ۽ قونصل سان رجسٽر ٿيل آهي هڪ iptables قاعدي ۾ بدلجي ٿي. اسان وٽ آهي SSH - اوپن پورٽ 22. بش اسڪرپٽ سادي آهي: curl ۽ iptables، ٻيو ڪجهه به گهربل ناهي.
ڪلائيندڙ
هر ڪنهن تائين نه، پر چونڊيل رسائي ڪيئن کولجي؟ سروس جي نالي سان KV اسٽوريج ۾ IP لسٽون شامل ڪريو.
مثال طور، اسان چاهيون ٿا ته هرڪو ڏهين نيٽ ورڪ تي SSH_TCP_22 سروس تائين رسائي حاصل ڪري سگهي. ھڪڙو ننڍڙو TTL فيلڊ شامل ڪريو؟ ۽ هاڻي اسان وٽ عارضي اجازتون آهن، مثال طور، هڪ ڏينهن لاءِ.
رسائي
اسان خدمتون ۽ گراهڪن سان ڳنڍيندا آهيون: اسان وٽ هڪ خدمت آهي، KV اسٽوريج هر هڪ لاء تيار آهي. هاڻي اسان سڀني کي نه، پر چونڊيل طور تي رسائي ڏيون ٿا.
ميڙ
جيڪڏهن اسان هر دفعي رسائي لاءِ هزارين IP لکندا آهيون، اسان ٿڪجي وينداسين. اچو ته گروپن سان گڏ - KV ۾ هڪ الڳ سبسٽ. اچو ته ان کي الياس (يا گروهه) سڏين ۽ ساڳئي اصول مطابق اتي گروپن کي ذخيرو ڪريو.
اچو ته ڳنڍيون: ھاڻي اسان SSH کولي سگھون ٿا خاص طور تي P2P لاءِ نه، پر سڄي گروپ يا ڪيترن ئي گروپن لاءِ. ساڳئي طرح، اتي TTL آهي - توهان هڪ گروپ ۾ شامل ڪري سگهو ٿا ۽ عارضي طور تي گروپ مان هٽائي سگهو ٿا.
انضمام
اسان جو مسئلو انساني فڪر ۽ خودڪار آهي. هينئر تائين اسان هن طريقي سان حل ڪيو آهي.
اسان Puppet سان ڪم ڪريون ٿا، ۽ هر شي کي منتقل ڪريون ٿا جيڪو سسٽم سان لاڳاپيل آهي (ايپليڪيشن ڪوڊ) انهن ڏانهن. Puppetdb (باقاعده PostgreSQL) خدمتن جي هڪ فهرست رکي ٿو جيڪي اتي هلن ٿيون، اهي ڳولي سگهجن ٿيون وسيلن جي قسم سان. اتي توهان ڳولي سگهو ٿا ڪير ڪٿي درخواست ڪري رهيو آهي. اسان وٽ ان لاءِ هڪ پل جي درخواست ۽ ضم ڪرڻ جي درخواست جو نظام پڻ آهي.
اسان لکيو befw-sync، ھڪڙو سادو حل جيڪو ڊيٽا جي منتقلي ۾ مدد ڪري ٿو. پهرين، ڪوڪيز کي هم وقت سازي جي ذريعي پهچايو ويندو آهي puppetdb. هڪ HTTP API اتي ترتيب ڏنل آهي: اسان درخواست ڪريون ٿا ته اسان وٽ ڪهڙيون خدمتون آهن، ڇا ڪرڻ جي ضرورت آهي. پوءِ اهي قونصلر کي درخواست ڏين ٿا.
ڇا انضمام آهي؟ ها: انهن قاعدن کي لکيو ۽ پل جي درخواستن کي قبول ڪرڻ جي اجازت ڏني. ڇا توھان کي ھڪڙي خاص بندرگاھ جي ضرورت آھي يا ھڪڙي گروپ ۾ ميزبان شامل ڪريو؟ درخواست ڪڍو، جائزو وٺو - وڌيڪ نه "200 ٻيا ACLs ڳولھيو ۽ ان بابت ڪجھ ڪرڻ جي ڪوشش ڪريو."
حاصل ڪرڻ
مقامي هوسٽ کي پنگ ڪرڻ هڪ خالي قاعدي زنجير سان 0,075 ايم ايس وٺندو آهي.
اچو ته شامل ڪريو 10 iptables ايڊريس ھن زنجير ۾. نتيجي طور، پنگ 000 ڀيرا وڌي ويندو: iptables مڪمل طور تي لڪير آهي، هر ايڊريس کي پروسيسنگ ڪجهه وقت وٺندو آهي.
هڪ فائر وال لاءِ جتي اسان هزارين ACLs لڏپلاڻ ڪريون ٿا، اسان وٽ ڪيترائي ضابطا آهن، ۽ هي دير سان متعارف ڪرائي ٿو. هي گيمنگ پروٽوڪول لاءِ خراب آهي.
پر جيڪڏهن اسان رکون ٿا ipset ۾ 10 ايڊريس پنگ به گهٽجي ويندو.
نقطو اهو آهي ته ipset لاءِ “O” (الگورٿم پيچيدگي) هميشه 1 جي برابر آهي، ڪابه ڳالهه نه آهي ته ڪيترا قاعدا آهن. سچ، اتي هڪ حد آهي - اتي 65535 قاعدن کان وڌيڪ نه ٿي سگهي ٿو. هن وقت اسان ان سان گڏ رهندا آهيون: توهان انهن کي گڏ ڪري سگهو ٿا، انهن کي وڌايو، هڪ ۾ ٻه ipsets ٺاهي سگهو ٿا.
اسٽوريج
تکرار جي عمل جو منطقي تسلسل ipset ۾ خدمت لاءِ ڪلائنٽ بابت معلومات محفوظ ڪري رهيو آهي.
هاڻي اسان وٽ ساڳيو SSH آهي، ۽ اسان هڪ ڀيرو 100 IPs نه لکندا آهيون، پر ipset جو نالو مقرر ڪندا آهيون جنهن سان اسان کي گفتگو ڪرڻ جي ضرورت آهي، ۽ هيٺ ڏنل قاعدو DROP. اهو هڪ قاعدي ۾ تبديل ٿي سگهي ٿو "ڪير ناهي هتي، DROP"، پر اهو وڌيڪ واضح آهي.
هاڻي اسان وٽ ضابطا ۽ سيٽ آهن. بنيادي ڪم قاعدو لکڻ کان اڳ هڪ سيٽ ٺاهڻ آهي، ڇاڪاڻ ته ٻي صورت ۾ iptables قاعدو نه لکندا.
عام اسڪيم
ڊاگرام جي صورت ۾، مون چيو ته سڀ ڪجهه هن طرح نظر اچي ٿو.
اسان Puppet سان انجام ڏيون ٿا، هر شي کي ميزبان ڏانهن موڪليو ويو آهي، هتي خدمتون، اتي ipset، ۽ جيڪو به رجسٽر ٿيل ناهي اتي اجازت نه آهي.
اجازت ۽ انڪار
دنيا کي جلدي بچائڻ يا جلدي ڪنهن کي غير فعال ڪرڻ لاء، سڀني زنجيرن جي شروعات ۾ اسان ٻه ipsets ٺاهيا: rules_allow и rules_deny. اهو ڪيئن ڪم ڪري ٿو؟
مثال طور، ڪو ماڻهو اسان جي ويب تي بوٽن سان لوڊ ٺاهي رهيو آهي. اڳي، توهان کي لاگ ان مان هن جو IP ڳولڻو هو، ان کي نيٽ ورڪ انجنيئرن ڏانهن وٺي، ته جيئن اهي ٽرئفڪ جو ذريعو ڳولي سگهن ۽ ان تي پابندي لڳائي سگهن. اهو هاڻي مختلف نظر اچي ٿو.
اسان ان کي قونصل ڏانهن موڪليو، 2,5 سيڪنڊ انتظار ڪريو، ۽ اهو ٿي چڪو آهي. جيئن ته قونصلر P2P ذريعي جلدي تقسيم ڪري ٿو، اهو دنيا جي ڪنهن به حصي ۾، هر جڳهه ڪم ڪري ٿو.
هڪ دفعو مون مڪمل طور تي WOT کي فائر وال سان غلطي جي ڪري روڪي ڇڏيو. rules_allow - هي اسان جي انشورنس آهي اهڙين ڪيسن جي خلاف. جيڪڏهن اسان فائر وال سان ڪٿي غلطي ڪئي آهي، ڪجهه هنڌ بند ٿيل آهي، اسان هميشه هڪ مشروط موڪلي سگهون ٿا 0.0/0جلدي سڀڪنھن شيء کي کڻڻ لاء. بعد ۾ اسان هر شيء کي هٿ سان درست ڪنداسين.
ٻيا سيٽ
توھان خلا ۾ ڪو ٻيو سيٽ شامل ڪري سگھو ٿا $IPSETS$.
ڇا جي لاءِ؟ ڪڏهن ڪڏهن ڪنهن کي ipset جي ضرورت آهي، مثال طور، ڪلستر جي ڪجهه حصي جي بندش کي نقل ڪرڻ لاء. ڪو به ڪو به سيٽ آڻي سگهي ٿو، انهن کي نالو ڏيو، ۽ اهي قونصلر کان وٺي ويندا. ساڳئي وقت، سيٽ يا ته iptables ضابطن ۾ حصو وٺي سگهن ٿا يا هڪ ٽيم طور ڪم ڪري سگهن ٿا NOOP: ڊيمن طرفان تسلسل برقرار رکيو ويندو.
صارفين
اڳي، اهو هن طرح هو: صارف نيٽ ورڪ سان ڳنڍيل آهي ۽ ڊومين ذريعي پيٽرولر وصول ڪيو. نئين نسل جي فائر والز جي اچڻ کان اڳ، سسڪو کي خبر نه هئي ته ڪيئن سمجهي سگهجي ته صارف ڪٿي هو ۽ IP ڪٿي هو. تنهن ڪري، رسائي صرف مشين جي ميزبان نالي ذريعي ڏني وئي هئي.
اسان ڇا ڪيو؟ اسان کي ائڊريس ملي ته ان مهل ڦاسي پيا. عام طور تي هي آهي dot1x، وائي فائي يا وي پي اين - سڀ ڪجهه RADIUS ذريعي ٿئي ٿو. هر يوزر لاءِ، اسان يوزرنيم ذريعي هڪ گروپ ٺاهيون ٿا ۽ ان ۾ TTL سان هڪ IP رکون ٿا جيڪو ان جي dhcp.lease جي برابر آهي - جيئن ئي اهو ختم ٿيندو، اهو قاعدو غائب ٿي ويندو.
ھاڻي اسان ٻين گروپن وانگر، يوزرنيم ذريعي خدمتن تائين رسائي کولي سگھون ٿا. اسان ميزبان نالن مان درد ڪڍي ڇڏيو آهي جڏهن اهي تبديل ٿين ٿا، ۽ اسان نيٽ ورڪ انجنيئرن تان بار کڻايو آهي ڇو ته انهن کي هاڻي Cisco جي ضرورت ناهي. ھاڻي انجنيئر پاڻ کي رجسٽر ڪندا آھن پنھنجي سرور تي رسائي.
موصليت
ساڳئي وقت، اسان موصليت کي ختم ڪرڻ شروع ڪيو. سروس مينيجرز هڪ فهرست ورتي، ۽ اسان اسان جي سڀني نيٽ ورڪن جو تجزيو ڪيو. اچو ته انهن کي ساڳئي گروپن ۾ ورهايو، ۽ ضروري سرور تي گروپ شامل ڪيا ويا، مثال طور، انڪار ڪرڻ. هاڻي ساڳيو اسٽيجنگ آئسوليشن پيداوار جي قاعدن_انڪارن ۾ ختم ٿئي ٿو، پر خود پيداوار ۾ نه.
اسڪيم تڪڙو ۽ سادو ڪم ڪري ٿو: اسان سڀني ACLs کي سرور مان هٽايو، هارڊويئر کي لوڊ ڪريو، ۽ الڳ ٿيل VLANs جو تعداد گھٽايو.
سالميت ڪنٽرول
اڳي، اسان وٽ ھڪڙو خاص محرڪ ھو جنھن کي ٻڌايو ويو آھي جڏھن ڪنھن ماڻھوءَ کي دستي طور تي فائر وال قاعدو تبديل ڪيو. مان فائر وال جي ضابطن کي جانچڻ لاءِ هڪ وڏو لينٽر لکي رهيو هوس، اهو ڏکيو هو. سالميت هاڻي BEFW پاران ڪنٽرول آهي. هو جوش سان يقيني بڻائي ٿو ته جيڪي ضابطا هن ٺاهيندا آهن انهن ۾ تبديلي نه ايندي. جيڪڏهن ڪو ماڻهو فائر وال جي ضابطن کي تبديل ڪري ٿو، اهو سڀ ڪجهه واپس تبديل ڪندو. ”مون جلدي هڪ پراڪسي سيٽ ڪئي ته جيئن مان گهر کان ڪم ڪري سگهان“- اهڙا وڌيڪ آپشن نه آهن.
BEFW ipset کي خدمتن مان ڪنٽرول ڪري ٿو ۽ befw.conf ۾ لسٽ ڪري ٿو، BEFW زنجير ۾ خدمتن جا قاعدا. پر اهو ٻين زنجيرن ۽ ضابطن ۽ ٻين ipsets جي نگراني نٿو ڪري.
حادثي جي حفاظت
BEFW هميشه آخري سڃاتل سٺي رياست کي سڌو سنئون رياست ۾ ذخيرو ڪري ٿو. جيڪڏهن ڪجهه غلط ٿئي ٿو، اهو هميشه هن state.bin ڏانهن واپس اچي ٿو.
هي غير مستحڪم قونصلر آپريشن جي خلاف انشورنس آهي، جڏهن اهو ڊيٽا نه موڪليو يا ڪنهن غلطي ڪئي ۽ ضابطا استعمال ڪيا جيڪي لاڳو نٿا ٿي سگهن. انهي ڳالهه کي يقيني بڻائڻ لاءِ ته اسان فائر وال کان سواءِ نه رهجي ويا آهيون، BEFW جديد رياست ڏانهن واپس هليو ويندو جيڪڏهن ڪنهن مرحلي تي ڪا غلطي ٿئي ٿي.
نازڪ حالتن ۾، اها هڪ گارنٽي آهي ته اسان کي ڪم ڪندڙ فائر وال سان رهجي ويندو. اسان سڀ گري نيٽ ورڪ کوليون ٿا ان اميد سان ته ايڊمن اچي ان کي درست ڪندو. ڪنهن ڏينهن مان هن کي ترتيب ۾ وجهي ڇڏيندس، پر هاڻي اسان وٽ صرف ٽي گرين نيٽ ورڪ آهن: 10/8، 172/12 ۽ 192.168/16. اسان جي قونصل جي اندر، اها هڪ اهم خصوصيت آهي جيڪا اسان کي اڳتي وڌڻ ۾ مدد ڪري ٿي.
ڊيمو: رپورٽ دوران، ايوان BEFW جي ڊيمو موڊ کي ڏيکاري ٿو. اهو مظاهرو ڏسڻ لاء آسان آهي . Demo ذريعو ڪوڊ موجود .
نقصان
مان توهان کي ٻڌايان ٿو انهن جي باري ۾ جيڪي اسان سامهون آيا.
ipset اضافو سيٽ 0.0.0.0/0. ڇا ٿيندو جيڪڏھن توھان 0.0.0.0/0 کي ipset ۾ شامل ڪيو؟ ڇا سڀ IPs شامل ڪيا ويندا؟ ڇا انٽرنيٽ جي رسائي دستياب ٿي ويندي؟
نه، اسان هڪ بگ حاصل ڪنداسين جيڪو اسان کي ٻن ڪلاڪن جي گھٽ وقت جي قيمت ڏيندو. ان کان علاوه، بگ 2016 کان ڪم نه ڪيو آهي، اهو نمبر #1297092 جي تحت RedHat Bugzilla ۾ واقع آهي، ۽ اسان ان کي حادثي سان مليو - هڪ ڊولپر جي رپورٽ مان.
اهو هاڻي 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 get -datacenter = ٻيو. جيئن مون چيو، اسان سوچيو ٿا ته اسان ڪجهه ڊيٽا لاء پڇي رهيا آهيون، پر اسان يا ته ڊيٽا يا غلطي حاصل ڪنداسين. اسان مقامي طور تي قونصل ذريعي ڪري سگهون ٿا، پر هن صورت ۾ ٻئي منجمد ٿي ويندا.
مقامي قونصل ڪلائنٽ HTTP API تي هڪ لپيندڙ آهي. پر اهو صرف لڪي ٿو ۽ Ctrl+C، يا Ctrl+Z، يا ڪنهن به شيءِ جو جواب نٿو ڏئي، صرف kill -9 ايندڙ ڪنسول ۾. اسان کي اهو سامنا ٿيو جڏهن اسان هڪ وڏو ڪلستر ٺاهي رهيا هئاسين. پر اسان وٽ اڃا تائين ڪو حل ناهي؛ اسان قونصل ۾ هن غلطي کي درست ڪرڻ جي تياري ڪري رهيا آهيون.
قونصل اڳواڻ جواب نه ڏئي رهيو آهي. ڊيٽا سينٽر ۾ اسان جو ماسٽر جواب نه ڏئي رهيو آهي، اسان سوچيو: "شايد ٻيهر چونڊ الگورتھم هاڻي ڪم ڪندو؟"
نه، اهو ڪم نه ڪندو، ۽ مانيٽرنگ ڪجهه به نه ڏيکاريندو: قونصل چوندو ته هڪ عزم انڊيڪس آهي، هڪ ليڊر مليو آهي، سڀ ڪجهه ٺيڪ آهي.
اسان هن سان ڪيئن ڊيل ڪريون؟ service consul restart هر ڪلاڪ ۾ ڪرون. جيڪڏهن توهان وٽ 50 سرور آهن، ڪا وڏي ڳالهه ناهي. جڏهن انهن مان 16 آهن، توهان سمجهي سگهندا ته اهو ڪيئن ڪم ڪري ٿو.
ٿڪل
نتيجي طور، اسان ھيٺ ڏنل فائدا حاصل ڪيا:
- سڀني لينڪس مشينن جي 100٪ ڪوريج.
- اسپيڊ.
- آٽوميشن.
- اسان هارڊويئر ۽ نيٽ ورڪ انجنيئرن کي غلاميءَ مان آزاد ڪيو.
- انضمام جا امڪان ظاهر ٿيا آهن جيڪي لڳ ڀڳ لامحدود آهن: حتي ڪبرنيٽس سان، حتي جوابي سان، حتي پٿون سان.
Минусы: قونصل، جنهن سان اسان کي هاڻي رهڻو آهي، ۽ غلطي جي تمام اعلي قيمت. مثال طور، هڪ ڀيرو شام 6 وڳي (روس ۾ پرائم ٽائيم) مان نيٽ ورڪ جي لسٽن ۾ ڪجهه ايڊٽ ڪري رهيو هوس. اسان وقت تي BEFW تي صرف موصليت تعمير ڪري رهيا هئاسين. مون ڪٿي غلطي ڪئي، لڳي ٿو مون غلط نقاب کي اشارو ڪيو، پر سڀ ڪجهه ٻن سيڪنڊن ۾ ٿي ويو. مانيٽرنگ روشني وڌي ٿي، ڊيوٽي تي مددگار ماڻهو ڊوڙندو اچي ٿو: ”اسان وٽ سڀ ڪجهه آهي! ڊپارٽمينٽ جو سربراهه ڳاڙهو ٿي ويو جڏهن هن ڪاروبار کي ٻڌايو ته اهو ڇو ٿيو.
غلطي جي قيمت تمام گهڻي آهي ته اسان اسان جي پنهنجي پيچيده روڪٿام جي طريقيڪار سان گڏ آيا آهيون. جيڪڏهن توهان هن کي وڏي پيداوار واري سائيٽ تي لاڳو ڪريو ٿا، توهان کي هر ڪنهن کي قونصل تي ماسٽر ٽوڪن ڏيڻ جي ضرورت ناهي. اهو خراب ختم ٿي ويندو.
خرچ مون اڪيلي 400 ڪلاڪن لاءِ ڪوڊ لکيو. منهنجي ٽيم 4 ماڻهن جي هر مهيني 10 ڪلاڪ هر ڪنهن جي مدد تي خرچ ڪري ٿي. ڪنهن به نئين نسل جي فائر وال جي قيمت جي مقابلي ۾، اها مفت آهي.
منصوبا. ڊگھي مدت جو منصوبو آھي متبادل ٽرانسپورٽ ڳولڻ لاءِ جيڪو ڪنسل کي تبديل ڪرڻ يا پورو ڪرڻ لاءِ. شايد اهو ڪافڪا يا ٻيو ڪجهه هوندو. پر ايندڙ سالن ۾ اسان قونصلن تي رهنداسين.
فوري منصوبا: Fail2ban سان انضمام، نگراني سان، nftables سان، ممڪن طور تي ٻين تقسيم سان، ميٽرڪس، ترقي يافته نگراني، اصلاح. Kubernetes سپورٽ پڻ منصوبن ۾ ڪٿي آهي، ڇاڪاڻ ته هاڻي اسان وٽ ڪيترائي ڪلستر ۽ خواهش آهي.
منصوبن کان وڌيڪ:
- ٽرئفڪ ۾ بي ضابطگين جي ڳولا؛
- نيٽ ورڪ نقشي جو انتظام؛
- Kubernetes جي حمايت؛
- سڀني سسٽم لاء پيڪيجز گڏ ڪرڻ؛
- ويب-UI.
اسان مسلسل ڪم ڪري رهيا آهيون تشڪيل کي وڌائڻ، ميٽرڪس ۽ اصلاح کي وڌائڻ تي.
منصوبي ۾ شامل ٿيو. پروجيڪٽ ٿڌو ٿي ويو، پر، بدقسمتي سان، اهو اڃا تائين هڪ شخص وارو منصوبو آهي. اچڻ ۽ ڪجھ ڪرڻ جي ڪوشش ڪريو: انجام ڏيو، ٽيسٽ ڪريو، ڪجھ تجويز ڪريو، پنھنجو جائزو ڏيو.
ان دوران اسان تياري ڪري رهيا آهيون ، جيڪو 6 ۽ 7 اپريل تي سينٽ پيٽرسبرگ ۾ ٿيندو، ۽ اسان اعلي لوڊ سسٽم جي ڊولپرز کي دعوت ڏيون ٿا. . تجربيڪار ڳالهائيندڙ اڳ ۾ ئي ڄاڻن ٿا ته ڇا ڪجي، پر انهن لاءِ جيڪي ڳالهائڻ لاءِ نوان آهن اسان گهٽ ۾ گهٽ سفارش ڪريون ٿا . ڪانفرنس ۾ اسپيڪر طور شرڪت ڪرڻ جا ڪيترائي فائدا آھن. توھان پڙھي سگھوٿا ڪھڙا، مثال طور، آخر ۾ .
جو ذريعو: www.habr.com