कौंसल + आईपीटेबल्स = :3

2010 में कंपनी युद्ध संबंधीगेम वहाँ 50 सर्वर और एक सरल नेटवर्क मॉडल था: बैकएंड, फ्रंटएंड और फ़ायरवॉल। सर्वरों की संख्या बढ़ी, मॉडल अधिक जटिल हो गया: स्टेजिंग, एसीएल के साथ पृथक वीएलएएन, फिर वीआरएफ के साथ वीपीएन, एल2 पर एसीएल के साथ वीएलएएन, एल3 पर एसीएल के साथ वीआरएफ। सिर घूम रहा है? बाद में और मजा आएगा.

जब 16 सर्वर थे, तो इतने सारे विविध खंडों के साथ बिना रुके काम करना असंभव हो गया। इसलिए हम एक और समाधान लेकर आए। हमने नेटफिल्टर स्टैक लिया, इसमें डेटा स्रोत के रूप में कॉन्सल को जोड़ा और हमें एक तेजी से वितरित फ़ायरवॉल मिला। उन्होंने राउटर पर एसीएल को बदल दिया और उन्हें बाहरी और आंतरिक फ़ायरवॉल के रूप में उपयोग किया। टूल को गतिशील रूप से प्रबंधित करने के लिए, हमने BEFW प्रणाली विकसित की, जिसका उपयोग हर जगह किया गया: उत्पाद नेटवर्क तक उपयोगकर्ता की पहुंच को प्रबंधित करने से लेकर नेटवर्क खंडों को एक दूसरे से अलग करने तक।

वह आपको बताएगा कि यह सब कैसे काम करता है और आपको इस प्रणाली पर करीब से नज़र क्यों डालनी चाहिए। इवान अगरकोव (annmuor) कंपनी के मिन्स्क विकास केंद्र में रखरखाव प्रभाग के बुनियादी ढांचे सुरक्षा समूह का प्रमुख है। इवान SELinux का प्रशंसक है, पर्ल से प्यार करता है और कोड लिखता है। सूचना सुरक्षा समूह के प्रमुख के रूप में, वह वॉरगेमिंग को हैकर्स से बचाने और कंपनी में सभी गेम सर्वरों के संचालन को सुनिश्चित करने के लिए नियमित रूप से लॉग, बैकअप और आर एंड डी के साथ काम करते हैं।

ऐतिहासिक जानकारी

इससे पहले कि मैं आपको बताऊं कि हमने यह कैसे किया, मैं आपको बताऊंगा कि हम सबसे पहले इस तक कैसे पहुंचे और इसकी आवश्यकता क्यों थी। ऐसा करने के लिए, आइए 9 साल पीछे चलें: 2010, टैंकों की दुनिया अभी सामने आई। वॉरगेमिंग में लगभग 50 सर्वर थे।

कंपनी सर्वर ग्रोथ चार्ट.

हमारे पास एक नेटवर्क मॉडल था। उस समय के लिए यह इष्टतम था।

2010 में नेटवर्क मॉडल।

सामने वाले छोर पर बुरे लोग हैं जो हमें तोड़ना चाहते हैं, लेकिन इसमें फ़ायरवॉल है। बैकएंड पर कोई फ़ायरवॉल नहीं है, लेकिन वहां 50 सर्वर हैं, हम उन सभी को जानते हैं। सब कुछ अच्छे से काम करता है.

4 वर्षों में, सर्वर बेड़ा 100 गुना बढ़कर 5000 हो गया। पहले पृथक नेटवर्क दिखाई दिए - स्टेजिंग: वे उत्पादन में नहीं जा सकते थे, और वहां अक्सर ऐसी चीजें चल रही थीं जो खतरनाक हो सकती थीं।

2014 में नेटवर्क मॉडल।

जड़ता से, हमने हार्डवेयर के समान टुकड़ों का उपयोग किया, और सभी काम अलग-अलग वीएलएएन पर किए गए: एसीएल वीएलएएन को लिखे गए हैं, जो किसी प्रकार के कनेक्शन की अनुमति देते हैं या अस्वीकार करते हैं।

2016 में, सर्वरों की संख्या 8000 तक पहुंच गई। वॉरगेमिंग ने अन्य स्टूडियो को अवशोषित कर लिया, और अतिरिक्त संबद्ध नेटवर्क दिखाई दिए। वे हमारे प्रतीत होते हैं, लेकिन बिल्कुल नहीं: वीएलएएन अक्सर भागीदारों के लिए काम नहीं करता है, आपको वीआरएफ के साथ वीपीएन का उपयोग करना होगा, अलगाव अधिक जटिल हो जाता है। एसीएल इन्सुलेशन मिश्रण में वृद्धि हुई।

2016 में नेटवर्क मॉडल।

2018 की शुरुआत तक, मशीनों का बेड़ा 16 तक बढ़ गया था। इसमें 000 खंड थे, और हमने बाकी की गिनती नहीं की, जिसमें बंद मशीनें भी शामिल थीं जिनमें वित्तीय डेटा संग्रहीत था। कंटेनर नेटवर्क (कुबेरनेट्स), डेवऑप्स, वीपीएन के माध्यम से जुड़े क्लाउड नेटवर्क, उदाहरण के लिए, आईवीएस से, सामने आए हैं। बहुत सारे नियम थे - यह दर्दनाक था।

2018 में नेटवर्क मॉडल और अलगाव के तरीके।

अलगाव के लिए हमने उपयोग किया: L2 पर ACL के साथ VLAN, L3 पर ACL के साथ VRF, VPN और भी बहुत कुछ। बहुत अधिक।

समस्याओं

हर कोई ACL और VLAN के साथ रहता है। क्या गलत? इस सवाल का जवाब हेरोल्ड दर्द छुपाते हुए देगा।

बहुत सारी समस्याएँ थीं, लेकिन पाँच बड़ी समस्याएँ भी थीं।

• नए नियमों के लिए ज्यामितीय मूल्य वृद्धि. प्रत्येक नए नियम को जोड़ने में पिछले नियम की तुलना में अधिक समय लगता था, क्योंकि पहले यह देखना आवश्यक था कि क्या पहले से ही ऐसा कोई नियम था।
• खंडों के अंदर कोई फ़ायरवॉल नहीं. खंड किसी तरह एक-दूसरे से अलग हो गए थे, और अंदर पहले से ही पर्याप्त संसाधन नहीं थे।
• नियम लंबे समय तक लागू रहे। ऑपरेटर एक घंटे में एक स्थानीय नियम हाथ से लिख सकते थे। वैश्विक स्तर पर कई दिन लग गए।
• ऑडिटिंग नियमों में कठिनाइयाँ. अधिक सटीक रूप से, यह संभव नहीं था। पहले नियम 2010 में लिखे गए थे, और उनके अधिकांश लेखक अब कंपनी के लिए काम नहीं करते हैं।
• बुनियादी ढांचे पर नियंत्रण का निम्न स्तर. यह मुख्य समस्या है - हमें ठीक से पता नहीं था कि हमारे देश में क्या चल रहा है।

2018 में एक नेटवर्क इंजीनियर ऐसा दिखता था जब उसने सुना: "कुछ और एसीएल की आवश्यकता है।"

Решения

2018 की शुरुआत में इस बारे में कुछ करने का निर्णय लिया गया।

एकीकरण की कीमत लगातार बढ़ रही है। शुरुआती बिंदु यह था कि बड़े डेटा केंद्रों ने अलग-अलग वीएलएएन और एसीएल का समर्थन करना बंद कर दिया क्योंकि डिवाइस की मेमोरी खत्म हो गई थी।

समाधान: हमने मानवीय कारक को हटा दिया और अधिकतम तक पहुंच के प्रावधान को स्वचालित कर दिया।

नये नियम लागू होने में काफी समय लगता है. समाधान: नियमों के कार्यान्वयन में तेजी लाएं, इसे वितरित और समानांतर बनाएं। इसके लिए एक वितरित प्रणाली की आवश्यकता होती है ताकि नियम स्वयं rsync या SFTP के बिना एक हजार प्रणालियों तक वितरित हो सकें।

खंडों के अंदर कोई फ़ायरवॉल नहीं. जब एक ही नेटवर्क में अलग-अलग सेवाएँ दिखाई दीं तो खंडों के भीतर एक फ़ायरवॉल हमारे पास आना शुरू हुआ। समाधान: होस्ट स्तर पर फ़ायरवॉल का उपयोग करें - होस्ट-आधारित फ़ायरवॉल। लगभग हर जगह हमारे पास Linux है, और हर जगह हमारे पास iptables है, यह कोई समस्या नहीं है।

ऑडिटिंग नियमों में कठिनाइयाँ। समाधान: समीक्षा और प्रबंधन के लिए सभी नियमों को एक ही स्थान पर रखें, ताकि हम हर चीज़ का ऑडिट कर सकें।

बुनियादी ढांचे पर नियंत्रण का निम्न स्तर। समाधान: सभी सेवाओं और उनके बीच पहुंच की एक सूची लें।

यह तकनीकी से अधिक एक प्रशासनिक प्रक्रिया है। कभी-कभी हमारे पास एक सप्ताह में 200-300 नई रिलीज़ होती हैं, विशेषकर प्रचार और छुट्टियों के दौरान। इसके अलावा, यह हमारे DevOps की केवल एक टीम के लिए है। इतने सारे रिलीज़ के साथ, यह देखना असंभव है कि किन पोर्ट, आईपी और एकीकरण की आवश्यकता है। इसलिए, हमें विशेष रूप से प्रशिक्षित सेवा प्रबंधकों की आवश्यकता थी जो टीमों से पूछें: "आखिर इसमें क्या है और आपने इसे क्यों उठाया?"

हमने जो कुछ भी लॉन्च किया, उसके बाद 2019 में एक नेटवर्क इंजीनियर इस तरह दिखने लगा।

कौंसल

हमने तय किया कि हम सेवा प्रबंधकों की मदद से जो कुछ भी पाएंगे उसे कौंसल में डाल देंगे और वहां से हम iptables नियम लिखेंगे।

हमने ऐसा करने का निर्णय कैसे लिया?

• हम सभी सेवाओं, नेटवर्क और उपयोगकर्ताओं को एकत्र करेंगे।
• आइए उनके आधार पर iptables नियम बनाएं।
• हम नियंत्रण स्वचालित करते हैं.
• ....
• फायदा।

कॉन्सल एक रिमोट एपीआई नहीं है, यह हर नोड पर चल सकता है और iptables पर लिख सकता है। जो कुछ बचा है वह स्वचालित नियंत्रण के साथ आना है जो अनावश्यक चीजों को साफ कर देगा, और अधिकांश समस्याएं हल हो जाएंगी! हम जाते-जाते बाकी काम कर लेंगे।

कौंसल क्यों?

खुद को बखूबी साबित किया है. 2014-15 में, हमने इसे वॉल्ट के लिए बैकएंड के रूप में उपयोग किया, जिसमें हम पासवर्ड संग्रहीत करते हैं।

डेटा नहीं खोता. उपयोग के दौरान, कॉन्सल ने एक भी दुर्घटना के दौरान डेटा नहीं खोया। फ़ायरवॉल प्रबंधन प्रणाली के लिए यह एक बहुत बड़ा लाभ है।

पी2पी कनेक्शन परिवर्तन के प्रसार को तेज करते हैं. पी2पी के साथ, सभी परिवर्तन शीघ्रता से आते हैं, घंटों इंतजार करने की आवश्यकता नहीं होती है।

सुविधाजनक रेस्ट एपीआई। हमने Apache ZooKeeper पर भी विचार किया, लेकिन इसमें REST API नहीं है, इसलिए आपको बैसाखी स्थापित करनी होगी।

एक कुंजी वॉल्ट (केवी) और एक निर्देशिका (सेवा डिस्कवरी) दोनों के रूप में काम करता है. आप सेवाओं, कैटलॉग और डेटा केंद्रों को एक साथ संग्रहीत कर सकते हैं। यह न केवल हमारे लिए, बल्कि पड़ोसी टीमों के लिए भी सुविधाजनक है, क्योंकि वैश्विक सेवा बनाते समय हम बड़ा सोचते हैं।

गो में लिखा गया है, जो वॉरगेमिंग स्टैक का हिस्सा है। हमें यह भाषा पसंद है, हमारे पास कई गो डेवलपर हैं।

शक्तिशाली एसीएल प्रणाली. कॉन्सल में, आप यह नियंत्रित करने के लिए एसीएल का उपयोग कर सकते हैं कि कौन क्या लिखता है। हम गारंटी देते हैं कि फ़ायरवॉल नियम किसी भी अन्य चीज़ के साथ ओवरलैप नहीं होंगे और हमें इससे कोई समस्या नहीं होगी।

लेकिन कौंसुल की अपनी कमियां भी हैं।

• जब तक आपके पास कोई व्यावसायिक संस्करण न हो, डेटा सेंटर के भीतर स्केल नहीं होता है। यह केवल फेडरेशन द्वारा स्केलेबल है।
• नेटवर्क की गुणवत्ता और सर्वर लोड पर बहुत निर्भर है। यदि नेटवर्क में कोई अंतराल है, उदाहरण के लिए, असमान गति, तो व्यस्त सर्वर पर कंसल एक सर्वर के रूप में ठीक से काम नहीं करेगा। यह पी2पी कनेक्शन और अद्यतन वितरण मॉडल के कारण है।
• उपलब्धता की निगरानी में कठिनाई. कौंसल की हैसियत से वह कह सकता है कि सब कुछ ठीक है, लेकिन उसकी काफी पहले मौत हो चुकी है।

कॉन्सल का उपयोग करते समय हमने इनमें से अधिकांश समस्याओं का समाधान किया, यही कारण है कि हमने इसे चुना। कंपनी के पास वैकल्पिक बैकएंड की योजना है, लेकिन हमने समस्याओं से निपटना सीख लिया है और वर्तमान में कॉन्सल के साथ रह रहे हैं।

कंसल कैसे काम करता है

हम एक सशर्त डेटा सेंटर में तीन से पांच सर्वर स्थापित करेंगे। एक या दो सर्वर काम नहीं करेंगे: वे कोरम व्यवस्थित करने और यह तय करने में सक्षम नहीं होंगे कि डेटा मेल नहीं खाने पर कौन सही है और कौन गलत है। पांच से अधिक का कोई मतलब नहीं है, उत्पादकता गिर जाएगी।

ग्राहक किसी भी क्रम में सर्वर से जुड़ते हैं: वही एजेंट, केवल ध्वज के साथ server = false.

इसके बाद, ग्राहकों को पी2पी कनेक्शन की एक सूची प्राप्त होती है और वे आपस में कनेक्शन बनाते हैं।

वैश्विक स्तर पर, हम कई डेटा केंद्रों को जोड़ते हैं। वे पी2पी को भी जोड़ते हैं और संचार करते हैं।

जब हम किसी अन्य डेटा सेंटर से डेटा पुनर्प्राप्त करना चाहते हैं, तो अनुरोध सर्वर से सर्वर पर जाता है। इस योजना को कहा जाता है सर्फ़ प्रोटोकॉल. कॉन्सल की तरह सर्फ़ प्रोटोकॉल, हाशीकॉर्प द्वारा विकसित किया गया है।

कौंसल के बारे में कुछ महत्वपूर्ण तथ्य

कौंसल के पास यह वर्णन करने वाले दस्तावेज़ हैं कि यह कैसे काम करता है। मैं केवल चुनिंदा तथ्य ही बताऊंगा जो जानने लायक हैं।

कॉन्सल सर्वर मतदाताओं में से एक मास्टर का चयन करते हैं. कॉन्सल प्रत्येक डेटा सेंटर के लिए सर्वरों की सूची से एक मास्टर का चयन करता है, और सर्वरों की संख्या की परवाह किए बिना, सभी अनुरोध केवल उसी के पास जाते हैं। मास्टर फ्रीजिंग से दोबारा चुनाव नहीं होता। यदि मास्टर का चयन नहीं किया गया है, तो किसी के द्वारा अनुरोधों की सेवा नहीं ली जाएगी।

क्या आप क्षैतिज स्केलिंग चाहते थे? क्षमा करें, नहीं.

किसी अन्य डेटा सेंटर के लिए अनुरोध मास्टर से मास्टर तक जाता है, चाहे वह किसी भी सर्वर से आया हो। अग्रेषित अनुरोधों पर लोड को छोड़कर, चयनित मास्टर को 100% लोड प्राप्त होता है। डेटा सेंटर के सभी सर्वरों के पास डेटा की अद्यतन प्रतिलिपि होती है, लेकिन केवल एक ही प्रतिक्रिया देता है।

स्केल करने का एकमात्र तरीका क्लाइंट पर बासी मोड को सक्षम करना है।

बासी मोड में, आप बिना कोरम के उत्तर दे सकते हैं। यह एक ऐसी विधा है जिसमें हम डेटा स्थिरता छोड़ देते हैं, लेकिन सामान्य से थोड़ा तेज पढ़ते हैं, और कोई भी सर्वर प्रतिक्रिया देता है। स्वाभाविक रूप से, रिकॉर्डिंग केवल मास्टर के माध्यम से होती है।

कॉन्सल डेटा केंद्रों के बीच डेटा की प्रतिलिपि नहीं बनाता है. जब एक फेडरेशन इकट्ठा होता है, तो प्रत्येक सर्वर के पास केवल अपना डेटा होगा। दूसरों के लिए वह हमेशा किसी और की ओर रुख करता है।

लेन-देन के बाहर संचालन की परमाणुता की गारंटी नहीं है. याद रखें कि आप अकेले नहीं हैं जो चीज़ें बदल सकते हैं। यदि आप इसे अलग तरह से चाहते हैं, तो ताले के साथ लेनदेन करें।

ब्लॉकिंग ऑपरेशन लॉकिंग की गारंटी नहीं देते. अनुरोध मास्टर से मास्टर तक जाता है, सीधे नहीं, इसलिए इस बात की कोई गारंटी नहीं है कि जब आप ब्लॉक करते हैं, उदाहरण के लिए, किसी अन्य डेटा सेंटर में ब्लॉकिंग काम करेगी।

एसीएल भी पहुंच की गारंटी नहीं देता (कई मामलों में). ACL काम नहीं कर सकता क्योंकि यह एक फ़ेडरेशन डेटा सेंटर - ACL डेटा सेंटर (प्राथमिक DC) में संग्रहीत है। यदि डीसी आपको उत्तर नहीं देता है, तो एसीएल काम नहीं करेगा।

एक जमे हुए मास्टर के कारण पूरा महासंघ जम जाएगा. उदाहरण के लिए, एक फेडरेशन में 10 डेटा सेंटर हैं, और एक का नेटवर्क ख़राब है, और एक मास्टर विफल है। हर कोई जो उसके साथ संवाद करता है वह एक घेरे में फंस जाएगा: एक अनुरोध है, इसका कोई जवाब नहीं है, धागा रुक जाता है। यह कब होगा, यह जानने का कोई तरीका नहीं है, बस एक या दो घंटे में पूरा महासंघ गिर जाएगा। आप इसके बारे में कुछ नहीं कर सकते।

स्थिति, कोरम और चुनाव को एक अलग सूत्र द्वारा नियंत्रित किया जाता है। दोबारा चुनाव नहीं होगा, स्टेटस कुछ नहीं बताएगा. आप सोचते हैं कि आपके पास एक जीवित कौंसल है, आप पूछते हैं, और कुछ नहीं होता - कोई उत्तर नहीं है। वहीं, स्टेटस से पता चलता है कि सब कुछ ठीक है.

हमने इस समस्या का सामना किया है और इससे बचने के लिए हमें डेटा केंद्रों के विशिष्ट हिस्सों का पुनर्निर्माण करना पड़ा है।

कॉन्सल एंटरप्राइज के व्यावसायिक संस्करण में उपरोक्त कुछ नुकसान नहीं हैं. इसके कई उपयोगी कार्य हैं: मतदाताओं का चयन करना, वितरण करना, स्केलिंग करना। केवल एक "लेकिन" है - एक वितरित प्रणाली के लिए लाइसेंसिंग प्रणाली बहुत महंगी है।

जीवन हैकिंग: rm -rf /var/lib/consul - एजेंट की सभी बीमारियों का इलाज। यदि कुछ आपके लिए काम नहीं करता है, तो बस अपना डेटा हटा दें और डेटा को एक कॉपी से डाउनलोड करें। सबसे अधिक संभावना है, कौंसल काम करेगा.

बीईएफडब्ल्यू

अब बात करते हैं कि हमने कॉन्सल में क्या जोड़ा है।

बीईएफडब्ल्यू का संक्षिप्त रूप है BackEndFक्रोधWसभी। जब मैंने रिपॉजिटरी बनाई तो उसमें पहला टेस्ट कमिट डालने के लिए मुझे उत्पाद का नाम किसी तरह रखना पड़ा। यही नाम रहता है.

नियम टेम्पलेट

नियम iptables सिंटैक्स में लिखे गए हैं।

• -एन बीईएफडब्ल्यू
• -पी इनपुट ड्रॉप
• -ए इनपुट -एम राज्य—राज्य संबंधित, स्थापित -जे स्वीकार
• -एक इनपुट-आई लो-जे स्वीकार करें
• -ए इनपुट -जे बीईएफडब्ल्यू

सिवाय इसके कि सब कुछ BEFW श्रृंखला में चला जाता है ESTABLISHED, RELATED और लोकलहोस्ट. टेम्प्लेट कुछ भी हो सकता है, यह तो सिर्फ एक उदाहरण है.

BEFW कैसे उपयोगी है?

सेवाएं

हमारे पास एक सेवा है, इसमें हमेशा एक पोर्ट, एक नोड होता है जिस पर यह चलता है। हमारे नोड से, हम स्थानीय रूप से एजेंट से पूछ सकते हैं और पता लगा सकते हैं कि हमारे पास किसी प्रकार की सेवा है। आप टैग भी लगा सकते हैं.

कोई भी सेवा जो चल रही है और कॉन्सल के साथ पंजीकृत है, एक iptables नियम में बदल जाती है। हमारे पास SSH - ओपन पोर्ट 22 है। बैश स्क्रिप्ट सरल है: कर्ल और iptables, और कुछ की आवश्यकता नहीं है।

ग्राहक

हर किसी के लिए नहीं, बल्कि चुनिंदा तरीके से पहुंच कैसे खोलें? सेवा नाम से केवी भंडारण में आईपी सूचियाँ जोड़ें।

उदाहरण के लिए, हम चाहते हैं कि दसवें नेटवर्क पर हर कोई SSH_TCP_22 सेवा तक पहुंच सके। एक छोटा टीटीएल फ़ील्ड जोड़ें? और अब हमारे पास अस्थायी परमिट हैं, उदाहरण के लिए, एक दिन के लिए।

पहुंच

हम सेवाओं और ग्राहकों को जोड़ते हैं: हमारे पास एक सेवा है, केवी स्टोरेज प्रत्येक के लिए तैयार है। अब हम हर किसी को नहीं, बल्कि चुनिंदा तरीके से एक्सेस देते हैं।'

समूह

अगर हम हर बार एक्सेस के लिए हजारों आईपी लिखेंगे तो हम थक जाएंगे। आइए ग्रुपिंग के साथ आएं - केवी में एक अलग उपसमुच्चय। आइए इसे उपनाम (या समूह) कहें और समूहों को उसी सिद्धांत के अनुसार संग्रहीत करें।

आइए जुड़ें: अब हम SSH को विशेष रूप से P2P के लिए नहीं, बल्कि पूरे समूह या कई समूहों के लिए खोल सकते हैं। उसी तरह, टीटीएल है - आप किसी समूह में जोड़ सकते हैं और अस्थायी रूप से समूह से हटा सकते हैं।

एकीकरण

हमारी समस्या मानवीय कारक और स्वचालन है। अब तक हमने इसे इस तरह से हल किया है।

हम पपेट के साथ काम करते हैं, और सिस्टम (एप्लिकेशन कोड) से संबंधित हर चीज उन्हें स्थानांतरित करते हैं। Puppetdb (नियमित PostgreSQL) वहां चल रही सेवाओं की एक सूची संग्रहीत करता है, उन्हें संसाधन प्रकार द्वारा पाया जा सकता है। वहां आप पता लगा सकते हैं कि कौन कहां आवेदन कर रहा है. इसके लिए हमारे पास पुल रिक्वेस्ट और मर्ज रिक्वेस्ट सिस्टम भी है।

हमने befw-sync लिखा, एक सरल समाधान जो डेटा स्थानांतरित करने में मदद करता है। सबसे पहले, सिंक कुकीज़ को puppetdb द्वारा एक्सेस किया जाता है। एक HTTP API वहां कॉन्फ़िगर किया गया है: हम अनुरोध करते हैं कि हमारे पास कौन सी सेवाएं हैं, क्या करने की आवश्यकता है। फिर वे कौंसल से अनुरोध करते हैं।

क्या कोई एकीकरण है? हाँ: उन्होंने नियम लिखे और पुल अनुरोधों को स्वीकार करने की अनुमति दी। क्या आपको किसी निश्चित पोर्ट की आवश्यकता है या किसी समूह में होस्ट जोड़ने की आवश्यकता है? अनुरोध खींचें, समीक्षा करें - अब और नहीं "200 अन्य एसीएल ढूंढें और इसके बारे में कुछ करने का प्रयास करें।"

इष्टतमीकरण

खाली नियम श्रृंखला के साथ लोकलहोस्ट को पिंग करने में 0,075 एमएस लगते हैं।

आइए इस श्रृंखला में 10 iptables पते जोड़ें। परिणामस्वरूप, पिंग 000 गुना बढ़ जाएगी: iptables पूरी तरह से रैखिक है, प्रत्येक पते को संसाधित करने में कुछ समय लगता है।

फ़ायरवॉल के लिए जहां हम हजारों एसीएल स्थानांतरित करते हैं, हमारे पास बहुत सारे नियम हैं, और यह विलंबता का परिचय देता है। यह गेमिंग प्रोटोकॉल के लिए ख़राब है.

लेकिन अगर हम डालते हैं आईपीसेट में 10 पते पिंग और भी कम हो जाएगी.

मुद्दा यह है कि आईपीसेट के लिए "ओ" (एल्गोरिदम जटिलता) हमेशा 1 के बराबर होता है, चाहे कितने भी नियम हों। सच है, एक सीमा है - 65535 से अधिक नियम नहीं हो सकते। अभी हम इसके साथ जी रहे हैं: आप उन्हें जोड़ सकते हैं, उनका विस्तार कर सकते हैं, एक में दो आईपीसेट बना सकते हैं।

सुरक्षित रखने के

पुनरावृत्ति प्रक्रिया की एक तार्किक निरंतरता ipset में सेवा के लिए ग्राहकों के बारे में जानकारी संग्रहीत करना है।

अब हमारे पास एक ही एसएसएच है, और हम एक बार में 100 आईपी नहीं लिखते हैं, लेकिन उस आईपीसेट का नाम सेट करते हैं जिसके साथ हमें संवाद करने की आवश्यकता है, और निम्नलिखित नियम DROP. इसे एक नियम "यहां कौन नहीं है, छोड़ें" में बदला जा सकता है, लेकिन यह अधिक स्पष्ट है।

अब हमारे पास नियम और सेट हैं। मुख्य कार्य नियम लिखने से पहले एक सेट बनाना है, क्योंकि अन्यथा iptables नियम नहीं लिखेंगे।

सामान्य योजना

एक रेखाचित्र के रूप में, मैंने जो कुछ भी कहा वह इस प्रकार दिखता है।

हम पपेट के लिए प्रतिबद्ध हैं, सब कुछ मेजबान को भेजा जाता है, सेवाएं यहां, आईपीसेट वहां, और जो कोई भी वहां पंजीकृत नहीं है उसे अनुमति नहीं है।

अनुमति दें इनकार करें

दुनिया को तुरंत बचाने या किसी को तुरंत अक्षम करने के लिए, सभी श्रृंखलाओं की शुरुआत में हमने दो आईपीसेट बनाए: rules_allow и rules_deny. यह काम किस प्रकार करता है?

उदाहरण के लिए, कोई हमारे वेब पर बॉट्स की मदद से लोड बना रहा है। पहले, आपको लॉग से उसका आईपी ढूंढना होता था, उसे नेटवर्क इंजीनियरों के पास ले जाना होता था, ताकि वे ट्रैफ़िक के स्रोत का पता लगा सकें और उस पर प्रतिबंध लगा सकें। यह अब अलग दिखता है.

हम इसे कौंसल को भेजते हैं, 2,5 सेकंड प्रतीक्षा करते हैं, और यह हो गया। चूंकि कॉन्सल पी2पी के माध्यम से तेजी से वितरण करता है, यह दुनिया के किसी भी हिस्से में, हर जगह काम करता है।

एक बार मैंने फ़ायरवॉल में गलती के कारण किसी तरह WOT को पूरी तरह से बंद कर दिया। rules_allow - ऐसे मामलों के खिलाफ यह हमारा बीमा है। यदि हमने फ़ायरवॉल के साथ कहीं कोई गलती की है, कहीं कुछ अवरुद्ध है, तो हम हमेशा एक सशर्त भेज सकते हैं 0.0/0सब कुछ जल्दी से उठा लेना। बाद में हम सब कुछ हाथ से ठीक कर देंगे.

अन्य सेट

आप अंतरिक्ष में कोई अन्य सेट जोड़ सकते हैं $IPSETS$.

किस लिए? कभी-कभी किसी को आईपीसेट की आवश्यकता होती है, उदाहरण के लिए, क्लस्टर के कुछ हिस्से के शटडाउन का अनुकरण करने के लिए। कोई भी कोई भी सेट ला सकता है, उनका नाम बता सकता है और उन्हें कौंसल से लिया जाएगा। उसी समय, सेट या तो iptables नियमों में भाग ले सकते हैं या एक टीम के रूप में कार्य कर सकते हैं NOOP: डेमॉन द्वारा संगति बनाए रखी जाएगी।

सदस्य

पहले, यह इस तरह था: उपयोगकर्ता नेटवर्क से जुड़ा था और डोमेन के माध्यम से पैरामीटर प्राप्त करता था। नई पीढ़ी के फ़ायरवॉल के आगमन से पहले, सिस्को को यह नहीं पता था कि यह कैसे समझा जाए कि उपयोगकर्ता कहाँ है और आईपी कहाँ है। इसलिए, मशीन के होस्टनाम के माध्यम से ही पहुंच प्रदान की गई थी।

हमने क्या किया? पता मिलते ही हम फंस गए। आमतौर पर यह dot1x, वाई-फ़ाई या VPN है - सब कुछ RADIUS के माध्यम से होता है। प्रत्येक उपयोगकर्ता के लिए, हम उपयोगकर्ता नाम से एक समूह बनाते हैं और उसमें एक टीटीएल के साथ एक आईपी डालते हैं जो उसके dhcp.lease के बराबर होता है - जैसे ही यह समाप्त होता है, नियम गायब हो जाएगा।

अब हम अन्य समूहों की तरह उपयोगकर्ता नाम से सेवाओं तक पहुंच खोल सकते हैं। हमने होस्टनाम बदलने पर होने वाली परेशानी को दूर कर दिया है, और हमने नेटवर्क इंजीनियरों पर से बोझ हटा दिया है क्योंकि उन्हें अब सिस्को की आवश्यकता नहीं है। अब इंजीनियर स्वयं अपने सर्वर पर पहुंच दर्ज करते हैं।

इन्सुलेशन

उसी समय, हमने इन्सुलेशन को नष्ट करना शुरू कर दिया। सेवा प्रबंधकों ने एक सूची ली और हमने अपने सभी नेटवर्क का विश्लेषण किया। आइए उन्हें समान समूहों में विभाजित करें, और आवश्यक सर्वर पर समूहों को जोड़ा गया, उदाहरण के लिए, इनकार करने के लिए। अब वही स्टेजिंग अलगाव उत्पादन के नियमों_अस्वीकार में समाप्त होता है, लेकिन उत्पादन में ही नहीं।

योजना तेजी से और सरलता से काम करती है: हम सर्वर से सभी एसीएल हटाते हैं, हार्डवेयर अनलोड करते हैं और पृथक वीएलएएन की संख्या कम करते हैं।

अखंडता नियंत्रण

पहले, हमारे पास एक विशेष ट्रिगर था जो तब रिपोर्ट करता था जब कोई फ़ायरवॉल नियम को मैन्युअल रूप से बदलता था। मैं फ़ायरवॉल नियमों की जाँच के लिए एक विशाल लिंटर लिख रहा था, यह कठिन था। सत्यनिष्ठा को अब BEFW द्वारा नियंत्रित किया जाता है। वह उत्साहपूर्वक यह सुनिश्चित करता है कि उसके द्वारा बनाए गए नियम न बदलें। यदि कोई फ़ायरवॉल नियम बदलता है, तो यह सब कुछ वापस बदल देगा। "मैंने तुरंत एक प्रॉक्सी स्थापित की ताकि मैं घर से काम कर सकूं" - ऐसे कोई और विकल्प नहीं हैं।

BEFW सेवाओं से ipset को नियंत्रित करता है और befw.conf में सूचीबद्ध करता है, BEFW श्रृंखला में सेवाओं के नियम। लेकिन यह अन्य श्रृंखलाओं और नियमों और अन्य आईपीसेट्स की निगरानी नहीं करता है।

दुर्घटना सुरक्षा

BEFW हमेशा अंतिम ज्ञात अच्छी स्थिति को सीधे state.bin बाइनरी संरचना में संग्रहीत करता है। यदि कुछ गलत होता है, तो यह हमेशा इस state.bin पर वापस आ जाता है।

यह अस्थिर कॉन्सल ऑपरेशन के खिलाफ बीमा है, जब उसने डेटा नहीं भेजा या किसी ने गलती की और ऐसे नियमों का इस्तेमाल किया जिन्हें लागू नहीं किया जा सकता। यह सुनिश्चित करने के लिए कि हम फ़ायरवॉल के बिना न रहें, यदि किसी भी स्तर पर कोई त्रुटि होती है तो BEFW नवीनतम स्थिति में वापस आ जाएगा।

गंभीर परिस्थितियों में, यह एक गारंटी है कि हमारे पास एक कार्यशील फ़ायरवॉल बचा रहेगा। हम सभी ग्रे नेटवर्क इस उम्मीद में खोलते हैं कि एडमिन आकर इसे ठीक कर देगा। किसी दिन मैं इसे कॉन्फ़िगरेशन में डालूंगा, लेकिन अब हमारे पास केवल तीन ग्रे नेटवर्क हैं: 10/8, 172/12 और 192.168/16। हमारे कौंसल के भीतर, यह एक महत्वपूर्ण विशेषता है जो हमें आगे विकसित होने में मदद करती है।

डेमो: रिपोर्ट के दौरान, इवान BEFW के डेमो मोड का प्रदर्शन करता है। प्रदर्शन देखना आसान है वीडियो. डेमो स्रोत कोड उपलब्ध है गीथहब पर.

नुकसान

मैं आपको उन बगों के बारे में बताऊंगा जिनका हमें सामना करना पड़ा।

आईपीसेट ऐड सेट 0.0.0.0/0। यदि आप ipset में 0.0.0.0/0 जोड़ते हैं तो क्या होता है? क्या सभी आईपी जोड़े जाएंगे? क्या इंटरनेट की सुविधा उपलब्ध होगी?

नहीं, हमें एक बग मिलेगा जिसके कारण हमें दो घंटे का डाउनटाइम खर्च करना पड़ेगा। इसके अलावा, बग 2016 से काम नहीं कर रहा है, यह RedHat Bugzilla में #1297092 नंबर के तहत स्थित है, और हमें यह दुर्घटनावश मिला - एक डेवलपर की रिपोर्ट से।

अब BEFW में यह एक सख्त नियम है 0.0.0.0/0 दो पतों में बदल जाता है: 0.0.0.0/1 и 128.0.0.0/1.

आईपीसेट पुनर्स्थापना सेट <फ़ाइल। जब आप इसे बताते हैं तो ipset क्या करता है? restore? क्या आपको लगता है कि यह iptables के समान ही काम करता है? क्या यह डेटा पुनर्प्राप्त करेगा?

ऐसा कुछ नहीं है - यह एक विलय करता है, और पुराने पते कहीं नहीं जाते हैं, आप पहुंच को अवरुद्ध नहीं करते हैं।

आइसोलेशन का परीक्षण करते समय हमें एक बग मिला। अब इसके बजाय एक जटिल प्रणाली है restore आयोजित create temp, तब restore flush temp и restore temp. स्वैप के अंत में: परमाणुता के लिए, क्योंकि यदि आप इसे पहले करते हैं flush और इसी समय कोई पैकेट आ जाएगा, उसे फेंक दिया जाएगा और कुछ गलत हो जाएगा। तो वहाँ थोड़ा सा काला जादू है।

कौंसल केवी को -डेटासेंटर=अन्य मिलता है। जैसा कि मैंने कहा, हमें लगता है कि हम कुछ डेटा मांग रहे हैं, लेकिन हमें या तो डेटा मिलेगा या कोई त्रुटि। हम इसे कौंसल के माध्यम से स्थानीय स्तर पर कर सकते हैं, लेकिन इस मामले में दोनों रुक जाएंगे।

स्थानीय कॉन्सल क्लाइंट HTTP एपीआई पर एक आवरण है। लेकिन यह बस लटका रहता है और केवल Ctrl+C, या Ctrl+Z, या किसी भी चीज़ पर प्रतिक्रिया नहीं देता है kill -9 अगले कंसोल में. जब हम एक बड़ा क्लस्टर बना रहे थे तो हमें इसका सामना करना पड़ा। लेकिन हमारे पास अभी तक कोई समाधान नहीं है; हम कौंसल में इस त्रुटि को ठीक करने की तैयारी कर रहे हैं।

कौंसल नेता जवाब नहीं दे रहे हैं. डेटा सेंटर में हमारा मास्टर जवाब नहीं दे रहा है, हम सोचते हैं: "शायद पुनर्चयन एल्गोरिथ्म अब काम करेगा?"

नहीं, यह काम नहीं करेगा, और निगरानी कुछ भी नहीं दिखाएगी: कौंसल कहेगा कि एक प्रतिबद्धता सूचकांक है, एक नेता मिल गया है, सब कुछ ठीक है।

हम इससे कैसे निपटें? service consul restart क्रॉन में हर घंटे. यदि आपके पास 50 सर्वर हैं, तो कोई बड़ी बात नहीं। जब उनमें से 16 हो जाएंगे, तो आप समझ जाएंगे कि यह कैसे काम करता है।

निष्कर्ष

परिणामस्वरूप, हमें निम्नलिखित लाभ प्राप्त हुए:

• सभी लिनक्स मशीनों का 100% कवरेज।
• स्पीड।
• स्वचालन।
• हमने हार्डवेयर और नेटवर्क इंजीनियरों को गुलामी से मुक्त कराया।
• एकीकरण की संभावनाएं सामने आई हैं जो लगभग असीमित हैं: कुबेरनेट्स के साथ भी, एन्सिबल के साथ भी, पायथन के साथ भी।

विपक्ष: कौंसल, जिसके साथ अब हमें रहना है, और त्रुटि की बहुत ऊंची कीमत। उदाहरण के तौर पर, एक बार शाम 6 बजे (रूस में प्राइम टाइम) मैं नेटवर्क की सूचियों में कुछ संपादित कर रहा था। हम उस समय BEFW में इन्सुलेशन का निर्माण कर रहे थे। मैंने कहीं न कहीं गलती की है, ऐसा लगता है कि मैंने गलत मास्क का संकेत दिया है, लेकिन दो सेकंड में सब कुछ गिर गया। मॉनिटरिंग लाइट जलती है, ड्यूटी पर मौजूद सहायक व्यक्ति दौड़ता हुआ आता है: "हमारे पास सब कुछ है!" जब विभाग के प्रमुख ने व्यवसाय को समझाया कि ऐसा क्यों हुआ तो उनका चेहरा उदास हो गया।

त्रुटि की कीमत इतनी अधिक है कि हम अपनी स्वयं की जटिल रोकथाम प्रक्रिया लेकर आए हैं। यदि आप इसे किसी बड़ी उत्पादन साइट पर लागू करते हैं, तो आपको हर किसी को कंसल पर मास्टर टोकन देने की आवश्यकता नहीं है। इसका अंत बुरा होगा.

लागत। मैंने अकेले 400 घंटों तक कोड लिखा। मेरी 4 लोगों की टीम हर किसी की सहायता के लिए महीने में 10 घंटे बिताती है। किसी भी नई पीढ़ी के फ़ायरवॉल की कीमत की तुलना में, यह मुफ़्त है।

योजनाएं। दीर्घकालिक योजना कांसुल को बदलने या पूरक करने के लिए वैकल्पिक परिवहन ढूंढना है। शायद यह काफ्का या ऐसा ही कुछ होगा. लेकिन आने वाले वर्षों में हम कौंसल पर रहेंगे।

तत्काल योजनाएँ: Fail2ban के साथ एकीकरण, निगरानी के साथ, nftables के साथ, संभवतः अन्य वितरण, मेट्रिक्स, उन्नत निगरानी, ​​अनुकूलन के साथ। कुबेरनेट्स का समर्थन भी कहीं न कहीं योजनाओं में है, क्योंकि अब हमारे पास कई क्लस्टर और इच्छाएं हैं।

योजनाओं से अधिक:

• यातायात में विसंगतियों की खोज करें;
• नेटवर्क मानचित्र प्रबंधन;
• कुबेरनेट्स समर्थन;
• सभी प्रणालियों के लिए पैकेजों का संयोजन;
• वेब-यूआई.

हम कॉन्फ़िगरेशन के विस्तार, मेट्रिक्स और अनुकूलन को बढ़ाने पर लगातार काम कर रहे हैं।

प्रोजेक्ट से जुड़ें. यह प्रोजेक्ट बढ़िया निकला, लेकिन, दुर्भाग्य से, यह अभी भी एक-व्यक्ति का प्रोजेक्ट है। के लिए आते हैं GitHub और कुछ करने का प्रयास करें: प्रतिबद्ध हों, परीक्षण करें, कुछ सुझाव दें, अपना मूल्यांकन दें।

इस बीच हम तैयारी कर रहे हैं सेंट हाईलोड++, जो 6 और 7 अप्रैल को सेंट पीटर्सबर्ग में होगा, और हम हाई-लोड सिस्टम के डेवलपर्स को आमंत्रित करते हैं एक रिपोर्ट के लिए आवेदन करें. अनुभवी वक्ता पहले से ही जानते हैं कि क्या करना है, लेकिन कम से कम उन लोगों के लिए जो बोलने में नए हैं, हम अनुशंसा करते हैं प्रयास करना. एक वक्ता के रूप में सम्मेलन में भाग लेने के कई फायदे हैं। उदाहरण के लिए, आप अंत में पढ़ सकते हैं कि कौन से हैं इस लेख का.

स्रोत: www.habr.com