Consul + iptables = :3

2010 मध्ये कंपनी वार्मिंग तेथे 50 सर्व्हर आणि एक साधे नेटवर्क मॉडेल होते: बॅकएंड, फ्रंटएंड आणि फायरवॉल. सर्व्हरची संख्या वाढली, मॉडेल अधिक गुंतागुंतीचे झाले: स्टेजिंग, ACL सह पृथक VLAN, नंतर VRF सह VPN, L2 वर ACL असलेले VLAN, L3 वर ACL असलेले VRF. डोके फिरत आहे? नंतर अधिक मजा येईल.

जेव्हा 16 सर्व्हर होते, तेव्हा अनेक विषम विभागांसह अश्रूंशिवाय काम करणे अशक्य झाले. म्हणून आम्ही दुसरा उपाय शोधून काढला. आम्ही नेटफिल्टर स्टॅक घेतला, त्यात डेटा स्रोत म्हणून सल्लागार जोडला आणि आम्हाला एक जलद वितरित फायरवॉल मिळाला. त्यांनी राउटरवर ACL बदलले आणि त्यांचा बाह्य आणि अंतर्गत फायरवॉल म्हणून वापर केला. साधन डायनॅमिकली व्यवस्थापित करण्यासाठी, आम्ही BEFW प्रणाली विकसित केली, जी सर्वत्र वापरली जात होती: उत्पादन नेटवर्कमध्ये वापरकर्त्याचा प्रवेश व्यवस्थापित करण्यापासून नेटवर्क विभागांना एकमेकांपासून वेगळे करणे.

हे सर्व कसे कार्य करते आणि आपण या प्रणालीकडे बारकाईने का लक्ष द्यावे हे तो तुम्हाला सांगेल. इव्हान अगारकोव्ह (annmuor) हे कंपनीच्या मिन्स्क डेव्हलपमेंट सेंटरमधील देखभाल विभागाच्या पायाभूत सुविधा सुरक्षा गटाचे प्रमुख आहेत. इव्हान एक SELinux चाहता आहे, त्याला पर्ल आवडतो आणि कोड लिहितो. माहिती सुरक्षा गटाचे प्रमुख म्हणून, तो हॅकर्सपासून वॉरगेमिंगचे संरक्षण करण्यासाठी आणि कंपनीमधील सर्व गेम सर्व्हरचे ऑपरेशन सुनिश्चित करण्यासाठी लॉग, बॅकअप आणि R&D सह नियमितपणे कार्य करतो.

ऐतिहासिक पार्श्वभूमी

आम्ही ते कसे केले हे मी तुम्हाला सांगण्यापूर्वी, आम्ही तुम्हाला प्रथम स्थानावर कसे आलो आणि त्याची आवश्यकता का होती ते सांगेन. हे करण्यासाठी, 9 वर्षे मागे जाऊया: 2010, वर्ल्ड ऑफ टँक्स नुकतेच दिसू लागले. वॉरगेमिंगमध्ये अंदाजे 50 सर्व्हर होते.

कंपनी सर्व्हर वाढ चार्ट.

आमच्याकडे नेटवर्क मॉडेल होते. त्या काळासाठी ते इष्टतम होते.

2010 मध्ये नेटवर्क मॉडेल.

समोरच्या टोकावर वाईट लोक आहेत ज्यांना आम्हाला तोडायचे आहे, परंतु त्यात फायरवॉल आहे. बॅकएंडवर कोणतीही फायरवॉल नाही, परंतु तेथे 50 सर्व्हर आहेत, आम्हाला ते सर्व माहित आहेत. सर्व काही चांगले कार्य करते.

4 वर्षांत, सर्व्हर फ्लीट 100 पटीने वाढून 5000 पर्यंत पोहोचले. पहिले वेगळे नेटवर्क दिसू लागले - स्टेजिंग: ते उत्पादनात जाऊ शकले नाहीत आणि तेथे अनेकदा अशा गोष्टी चालू होत्या ज्या धोकादायक असू शकतात.

2014 मध्ये नेटवर्क मॉडेल.

जडत्वानुसार, आम्ही हार्डवेअरचे समान तुकडे वापरले, आणि सर्व काम वेगळ्या VLAN वर केले गेले: ACL VLAN ला लिहिलेले आहेत, जे काही प्रकारच्या कनेक्शनला परवानगी देतात किंवा नाकारतात.

2016 मध्ये, सर्व्हरची संख्या 8000 वर पोहोचली. वॉरगेमिंगने इतर स्टुडिओ शोषले आणि अतिरिक्त संलग्न नेटवर्क दिसू लागले. ते आमचे आहेत असे दिसते, परंतु फारसे नाही: VLAN सहसा भागीदारांसाठी कार्य करत नाही, तुम्हाला VRF सह VPN वापरावे लागते, अलगाव अधिक क्लिष्ट होतो. ACL इन्सुलेशन मिश्रण वाढले.

2016 मध्ये नेटवर्क मॉडेल.

2018 च्या सुरूवातीस, मशीन्सचा ताफा 16 पर्यंत वाढला होता. तेथे 000 विभाग होते आणि आम्ही उर्वरित मोजले नाही, ज्यामध्ये आर्थिक डेटा संग्रहित केला गेला होता. कंटेनर नेटवर्क (कुबर्नेट्स), DevOps, VPN द्वारे कनेक्ट केलेले क्लाउड नेटवर्क, उदाहरणार्थ, IVS वरून, दिसू लागले आहेत. बरेच नियम होते - ते वेदनादायक होते.

2018 मध्ये नेटवर्क मॉडेल आणि अलगाव पद्धती.

आयसोलेशनसाठी आम्ही वापरले: L2 वर ACL सह VLAN, L3 वर ACL सह VRF, VPN आणि बरेच काही. खूप जास्त.

समस्या

प्रत्येकजण ACL आणि VLAN सह राहतो. काय चूक आहे? वेदना लपवत या प्रश्नाचे उत्तर हॅरोल्ड देईल.

अनेक समस्या होत्या, पण पाच मोठ्या होत्या.

• नवीन नियमांसाठी भौमितीय किंमत वाढ. प्रत्येक नवीन नियमाला आधीच्या नियमापेक्षा जोडण्यासाठी जास्त वेळ लागला, कारण आधीपासून असा नियम आहे का हे पाहणे आवश्यक होते.
• विभागांमध्ये फायरवॉल नाही. सेगमेंट कसे तरी एकमेकांपासून वेगळे केले गेले होते आणि आत आधीच पुरेशी संसाधने नव्हती.
• नियम बरेच दिवस लागू होते. ऑपरेटर एका तासात एक स्थानिक नियम हाताने लिहू शकतात. जागतिक एकाला अनेक दिवस लागले.
• ऑडिटिंग नियमांमध्ये अडचणी. अधिक स्पष्टपणे, ते शक्य नव्हते. पहिले नियम 2010 मध्ये परत लिहिले गेले होते आणि त्यांचे बहुतेक लेखक यापुढे कंपनीसाठी काम करत नाहीत.
• पायाभूत सुविधा नियंत्रणाची निम्न पातळी. ही मुख्य समस्या आहे - आपल्या देशात काय चालले आहे हे आम्हाला चांगले माहित नव्हते.

2018 मध्ये नेटवर्क अभियंता असे दिसले जेव्हा त्याने ऐकले: “काही ACL हवे आहे.”

उपाय

2018 च्या सुरुवातीला याबाबत काहीतरी करायचे ठरवले होते.

एकत्रीकरणाची किंमत सतत वाढत आहे. सुरुवातीचा मुद्दा असा होता की मोठ्या डेटा केंद्रांनी वेगळ्या VLAN आणि ACL ला समर्थन देणे बंद केले कारण डिव्हाइसेसची मेमरी संपली.

उपाय: आम्ही मानवी घटक काढून टाकला आणि जास्तीत जास्त प्रवेशाची तरतूद स्वयंचलित केली.

नवीन नियम लागू होण्यास बराच वेळ लागतो. उपाय: नियमांच्या वापरास गती द्या, ते वितरित आणि समांतर करा. यासाठी वितरीत प्रणाली आवश्यक आहे जेणेकरुन नियम स्वतःच वितरीत केले जातील, rsync किंवा SFTP शिवाय हजार सिस्टमला.

विभागांमध्ये फायरवॉल नाही. एकाच नेटवर्कमध्ये वेगवेगळ्या सेवा दिसू लागल्यावर विभागांमधील फायरवॉल आमच्याकडे येऊ लागला. उपाय: होस्ट स्तरावर फायरवॉल वापरा - होस्ट-आधारित फायरवॉल. जवळजवळ सर्वत्र आमच्याकडे लिनक्स आहे आणि सर्वत्र आमच्याकडे iptables आहेत, ही समस्या नाही.

ऑडिटिंग नियमांमध्ये अडचणी. उपाय: पुनरावलोकन आणि व्यवस्थापनासाठी सर्व नियम एकाच ठिकाणी ठेवा, जेणेकरून आम्ही प्रत्येक गोष्टीचे ऑडिट करू शकतो.

पायाभूत सुविधांवर नियंत्रणाची कमी पातळी. उपाय: सर्व सेवांची यादी घ्या आणि त्यामधील प्रवेश.

ही तांत्रिक प्रक्रियेपेक्षा प्रशासकीय प्रक्रिया आहे. काहीवेळा आमच्याकडे आठवड्यातून 200-300 नवीन रिलीझ असतात, विशेषत: जाहिराती आणि सुट्टीच्या वेळी. शिवाय, हे फक्त आमच्या DevOps च्या एका टीमसाठी आहे. बर्‍याच प्रकाशनांसह, कोणते पोर्ट, आयपी आणि एकत्रीकरण आवश्यक आहे हे पाहणे अशक्य आहे. म्हणून, आम्हाला विशेष प्रशिक्षित सेवा व्यवस्थापकांची आवश्यकता होती ज्यांनी संघांना विचारले: "तरीही तेथे काय आहे आणि तुम्ही ते का आणले?"

आम्ही लॉन्च केलेल्या प्रत्येक गोष्टीनंतर, 2019 मध्ये नेटवर्क अभियंता यासारखे दिसू लागले.

वाणिज्य

आम्‍ही ठरवले की सेवा व्‍यवस्‍थापकांच्‍या मदतीने आम्‍हाला जे काही सापडले ते आम्ही कॉन्सुलमध्‍ये ठेवू आणि तेथून iptables नियम लिहू.

आम्ही हे कसे करायचे ठरवले?

• आम्ही सर्व सेवा, नेटवर्क आणि वापरकर्ते गोळा करू.
• त्यावर आधारित iptables नियम बनवू.
• आम्ही नियंत्रण स्वयंचलित करतो.
• ....
• नफा.

Consul हे रिमोट API नाही, ते प्रत्येक नोडवर चालू शकते आणि iptables वर लिहू शकते. जे काही उरले आहे ते म्हणजे स्वयंचलित नियंत्रणे आणणे जे अनावश्यक गोष्टी साफ करतील आणि बहुतेक समस्या सोडवल्या जातील! आम्ही जाताना बाकीचे काम करू.

कॉन्सुल का?

स्वतःला चांगले सिद्ध केले आहे. 2014-15 मध्ये, आम्ही ते Vault साठी बॅकएंड म्हणून वापरले, ज्यामध्ये आम्ही पासवर्ड साठवतो.

डेटा गमावत नाही. वापराच्या वेळी, कॉन्सुलने एका अपघातादरम्यान डेटा गमावला नाही. फायरवॉल व्यवस्थापन प्रणालीसाठी हे एक मोठे प्लस आहे.

P2P कनेक्शन बदलाच्या प्रसाराला गती देतात. P2P सह, सर्व बदल त्वरीत येतात, तास प्रतीक्षा करण्याची आवश्यकता नाही.

सोयीस्कर REST API. आम्ही Apache ZooKeeper देखील मानले, परंतु त्यात REST API नाही, म्हणून तुम्हाला क्रॅच स्थापित करावे लागतील.

की व्हॉल्ट (KV) आणि निर्देशिका (सर्व्हिस डिस्कव्हरी) दोन्ही म्हणून कार्य करते. तुम्ही एकाच वेळी सेवा, कॅटलॉग आणि डेटा सेंटर्स संचयित करू शकता. हे केवळ आपल्यासाठीच नाही तर शेजारच्या संघांसाठीही सोयीचे आहे, कारण जागतिक सेवा तयार करताना आपण मोठा विचार करतो.

Go मध्ये लिहिलेले, जो Wargaming स्टॅकचा भाग आहे. आम्हाला ही भाषा आवडते, आमच्याकडे अनेक गो डेव्हलपर आहेत.

शक्तिशाली ACL प्रणाली. कौन्सुलमध्ये, कोण काय लिहिते यावर नियंत्रण ठेवण्यासाठी तुम्ही ACL वापरू शकता. आम्ही हमी देतो की फायरवॉल नियम इतर कोणत्याही गोष्टीशी ओव्हरलॅप होणार नाहीत आणि आम्हाला यामध्ये समस्या येणार नाहीत.

पण Consul मध्ये देखील त्याचे दोष आहेत.

• तुमच्याकडे व्यवसाय आवृत्ती असल्याशिवाय डेटा सेंटरमध्ये मोजत नाही. हे केवळ फेडरेशनद्वारे मोजता येऊ शकते.
• नेटवर्क आणि सर्व्हर लोडच्या गुणवत्तेवर खूप अवलंबून आहे. नेटवर्कमध्ये काही अंतर असल्यास, उदाहरणार्थ, असमान वेग असल्यास व्यस्त सर्व्हरवर कॉन्सुल सर्व्हर म्हणून योग्यरित्या कार्य करणार नाही. हे P2P कनेक्शन आणि अद्यतन वितरण मॉडेलमुळे आहे.
• उपलब्धतेचे निरीक्षण करण्यात अडचण. कॉन्सुलच्या स्थितीत तो असे म्हणू शकतो की सर्व काही ठीक आहे, परंतु तो खूप पूर्वी मरण पावला.

आम्ही Consul वापरताना यापैकी बहुतेक समस्या सोडवल्या, म्हणूनच आम्ही ते निवडले. कंपनीकडे पर्यायी बॅकएंडची योजना आहे, परंतु आम्ही समस्यांना सामोरे जाण्यास शिकलो आहोत आणि सध्या कॉन्सुलसोबत राहत आहोत.

कॉन्सुल कसे कार्य करते

आम्ही सशर्त डेटा सेंटरमध्ये तीन ते पाच सर्व्हर स्थापित करू. एक किंवा दोन सर्व्हर काम करणार नाहीत: ते कोरम आयोजित करू शकणार नाहीत आणि डेटा जुळत नसताना कोण बरोबर आणि कोण चूक हे ठरवू शकणार नाहीत. पाचपेक्षा जास्त अर्थ नाही, उत्पादकता कमी होईल.

क्लायंट कोणत्याही क्रमाने सर्व्हरशी कनेक्ट होतात: समान एजंट, फक्त ध्वजासह server = false.

यानंतर, क्लायंटला P2P कनेक्शनची यादी मिळते आणि आपापसात कनेक्शन तयार करतात.

जागतिक स्तरावर, आम्ही अनेक डेटा सेंटर कनेक्ट करतो. ते P2P ला जोडतात आणि संवाद साधतात.

जेव्हा आम्हाला दुसर्‍या डेटा सेंटरमधून डेटा पुनर्प्राप्त करायचा असतो, तेव्हा विनंती सर्व्हरकडून सर्व्हरकडे जाते. या योजनेला म्हणतात Serf प्रोटोकॉल. Consul सारखे Serf प्रोटोकॉल, HashiCorp ने विकसित केले आहे.

कॉन्सुल बद्दल काही महत्वाचे तथ्य

कॉन्सुलकडे ते कसे कार्य करते याचे वर्णन करणारे दस्तऐवज आहेत. मी फक्त निवडक तथ्ये देईन जे जाणून घेण्यासारखे आहेत.

कॉन्सुल सर्व्हर मतदारांमधून एक मास्टर निवडतात. कॉन्सुल प्रत्येक डेटा सेंटरसाठी सर्व्हरच्या सूचीमधून एक मास्टर निवडतो आणि सर्व्हरची संख्या विचारात न घेता सर्व विनंत्या फक्त त्यावर जातात. मास्टर फ्रीझिंगमुळे पुन्हा निवडणूक होत नाही. जर मास्टर निवडला नसेल तर, विनंत्या कोणाकडूनही केल्या जात नाहीत.

तुम्हाला क्षैतिज स्केलिंग हवे आहे का? सॉरी, नाही.

दुसर्‍या डेटा सेंटरची विनंती मास्टरकडून मास्टरकडे जाते, ती कोणत्या सर्व्हरवर आली याची पर्वा न करता. निवडलेल्या मास्टरला 100% लोड प्राप्त होतो, फॉरवर्ड विनंत्यांवर लोड वगळता. डेटा सेंटरमधील सर्व सर्व्हरकडे डेटाची अद्ययावत प्रत आहे, परंतु फक्त एकच प्रतिसाद देतो.

स्केल करण्याचा एकमेव मार्ग म्हणजे क्लायंटवर स्टेल मोड सक्षम करणे.

जुन्या मोडमध्ये, तुम्ही कोरमशिवाय प्रतिसाद देऊ शकता. हा एक मोड आहे ज्यामध्ये आम्ही डेटाची सुसंगतता सोडून देतो, परंतु नेहमीपेक्षा थोडे वेगाने वाचतो आणि कोणताही सर्व्हर प्रतिसाद देतो. स्वाभाविकच, केवळ मास्टरद्वारे रेकॉर्डिंग.

कॉन्सुल डेटा केंद्रांमधील डेटा कॉपी करत नाही. जेव्हा फेडरेशन एकत्र केले जाते, तेव्हा प्रत्येक सर्व्हरकडे फक्त स्वतःचा डेटा असतो. इतरांसाठी, तो नेहमी दुसऱ्याकडे वळतो.

व्यवहाराच्या बाहेर ऑपरेशन्सच्या अणूपणाची हमी दिली जात नाही. लक्षात ठेवा की आपण एकटेच गोष्टी बदलू शकत नाही. तुम्हाला ते वेगळ्या पद्धतीने हवे असल्यास, लॉकसह व्यवहार करा.

ब्लॉकिंग ऑपरेशन्स लॉकिंगची हमी देत ​​​​नाहीत. विनंती मास्टरकडून मास्टरकडे जाते आणि थेट नाही, त्यामुळे तुम्ही ब्लॉक करता तेव्हा ब्लॉकिंग कार्य करेल याची कोणतीही हमी नाही, उदाहरणार्थ, दुसर्‍या डेटा सेंटरमध्ये.

ACL देखील प्रवेशाची हमी देत ​​नाही (अनेक प्रकरणांमध्ये). ACL कदाचित कार्य करणार नाही कारण ते एका फेडरेशन डेटा सेंटरमध्ये - ACL डेटा सेंटरमध्ये (प्राथमिक DC) संग्रहित आहे. जर डीसी तुम्हाला उत्तर देत नसेल तर ACL काम करणार नाही.

एक गोठवलेल्या मास्टरमुळे संपूर्ण महासंघ गोठवला जाईल. उदाहरणार्थ, फेडरेशनमध्ये 10 डेटा सेंटर्स आहेत आणि एकाचे नेटवर्क खराब आहे आणि एक मास्टर अयशस्वी आहे. प्रत्येकजण जो त्याच्याशी संवाद साधतो तो एका वर्तुळात अडकतो: एक विनंती आहे, त्याचे उत्तर नाही, धागा गोठतो. हे कधी होईल, हे कळायला मार्ग नाही, अवघ्या एक-दोन तासांत संपूर्ण महासंघाची पडझड होईल. आपण याबद्दल काहीही करू शकत नाही.

स्थिती, कोरम आणि निवडणुका वेगळ्या धाग्याने हाताळल्या जातात. पुन्हा निवडणूक होणार नाही, स्थिती काही दाखवणार नाही. तुम्हाला असे वाटते की तुमच्याकडे थेट सल्लागार आहे, तुम्ही विचारता, आणि काहीही होत नाही - उत्तर नाही. त्याच वेळी, स्थिती दर्शवते की सर्वकाही ठीक आहे.

आम्हाला ही समस्या आली आहे आणि ती टाळण्यासाठी डेटा केंद्रांचे विशिष्ट भाग पुन्हा तयार करावे लागले.

Consul Enterprise च्या व्यवसाय आवृत्तीमध्ये वरीलपैकी काही तोटे नाहीत. यात अनेक उपयुक्त कार्ये आहेत: मतदार निवडणे, वितरण, स्केलिंग. फक्त एक "पण" आहे - वितरित प्रणालीसाठी परवाना प्रणाली खूप महाग आहे.

लाइफ हॅकिंग: rm -rf /var/lib/consul - एजंट सर्व रोग एक बरा. तुमच्यासाठी काहीतरी काम करत नसल्यास, फक्त तुमचा डेटा हटवा आणि कॉपीमधून डेटा डाउनलोड करा. बहुधा, कॉन्सुल काम करेल.

BEFW

आता आपण Consul मध्ये काय जोडले आहे याबद्दल बोलूया.

BEFW साठी एक संक्षिप्त रूप आहे BAckEndFइरेWसर्व जेव्हा मी त्यात प्रथम चाचणी कमिट ठेवण्यासाठी भांडार तयार केले तेव्हा मला कसे तरी उत्पादनाचे नाव द्यावे लागले. हे नाव राहते.

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

नियम iptables सिंटॅक्समध्ये लिहिलेले आहेत.

• -एन BEFW
• -P इनपुट ड्रॉप
• -एक इनपुट -m राज्य-राज्य संबंधित, स्थापित -j स्वीकार
• -एक इनपुट -i lo -j स्वीकारा
• -एक इनपुट -j BEFW

सर्व काही BEFW साखळीत जाते, वगळता ESTABLISHED, RELATED आणि लोकलहोस्ट. टेम्पलेट काहीही असू शकते, हे फक्त एक उदाहरण आहे.

BEFW कसे उपयुक्त आहे?

सेवा

आमच्याकडे एक सेवा आहे, त्यात नेहमीच एक पोर्ट असतो, एक नोड असतो ज्यावर ती चालते. आमच्या नोडवरून, आम्ही स्थानिक पातळीवर एजंटला विचारू शकतो आणि आमच्याकडे काही प्रकारची सेवा आहे हे शोधू शकतो. आपण टॅग देखील लावू शकता.

Consul वर चालू असलेली आणि नोंदणीकृत असलेली कोणतीही सेवा iptables नियमात बदलते. आमच्याकडे SSH - ओपन पोर्ट 22 आहे. बॅश स्क्रिप्ट सोपी आहे: कर्ल आणि iptables, इतर कशाचीही गरज नाही.

ग्राहक

प्रत्येकासाठी नाही तर निवडकपणे प्रवेश कसा उघडायचा? सेवेच्या नावाने KV स्टोरेजमध्ये IP सूची जोडा.

उदाहरणार्थ, दहाव्या नेटवर्कवरील प्रत्येकजण SSH_TCP_22 सेवेमध्ये प्रवेश करू शकेल अशी आमची इच्छा आहे. एक लहान टीटीएल फील्ड जोडायचे? आणि आता आमच्याकडे तात्पुरते परवानग्या आहेत, उदाहरणार्थ, एका दिवसासाठी.

प्रवेश

आम्ही सेवा आणि क्लायंट कनेक्ट करतो: आमच्याकडे एक सेवा आहे, प्रत्येकासाठी केव्ही स्टोरेज तयार आहे. आता आम्ही प्रत्येकाला प्रवेश देत नाही, परंतु निवडकपणे.

गट

आम्ही प्रत्येक वेळी प्रवेशासाठी हजारो आयपी लिहिल्यास, आम्ही थकून जाऊ. चला ग्रुपिंगसह येऊ या - KV मध्ये एक वेगळा उपसंच. चला त्याला उपनाव (किंवा गट) म्हणू आणि त्याच तत्त्वानुसार तेथे गट संग्रहित करू.

चला कनेक्ट करूया: आता आपण P2P साठी नाही तर संपूर्ण गट किंवा अनेक गटांसाठी SSH उघडू शकतो. त्याच प्रकारे, TTL आहे - तुम्ही ग्रुपमध्ये अॅड करू शकता आणि ग्रुपमधून तात्पुरते काढून टाकू शकता.

एकत्रीकरण

आमची समस्या मानवी घटक आणि ऑटोमेशन आहे. आतापर्यंत आम्ही हे अशा प्रकारे सोडवले आहे.

आम्ही पपेट सोबत काम करतो आणि सिस्टीमशी (अॅप्लिकेशन कोड) संबंधित प्रत्येक गोष्ट त्यांच्याकडे हस्तांतरित करतो. Puppetdb (नियमित PostgreSQL) तेथे चालू असलेल्या सेवांची सूची संग्रहित करते, त्या संसाधन प्रकारानुसार शोधल्या जाऊ शकतात. तिथे कोण कुठे अर्ज करत आहे हे कळू शकते. यासाठी आमच्याकडे पुल रिक्वेस्ट आणि मर्ज रिक्वेस्ट सिस्टम देखील आहे.

आम्ही befw-sync लिहिले, एक सोपा उपाय जो डेटा हस्तांतरित करण्यात मदत करतो. प्रथम, सिंक कुकीज puppetdb द्वारे ऍक्सेस केल्या जातात. तेथे HTTP API कॉन्फिगर केले आहे: आम्ही विनंती करतो की आमच्याकडे कोणत्या सेवा आहेत, काय करण्याची आवश्यकता आहे. मग ते कॉन्सुलला विनंती करतात.

एकीकरण आहे का? होय: त्यांनी नियम लिहिले आणि पुल विनंत्या स्वीकारण्याची परवानगी दिली. तुम्हाला एका विशिष्ट पोर्टची आवश्यकता आहे किंवा काही गटामध्ये होस्ट जोडण्याची आवश्यकता आहे? विनंती करा, पुनरावलोकन करा - यापुढे नाही “इतर 200 ACL शोधा आणि त्याबद्दल काहीतरी करण्याचा प्रयत्न करा.”

सर्वोत्तमीकरण

रिकाम्या नियम साखळीसह लोकलहोस्टला पिंग करण्यासाठी 0,075 ms लागतात.

या साखळीत 10 iptables पत्ते जोडू. परिणामी, पिंग 000 पट वाढेल: iptables पूर्णपणे रेखीय आहे, प्रत्येक पत्त्यावर प्रक्रिया करण्यासाठी थोडा वेळ लागतो.

फायरवॉलसाठी जिथे आम्ही हजारो ACLs स्थलांतरित करतो, आमच्याकडे बरेच नियम आहेत आणि यामुळे विलंब होतो. हे गेमिंग प्रोटोकॉलसाठी वाईट आहे.

पण आम्ही ठेवले तर ipset मध्ये 10 पत्ते पिंग अगदी कमी होईल.

मुद्दा असा आहे की ipset साठी “O” (अल्गोरिदम जटिलता) नेहमी 1 च्या समान असते, कितीही नियम असले तरीही. खरे आहे, एक मर्यादा आहे - तेथे 65535 पेक्षा जास्त नियम असू शकत नाहीत. सध्या आम्ही यासह जगतो: तुम्ही त्यांना एकत्र करू शकता, त्यांचा विस्तार करू शकता, एकामध्ये दोन ipsets बनवू शकता.

साठवण

पुनरावृत्ती प्रक्रियेची तार्किक निरंतरता म्हणजे ipset मध्ये सेवेसाठी क्लायंटची माहिती संग्रहित करणे.

आता आमच्याकडे समान एसएसएच आहे आणि आम्ही एकाच वेळी 100 आयपी लिहित नाही, परंतु ज्या ipsetशी संवाद साधायचा आहे त्याचे नाव सेट करतो आणि खालील नियम DROP. हे एका नियमात रूपांतरित केले जाऊ शकते "येथे कोण नाही, ड्रॉप करा", परंतु ते अधिक स्पष्ट आहे.

आता आमच्याकडे नियम आणि संच आहेत. मुख्य कार्य म्हणजे नियम लिहिण्यापूर्वी एक संच तयार करणे, कारण अन्यथा iptables नियम लिहिणार नाहीत.

सर्वसाधारण योजना

आकृतीच्या स्वरूपात, मी जे काही बोललो ते असे दिसते.

आम्ही कठपुतळीसाठी वचनबद्ध आहोत, सर्व काही होस्टला पाठवले जाते, येथे सेवा, तेथे ipset, आणि तेथे नोंदणीकृत नसलेल्या कोणालाही परवानगी नाही.

परवानगी द्या आणि नकार द्या

जगाला त्वरीत वाचवण्यासाठी किंवा एखाद्याला त्वरीत अक्षम करण्यासाठी, सर्व साखळ्यांच्या सुरूवातीस आम्ही दोन ipsets केले: rules_allow и rules_deny. हे कसे कार्य करते?

उदाहरणार्थ, कोणीतरी आमच्या वेबवर बॉट्ससह लोड तयार करत आहे. पूर्वी, तुम्हाला लॉगमधून त्याचा आयपी शोधायचा होता, तो नेटवर्क अभियंत्यांकडे घेऊन जायचा, जेणेकरून ते रहदारीचा स्त्रोत शोधू शकतील आणि त्याच्यावर बंदी घालू शकतील. ते आता वेगळे दिसते.

आम्ही ते कॉन्सुलकडे पाठवतो, 2,5 सेकंद थांबा आणि ते पूर्ण झाले. Consul P2P द्वारे त्वरीत वितरण करत असल्याने, ते जगाच्या कोणत्याही भागात, सर्वत्र कार्य करते.

एकदा मी फायरवॉलच्या चुकीमुळे WOT पूर्णपणे थांबवले. rules_allow - अशा केसेससाठी हा आमचा विमा आहे. जर आम्ही फायरवॉलसह कुठेतरी चूक केली असेल, काहीतरी कुठेतरी अवरोधित केले असेल तर आम्ही नेहमी सशर्त पाठवू शकतो 0.0/0सर्वकाही पटकन उचलण्यासाठी. नंतर आम्ही हाताने सर्वकाही ठीक करू.

इतर संच

तुम्ही स्पेसमध्ये इतर कोणतेही सेट जोडू शकता $IPSETS$.

कशासाठी? कधीकधी एखाद्याला ipset आवश्यक असते, उदाहरणार्थ, क्लस्टरच्या काही भागाच्या शटडाउनचे अनुकरण करण्यासाठी. कोणीही कोणताही सेट आणू शकतो, त्यांना नाव देऊ शकतो आणि ते कॉन्सुलकडून घेतले जातील. त्याच वेळी, सेट एकतर iptables नियमांमध्ये सहभागी होऊ शकतात किंवा संघ म्हणून कार्य करू शकतात NOOP: डिमनद्वारे सातत्य राखले जाईल.

वापरकर्ते

पूर्वी, हे असे होते: वापरकर्त्याने नेटवर्कशी कनेक्ट केले आणि डोमेनद्वारे पॅरामीटर्स प्राप्त केले. नवीन पिढीच्या फायरवॉलच्या आगमनापूर्वी, वापरकर्ता कुठे आहे आणि IP कुठे आहे हे कसे समजून घ्यावे हे सिस्कोला माहित नव्हते. म्हणून, प्रवेश फक्त मशीनच्या होस्टनावाद्वारे मंजूर केला गेला.

आम्ही काय केले? पत्ता मिळताच आम्ही अडकलो. सहसा हे dot1x, Wi-Fi किंवा VPN असते - सर्वकाही RADIUS मधून जाते. प्रत्येक वापरकर्त्यासाठी, आम्ही वापरकर्तानावाने एक गट तयार करतो आणि त्यात त्याच्या dhcp.lease प्रमाणे TTL असलेला IP ठेवतो - तो कालबाह्य होताच, नियम नाहीसा होईल.

आता आम्ही वापरकर्तानावाने इतर गटांप्रमाणे सेवांमध्ये प्रवेश उघडू शकतो. जेव्हा होस्टनावे बदलतात तेव्हा आम्ही त्यांच्या वेदना दूर केल्या आहेत आणि आम्ही नेटवर्क अभियंत्यांकडून ओझे काढून टाकले आहे कारण त्यांना यापुढे सिस्कोची आवश्यकता नाही. आता अभियंते स्वतःच त्यांच्या सर्व्हरवर प्रवेश नोंदवतात.

इन्सुलेशन

त्याच वेळी, आम्ही इन्सुलेशन नष्ट करण्यास सुरुवात केली. सेवा व्यवस्थापकांनी एक यादी घेतली आणि आम्ही आमच्या सर्व नेटवर्कचे विश्लेषण केले. चला त्यांना समान गटांमध्ये विभाजित करूया, आणि आवश्यक सर्व्हरवर गट जोडले गेले, उदाहरणार्थ, नाकारण्यासाठी. आता तेच स्टेजिंग अलगाव उत्पादनाच्या नियमांमध्ये समाप्त होते, परंतु उत्पादनातच नाही.

योजना जलद आणि सोप्या पद्धतीने कार्य करते: आम्ही सर्व्हरवरून सर्व ACL काढून टाकतो, हार्डवेअर अनलोड करतो आणि वेगळ्या VLAN ची संख्या कमी करतो.

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

पूर्वी, आमच्याकडे एक विशेष ट्रिगर होता ज्याने कोणीतरी फायरवॉल नियम मॅन्युअली बदलल्यावर अहवाल दिला. मी फायरवॉल नियम तपासण्यासाठी एक मोठा लिंटर लिहित होतो, ते कठीण होते. अखंडता आता BEFW द्वारे नियंत्रित केली जाते. त्याने बनवलेले नियम बदलणार नाहीत याची तो आवेशाने खात्री करतो. जर कोणी फायरवॉल नियम बदलले तर ते सर्व काही बदलेल. “मी पटकन एक प्रॉक्सी सेट केली जेणेकरून मी घरून काम करू शकेन”—असे कोणतेही पर्याय नाहीत.

BEFW सेवांमधून ipset नियंत्रित करते आणि befw.conf मधील सूची, BEFW चेनमधील सेवांचे नियम. परंतु ते इतर साखळी आणि नियम आणि इतर आयपसेटचे निरीक्षण करत नाही.

क्रॅश संरक्षण

BEFW नेहमी स्टेट.बिन बायनरी स्ट्रक्चरमध्ये शेवटची ज्ञात चांगली स्थिती थेट संग्रहित करते. जर काही चूक झाली, तर ती नेहमी या state.bin वर परत येते.

हा अस्थिर कॉन्सुल ऑपरेशन विरुद्ध विमा आहे, जेव्हा त्याने डेटा पाठवला नाही किंवा कोणीतरी चूक केली आणि नियम वापरले जे लागू केले जाऊ शकत नाहीत. आम्ही फायरवॉलशिवाय राहणार नाही याची खात्री करण्यासाठी, कोणत्याही टप्प्यावर त्रुटी आढळल्यास BEFW नवीनतम स्थितीत परत येईल.

गंभीर परिस्थितींमध्ये, ही हमी आहे की आमच्याकडे कार्यरत फायरवॉल असेल. प्रशासक येईल आणि त्याचे निराकरण करेल या आशेने आम्ही सर्व ग्रे नेटवर्क उघडतो. एखाद्या दिवशी मी हे कॉन्फिगमध्ये ठेवेन, परंतु आता आमच्याकडे फक्त तीन ग्रे नेटवर्क आहेत: 10/8, 172/12 आणि 192.168/16. आमच्या कॉन्सुलमध्ये, हे एक महत्त्वाचे वैशिष्ट्य आहे जे आम्हाला आणखी विकसित करण्यात मदत करते.

डेमो: अहवालादरम्यान, इव्हान BEFW चा डेमो मोड प्रदर्शित करतो. प्रात्यक्षिक पाहणे सोपे आहे видео. डेमो स्त्रोत कोड उपलब्ध आहे GitHub वर.

तेथे उपासनेच्या

आम्हाला आढळलेल्या बगबद्दल मी तुम्हाला सांगेन.

ipset जोडा सेट 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 पुनर्संचयित सेट < फाइल. तुम्ही सांगाल तेव्हा ipset काय करते restore? तुम्हाला असे वाटते की ते iptables प्रमाणेच कार्य करते? तो डेटा पुनर्प्राप्त करेल?

असे काहीही नाही - ते विलीन होते आणि जुने पत्ते कुठेही जात नाहीत, तुम्ही प्रवेश अवरोधित करत नाही.

अलगाव चाचणी करताना आम्हाला एक बग आढळला. आता एक ऐवजी जटिल प्रणाली आहे - त्याऐवजी restore आयोजित केले जाते create tempमग restore flush temp и restore temp. स्वॅपच्या शेवटी: अणुत्वासाठी, कारण आपण ते प्रथम केले तर flush आणि या क्षणी काही पॅकेट येईल, ते टाकून दिले जाईल आणि काहीतरी चूक होईल. त्यामुळे तिथे थोडी काळी जादू आहे.

consul kv get -datacenter=other. मी म्हटल्याप्रमाणे, आम्हाला वाटते की आम्ही काही डेटा विचारत आहोत, परंतु आम्हाला एकतर डेटा मिळेल किंवा एरर मिळेल. आम्ही स्थानिक पातळीवर कॉन्सुलद्वारे हे करू शकतो, परंतु या प्रकरणात दोन्ही गोठतील.

स्थानिक कॉन्सुल क्लायंट हे HTTP API वर रॅपर आहे. परंतु ते फक्त हँग होते आणि Ctrl+C, किंवा Ctrl+Z, किंवा कशालाही प्रतिसाद देत नाही. kill -9 पुढील कन्सोलमध्ये. आम्ही एक मोठा क्लस्टर तयार करत असताना आम्हाला याचा सामना करावा लागला. परंतु आमच्याकडे अद्याप उपाय नाही; आम्ही कॉन्सुलमध्ये ही त्रुटी दूर करण्याची तयारी करत आहोत.

कॉन्सुल लीडर प्रतिसाद देत नाही. डेटा सेंटरमधील आमचे मास्टर प्रतिसाद देत नाहीत, आम्हाला वाटते: "कदाचित रिसेलेक्शन अल्गोरिदम आता कार्य करेल?"

नाही, ते कार्य करणार नाही आणि देखरेख काहीही दर्शवणार नाही: कॉन्सुल म्हणेल की एक वचनबद्धता निर्देशांक आहे, एक नेता सापडला आहे, सर्व काही ठीक आहे.

आम्ही याला कसे सामोरे जाऊ? service consul restart प्रत्येक तासाला क्रॉनमध्ये. आपल्याकडे 50 सर्व्हर असल्यास, कोणतीही मोठी गोष्ट नाही. जेव्हा त्यापैकी 16 असतील, तेव्हा ते कसे कार्य करते ते तुम्हाला समजेल.

निष्कर्ष

परिणामी, आम्हाला खालील फायदे मिळाले:

• सर्व लिनक्स मशीनचे 100% कव्हरेज.
• गती.
• ऑटोमेशन.
• आम्ही हार्डवेअर आणि नेटवर्क अभियंत्यांना गुलामगिरीतून मुक्त केले.
• एकत्रीकरणाच्या शक्यता दिसू लागल्या आहेत ज्या जवळजवळ अमर्याद आहेत: अगदी कुबरनेटसह, अगदी अॅन्सिबलसह, अगदी पायथनसह देखील.

मिनिन्स: Consul, ज्यासह आम्हाला आता राहायचे आहे, आणि त्रुटीची उच्च किंमत. उदाहरणार्थ, एकदा संध्याकाळी 6 वाजता (रशियामधील प्राइम टाइम) मी नेटवर्कच्या सूचीमध्ये काहीतरी संपादित करत होतो. आम्ही त्यावेळी BEFW मध्ये फक्त इन्सुलेशन बनवत होतो. मी कुठेतरी चूक केली आहे, असे दिसते की मी चुकीचा मुखवटा दर्शविला आहे, परंतु सर्वकाही दोन सेकंदात पडले. मॉनिटरिंग उजळते, ड्युटीवरील सहाय्यक व्यक्ती धावत येते: "आमच्याकडे सर्व काही आहे!" असे का घडले, हे व्यवसायाला समजावून सांगितल्यावर विभागप्रमुख धूसर झाले.

त्रुटीची किंमत इतकी जास्त आहे की आम्ही आमच्या स्वतःच्या जटिल प्रतिबंधक प्रक्रियेसह आलो आहोत. तुम्ही मोठ्या उत्पादन साइटवर हे अंमलात आणल्यास, तुम्हाला प्रत्येकाला कॉन्सुलवर मास्टर टोकन देण्याची गरज नाही. हे वाईटरित्या समाप्त होईल.

किंमत मी एकट्याने 400 तास कोड लिहिला. माझी 4 लोकांची टीम प्रत्येकाच्या मदतीसाठी महिन्यातून 10 तास खर्च करते. कोणत्याही नवीन पिढीच्या फायरवॉलच्या किमतीच्या तुलनेत, ते विनामूल्य आहे.

योजना. कॉन्सुल बदलण्यासाठी किंवा पूरक करण्यासाठी पर्यायी वाहतूक शोधणे ही दीर्घकालीन योजना आहे. कदाचित तो काफ्का किंवा तत्सम काहीतरी असेल. पण येत्या काही वर्षांत आम्ही कौन्सिलवर राहू.

तात्काळ योजना: Fail2ban सह एकत्रीकरण, मॉनिटरिंगसह, nftables सह, शक्यतो इतर वितरणांसह, मेट्रिक्स, प्रगत निरीक्षण, ऑप्टिमायझेशन. Kubernetes समर्थन देखील योजनांमध्ये कुठेतरी आहे, कारण आता आमच्याकडे अनेक क्लस्टर्स आणि इच्छा आहेत.

योजनांमधून अधिक:

• रहदारीतील विसंगती शोधा;
• नेटवर्क नकाशा व्यवस्थापन;
• कुबर्नेट्स समर्थन;
• सर्व प्रणालींसाठी पॅकेजेस एकत्र करणे;
• वेब-UI.

आम्ही कॉन्फिगरेशनचा विस्तार, मेट्रिक्स आणि ऑप्टिमायझेशन वाढविण्यावर सतत काम करत आहोत.

प्रकल्पात सामील व्हा. प्रकल्प छान निघाला, परंतु, दुर्दैवाने, तो अजूनही एक-व्यक्ती प्रकल्प आहे. ला ये GitHub आणि काहीतरी करण्याचा प्रयत्न करा: वचन द्या, चाचणी करा, काहीतरी सुचवा, तुमचे मूल्यांकन द्या.

दरम्यान आम्ही तयारी करत आहोत सेंट हायलोड++, जे सेंट पीटर्सबर्ग येथे 6 आणि 7 एप्रिल रोजी होणार आहे आणि आम्ही उच्च-लोड सिस्टमच्या विकासकांना आमंत्रित करतो अहवालासाठी अर्ज करा. अनुभवी स्पीकर्सना काय करावे हे आधीच माहित आहे, परंतु जे नवीन बोलत आहेत त्यांच्यासाठी आम्ही किमान शिफारस करतो प्रयत्न करणे. संमेलनात वक्ता म्हणून सहभागी होण्याचे अनेक फायदे आहेत. आपण कोणते वाचू शकता, उदाहरणार्थ, शेवटी हा लेख.

स्त्रोत: www.habr.com