कन्सुल + iptables = :3

2010 मा कम्पनी वार्मिंग त्यहाँ 50 सर्भरहरू र एक साधारण नेटवर्क मोडेल थिए: ब्याकएन्ड, फ्रन्टएन्ड र फायरवाल। सर्भरहरूको संख्या बढ्दै गयो, मोडेल थप जटिल भयो: स्टेजिङ, ACLs सँग पृथक VLANs, त्यसपछि VRFs सँग VPNs, L2 मा ACLs सँग VLAN, L3 मा ACLs सँग VRFs। टाउको घुम्छ? पछि थप रमाइलो हुनेछ।

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

यो सबै कसरी काम गर्छ र तपाईंले यस प्रणालीलाई किन नजिकबाट हेर्नुपर्छ भनेर उहाँले तपाईंलाई बताउनुहुन्छ। इवान Agarkov (annmuor) कम्पनीको मिन्स्क विकास केन्द्रमा मर्मत विभागको पूर्वाधार सुरक्षा समूहको प्रमुख हुनुहुन्छ। इभान SELinux फ्यान हो, पर्ललाई माया गर्छ र कोड लेख्छ। सूचना सुरक्षा समूहको प्रमुखको रूपमा, उसले ह्याकरहरूबाट Wargaming लाई जोगाउन र कम्पनीमा सबै गेम सर्भरहरूको सञ्चालन सुनिश्चित गर्न लग, ब्याकअप र R&D सँग नियमित रूपमा काम गर्दछ।

ऐतिहासिक पृष्ठभूमि

हामीले यो कसरी गर्यौं भनेर मैले तपाईलाई भन्नु अघि, म तपाईलाई बताउनेछु कि हामी पहिलो स्थानमा यो कसरी आयौं र यो किन आवश्यक थियो। यो गर्नको लागि, 9 वर्ष पछाडि जाऔं: 2010, ट्याङ्कहरूको संसार भर्खरै देखा पर्‍यो। Wargaming मा लगभग 50 सर्भरहरू थिए।

कम्पनी सर्भर वृद्धि चार्ट।

हामीसँग नेटवर्क मोडेल थियो। त्यो समयको लागि यो इष्टतम थियो।

2010 मा नेटवर्क मोडेल।

अगाडिको छेउमा खराब मान्छेहरू छन् जसले हामीलाई तोड्न चाहन्छन्, तर यसमा फायरवाल छ। ब्याकएन्डमा कुनै फायरवाल छैन, तर त्यहाँ 50 सर्भरहरू छन्, हामी ती सबैलाई थाहा छ। सबै कुरा राम्ररी काम गर्छ।

4 वर्षमा, सर्भर फ्लीट 100 गुणा बढेर 5000 पुग्यो। पहिलो पृथक नेटवर्कहरू देखा पर्यो - स्टेजिङ: तिनीहरू उत्पादनमा जान सकेनन्, र त्यहाँ प्राय: चीजहरू चलिरहेका थिए जुन खतरनाक हुन सक्छ।

2014 मा नेटवर्क मोडेल।

जडता द्वारा, हामीले हार्डवेयरको एउटै टुक्राहरू प्रयोग गर्यौं, र सबै काम पृथक VLANs मा गरिएको थियो: ACL हरू VLAN मा लेखिएको छ, जसले कुनै प्रकारको जडानलाई अनुमति दिन्छ वा अस्वीकार गर्दछ।

2016 मा, सर्भरहरूको संख्या 8000 पुग्यो। Wargaming ले अन्य स्टुडियोहरू अवशोषित गर्यो, र थप सम्बद्ध नेटवर्कहरू देखा पर्यो। तिनीहरू हाम्रो जस्तो देखिन्छ, तर पूर्ण रूपमा होइन: VLAN ले प्राय: साझेदारहरूको लागि काम गर्दैन, तपाईंले VRF सँग VPN प्रयोग गर्नुपर्छ, अलगाव थप जटिल हुन्छ। ACL इन्सुलेशन मिश्रण बढ्यो।

2016 मा नेटवर्क मोडेल।

2018 को सुरुमा, मेसिनहरूको फ्लीट बढेर 16 पुगेको थियो। त्यहाँ 000 खण्डहरू थिए, र हामीले वित्तीय डेटा भण्डारण गरिएका बन्द गरिएकाहरू सहित बाँकीलाई गणना गरेनौं। कन्टेनर नेटवर्कहरू (Kubernetes), DevOps, क्लाउड नेटवर्कहरू VPN मार्फत जडान भएका, उदाहरणका लागि, IVS बाट, देखा परेका छन्। त्यहाँ धेरै नियमहरू थिए - यो पीडादायी थियो।

2018 मा नेटवर्क मोडेल र अलगाव विधिहरू।

अलगावको लागि हामीले प्रयोग गर्यौं: L2 मा ACL सँग VLAN, L3 मा ACL सँग VRF, VPN र अधिक। धेरै।

समस्याहरू

सबैजना ACL र VLAN सँग बस्छन्। के गल्ति छ? यो प्रश्नको जवाफ ह्यारोल्डले दिनेछन्, पीडा लुकाएर।

त्यहाँ धेरै समस्याहरू थिए, तर त्यहाँ पाँचवटा ठूलो समस्याहरू थिए।

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

2018 मा एक नेटवर्क इन्जिनियर जस्तो देखिन्थ्यो जब उनले सुने: "केही ACL चाहिन्छ।"

समाधानहरू

2018 को सुरुमा, यो यसको बारेमा केहि गर्ने निर्णय गरियो।

एकीकरणको मूल्य निरन्तर बढिरहेको छ। सुरुवात बिन्दु यो थियो कि ठूला डाटा केन्द्रहरूले पृथक VLAN र ACLs लाई समर्थन गर्न बन्द गरे किनभने यन्त्रहरूको मेमोरी सकियो।

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

नयाँ नियम लागू हुन लामो समय लाग्छ। समाधान: नियमहरूको प्रयोगलाई गति दिनुहोस्, यसलाई वितरण र समानान्तर बनाउनुहोस्। यसको लागि एक वितरित प्रणाली चाहिन्छ ताकि नियमहरू आफैं डेलिभर हुन्छन्, बिना rsync वा SFTP हजार प्रणालीहरूमा।

खण्डहरू भित्र फायरवाल छैन। एउटै नेटवर्क भित्र विभिन्न सेवाहरू देखा पर्दा खण्डहरू भित्रको फायरवाल हामीलाई आउन थाल्यो। समाधान: होस्ट स्तरमा फायरवाल प्रयोग गर्नुहोस् - होस्ट-आधारित फायरवालहरू। लगभग सबै ठाउँमा हामीसँग लिनक्स छ, र जताततै हामीसँग iptables छ, यो कुनै समस्या होइन।

लेखापरीक्षण नियमहरूसँग कठिनाइहरू। समाधान: समीक्षा र व्यवस्थापनको लागि सबै नियमहरू एकै ठाउँमा राख्नुहोस्, ताकि हामी सबै कुरा लेखा परीक्षा गर्न सक्छौं।

पूर्वाधारमा नियन्त्रणको न्यून स्तर। समाधान: सबै सेवाहरू र तिनीहरू बीच पहुँचहरूको सूची लिनुहोस्।

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

हामीले सुरु गरेको सबै कुरा पछि, 2019 मा एक नेटवर्क इन्जिनियर यस्तो देखिन थाल्यो।

कन्सुलर

हामीले निर्णय गर्यौं कि हामीले सेवा प्रबन्धकहरूको सहयोगमा भेट्टाएका सबै कुरा कन्सुलमा राख्नेछौं र त्यहाँबाट हामीले iptables नियमहरू लेख्नेछौं।

हामीले यो कसरी गर्ने निर्णय गर्यौं?

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

कन्सुल एक रिमोट API होइन, यो हरेक नोडमा चल्न सक्छ र iptables मा लेख्न सक्छ। बाँकी सबै स्वचालित नियन्त्रणहरू संग आउनु हो जसले अनावश्यक चीजहरू सफा गर्नेछ, र धेरै जसो समस्याहरू समाधान हुनेछन्! हामी जाने क्रममा बाँकी काम गर्नेछौं।

किन कन्सुल ?

आफूलाई राम्रोसँग प्रमाणित गरेको छ । 2014-15 मा, हामीले यसलाई Vault को लागि ब्याकइन्डको रूपमा प्रयोग गर्यौं, जसमा हामी पासवर्डहरू भण्डार गर्छौं।

डाटा गुमाउँदैन। प्रयोगको समयमा, कन्सुलले एकल दुर्घटनाको समयमा डेटा गुमाएन। यो फायरवाल व्यवस्थापन प्रणाली को लागी एक ठूलो प्लस हो।

P2P जडानहरूले परिवर्तनको प्रसारलाई गति दिन्छ। P2P को साथ, सबै परिवर्तनहरू चाँडै आउँछन्, घण्टा पर्खनु पर्दैन।

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

कुञ्जी भल्ट (KV) र डाइरेक्टरी (सर्भिस डिस्कवरी) दुवैको रूपमा काम गर्दछ। तपाईं सेवाहरू, क्याटलगहरू, र डाटा केन्द्रहरू एकैचोटि भण्डारण गर्न सक्नुहुन्छ। यो हाम्रो लागि मात्र होइन, तर छिमेकी टोलीहरूको लागि पनि सुविधाजनक छ, किनभने विश्वव्यापी सेवा निर्माण गर्दा, हामी ठूलो सोच्दछौं।

Go मा लेखिएको, जुन Wargaming स्ट्याक को भाग हो। हामीलाई यो भाषा मन पर्छ, हामीसँग धेरै Go विकासकर्ताहरू छन्।

शक्तिशाली ACL प्रणाली। कन्सुलमा, कसले के लेख्छ भनेर नियन्त्रण गर्न तपाईंले ACLs प्रयोग गर्न सक्नुहुन्छ। हामी ग्यारेन्टी दिन्छौं कि फायरवाल नियमहरू अरू कुनै कुरासँग ओभरल्याप हुने छैनन् र हामीलाई यसमा समस्या हुनेछैन।

तर कन्सुलका पनि कमजोरी छन्।

• तपाईंसँग व्यापार संस्करण नभएसम्म डेटा केन्द्र भित्र मापन गर्दैन। यो महासंघ द्वारा मात्र मापन योग्य छ।
• नेटवर्क र सर्भर लोड को गुणस्तर मा धेरै निर्भर। कन्सुलले व्यस्त सर्भरमा सर्भरको रूपमा ठीकसँग काम गर्दैन यदि नेटवर्कमा कुनै ढिलाइहरू छन्, उदाहरणका लागि, असमान गति। यो P2P जडान र अद्यावधिक वितरण मोडेल को कारण हो।
• उपलब्धता अनुगमन गर्न कठिनाई। कन्सुलर स्थितिमा उहाँले भन्न सक्नुहुन्छ कि सबै ठीक छ, तर उहाँ लामो समय पहिले मरे।

हामीले कन्सुल प्रयोग गर्दा यी धेरैजसो समस्याहरू समाधान गर्यौं, त्यसैले हामीले यसलाई रोज्यौं। कम्पनीसँग वैकल्पिक ब्याकएन्डको योजना छ, तर हामीले समस्याहरू समाधान गर्न सिकेका छौं र हाल कन्सुलसँग बसिरहेका छौं।

कन्सुल कसरी काम गर्दछ

हामी सशर्त डाटा सेन्टरमा तीन देखि पाँच सर्भरहरू स्थापना गर्नेछौं। एक वा दुई सर्भरहरूले काम गर्दैनन्: तिनीहरूले कोरम व्यवस्थित गर्न र डेटा नमिल्दा को सही र को गलत हो भनेर निर्णय गर्न सक्षम हुनेछैनन्। पाँच भन्दा बढीको कुनै अर्थ छैन, उत्पादकता घट्नेछ।

ग्राहकहरू कुनै पनि क्रममा सर्भरहरूमा जडान हुन्छन्: समान एजेन्टहरू, झण्डाको साथ मात्र server = false.

यसपछि, ग्राहकहरूले P2P जडानहरूको सूची प्राप्त गर्छन् र आपसमा जडानहरू निर्माण गर्छन्।

विश्वव्यापी स्तरमा, हामी धेरै डाटा केन्द्रहरू जडान गर्छौं। तिनीहरू पनि P2P जडान र संचार।

जब हामी अर्को डाटा केन्द्रबाट डाटा पुन: प्राप्त गर्न चाहन्छौं, अनुरोध सर्भरबाट सर्भरमा जान्छ। यो योजना भनिन्छ Serf प्रोटोकल। कन्सुल जस्तै Serf प्रोटोकल, HashiCorp द्वारा विकसित गरिएको हो।

कन्सुल बारे केहि महत्त्वपूर्ण तथ्यहरू

कन्सुलसँग यसले कसरी काम गर्छ भनेर वर्णन गर्ने कागजातहरू छन्। म केवल चयन गरिएका तथ्यहरू दिनेछु जुन जान्न लायक छ।

कन्सुलर सर्भरहरूले मतदाताहरू मध्येबाट एक मास्टर छान्छन्। कन्सुलले प्रत्येक डाटा सेन्टरको लागि सर्भरहरूको सूचीबाट एक मास्टर चयन गर्दछ, र सबै अनुरोधहरू सर्भरहरूको संख्यालाई ध्यान नदिई त्यसमा मात्र जान्छन्। मास्टर फ्रिजिङले पुन: चुनावको नेतृत्व गर्दैन। यदि मास्टर चयन गरिएको छैन भने, अनुरोधहरू कसैले पनि सेवा गर्दैनन्।

के तपाइँ तेर्सो स्केलिंग चाहनुहुन्छ? माफ गर्नुहोस्, छैन।

अर्को डाटा सेन्टरको अनुरोध मास्टरबाट मास्टरमा जान्छ, यो कुन सर्भरमा आएको भएता पनि। चयन गरिएको मास्टरले फर्वार्ड अनुरोधहरूमा लोड बाहेक, लोडको 100% प्राप्त गर्दछ। डाटा सेन्टरका सबै सर्भरहरूमा डाटाको अप-टु-डेट प्रतिलिपि छ, तर एउटाले मात्र जवाफ दिन्छ।

मापन गर्ने एक मात्र तरिका ग्राहकमा बासी मोड सक्षम गर्न हो।

पुरानो मोडमा, तपाइँ बिना गणपूरक प्रतिक्रिया दिन सक्नुहुन्छ। यो एउटा मोड हो जसमा हामी डेटा स्थिरता छोड्छौं, तर सामान्य भन्दा अलि छिटो पढ्छौं, र कुनै पनि सर्भरले प्रतिक्रिया दिन्छ। स्वाभाविक रूपमा, मास्टर मार्फत मात्र रेकर्डिङ।

कन्सुलले डाटा केन्द्रहरू बीच डाटा प्रतिलिपि गर्दैन। जब एक महासंघ भेला हुन्छ, प्रत्येक सर्भरको केवल आफ्नै डाटा हुनेछ। अरूको लागि, ऊ सधैं अरू कसैलाई फर्काउँछ।

एक लेनदेन बाहिर सञ्चालनको परमाणु ग्यारेन्टी छैन। सम्झनुहोस् कि चीजहरू परिवर्तन गर्न सक्ने तपाईं मात्र हुनुहुन्न। यदि तपाइँ यसलाई फरक रूपमा चाहनुहुन्छ भने, लकको साथ लेनदेन गर्नुहोस्।

अवरुद्ध कार्यहरूले ताला लगाउने ग्यारेन्टी गर्दैन। अनुरोध मास्टरबाट मास्टरमा जान्छ, र सीधा होइन, त्यसैले त्यहाँ कुनै ग्यारेन्टी छैन कि तपाईंले ब्लक गर्दा ब्लक गर्ने काम हुनेछ, उदाहरणका लागि, अर्को डेटा केन्द्रमा।

ACL ले पहुँचको ग्यारेन्टी पनि गर्दैन (धेरै अवस्थामा)। ACL ले काम नगर्न सक्छ किनभने यो एक महासंघ डेटा केन्द्रमा भण्डार गरिएको छ - ACL डाटा केन्द्र (प्राथमिक DC) मा। यदि DC ले तपाईंलाई जवाफ दिँदैन भने, ACL ले काम गर्ने छैन।

एक जम्मा भएका मास्टरले सिंगो महासंघलाई फ्रिज गर्नेछ। उदाहरणका लागि, एउटा महासंघमा १० वटा डाटा सेन्टरहरू छन्, र एउटाको नेटवर्क खराब छ, र एउटा मास्टर फेल हुन्छ। उहाँसँग कुराकानी गर्ने सबैजना सर्कलमा अड्किनेछन्: त्यहाँ एउटा अनुरोध छ, त्यहाँ यसको कुनै जवाफ छैन, थ्रेड स्थिर हुन्छ। यो कहिले हुन्छ थाहा छैन, एक दुई घण्टामा सिंगो महासंघ ढल्छ। यसमा तपाईंले गर्न सक्ने केही छैन।

स्थिति, गणपूरक र निर्वाचनलाई छुट्टै थ्रेडद्वारा ह्यान्डल गरिन्छ। फेरि चुनाव हुँदैन, स्थितिले केही देखाउँदैन। तपाइँ सोच्नुहुन्छ कि तपाइँसँग प्रत्यक्ष कन्सुल छ, तपाइँ सोध्नुहुन्छ, र केहि हुँदैन - त्यहाँ कुनै जवाफ छैन। एकै समयमा, स्थितिले देखाउँछ कि सबै ठीक छ।

हामीले यो समस्याको सामना गर्‍यौं र यसबाट बच्न डेटा केन्द्रहरूको विशेष भागहरू पुनर्निर्माण गर्नुपर्‍यो।

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

जीवन हैकिंग: rm -rf /var/lib/consul - एजेन्ट को सबै रोगहरु को लागी एक उपचार। यदि तपाइँको लागि केहि काम गर्दैन भने, केवल तपाइँको डेटा मेटाउनुहोस् र प्रतिलिपिबाट डेटा डाउनलोड गर्नुहोस्। सम्भवतः, कन्सुलले काम गर्नेछ।

BEFW

अब हामीले कन्सुलमा के थपेका छौं भन्ने कुरा गरौं।

BEFW को संक्षिप्त रूप हो BAckEndFआइरWसबै। मैले पहिलो परीक्षण कमिटहरू राख्नको लागि भण्डार सिर्जना गर्दा मैले कुनै न कुनै रूपमा उत्पादनको नाम दिनुपर्‍यो। यो नाम बाँकी छ।

नियम टेम्प्लेटहरू

नियमहरू iptables सिन्ट्याक्समा लेखिएका छन्।

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

सबै कुरा BEFW श्रृंखलामा जान्छ, बाहेक ESTABLISHED, RELATED र localhost। टेम्प्लेट जे पनि हुन सक्छ, यो केवल एक उदाहरण हो।

BEFW कसरी उपयोगी छ?

सेवाहरू

हामीसँग सेवा छ, यसमा सधैं पोर्ट हुन्छ, नोड जसमा यो चल्छ। हाम्रो नोडबाट, हामी स्थानीय रूपमा एजेन्टलाई सोध्न सक्छौं र पत्ता लगाउन सक्छौं कि हामीसँग कुनै प्रकारको सेवा छ। तपाईं पनि ट्याग राख्न सक्नुहुन्छ।

कन्सुलसँग चलिरहेको र दर्ता भएको कुनै पनि सेवा iptables नियममा परिणत हुन्छ। हामीसँग SSH - खुला पोर्ट 22 छ। Bash स्क्रिप्ट सरल छ: कर्ल र iptables, अरू केहि आवश्यक छैन।

ग्राहकहरू

कसरी सबैको लागि पहुँच खोल्ने, तर छनौट रूपमा? सेवा नामद्वारा KV भण्डारणमा IP सूचीहरू थप्नुहोस्।

उदाहरणका लागि, हामी दसौं नेटवर्कमा सबैले SSH_TCP_22 सेवा पहुँच गर्न सक्षम भएको चाहन्छौं। एउटा सानो TTL क्षेत्र थप्ने हो? र अब हामीसँग अस्थायी अनुमतिहरू छन्, उदाहरणका लागि, एक दिनको लागि।

पहुँचहरू

हामी सेवाहरू र ग्राहकहरू जडान गर्छौं: हामीसँग सेवा छ, प्रत्येकको लागि KV भण्डारण तयार छ। अब हामी सबैलाई पहुँच प्रदान गर्दैनौं, तर छनौट रूपमा।

समूहहरू

यदि हामीले प्रत्येक पटक पहुँचको लागि हजारौं आईपीहरू लेख्यौं भने, हामी थकित हुनेछौं। समूहहरू लिएर आउनुहोस् - KV मा छुट्टै उपसेट। यसलाई उपनाम (वा समूह) भनौं र त्यही सिद्धान्त अनुसार समूहहरू भण्डारण गरौं।

जडान गरौं: अब हामी P2P को लागि विशेष गरी SSH खोल्न सक्दैनौं, तर सम्पूर्ण समूह वा धेरै समूहहरूको लागि। त्यसैगरी, त्यहाँ TTL छ - तपाईं समूहमा थप्न सक्नुहुन्छ र अस्थायी रूपमा समूहबाट हटाउन सक्नुहुन्छ।

एकीकरण

हाम्रो समस्या मानव कारक र स्वचालन हो। अहिलेसम्म हामीले यसरी समाधान गरेका छौं।

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

हामीले befw-sync लेख्यौं, एक सरल समाधान जसले डेटा स्थानान्तरण गर्न मद्दत गर्दछ। पहिले, सिंक कुकीहरू puppetdb द्वारा पहुँच गरिन्छ। त्यहाँ HTTP API कन्फिगर गरिएको छ: हामी अनुरोध गर्छौं कि हामीसँग कुन सेवाहरू छन्, के गर्न आवश्यक छ। त्यसपछि उनीहरूले कन्सुललाई अनुरोध गर्छन्।

त्यहाँ एकीकरण छ? हो: तिनीहरूले नियमहरू लेखे र पुल अनुरोधहरू स्वीकार गर्न अनुमति दिए। के तपाईलाई निश्चित पोर्ट चाहिन्छ वा केहि समूहमा होस्ट थप्नुहोस्? अनुरोध तान्नुहोस्, समीक्षा गर्नुहोस् - अब "200 अन्य ACL फेला पार्नुहोस् र यसको बारेमा केहि गर्न प्रयास गर्नुहोस्।"

अनुकूलन

खाली नियम शृङ्खलाको साथ लोकलहोस्ट पिङ गर्न ०.०७५ ms लाग्छ।

यस चेनमा 10 iptables ठेगानाहरू थपौं। नतिजाको रूपमा, पिंग 000 गुणा बढ्नेछ: iptables पूर्णतया रैखिक छ, प्रत्येक ठेगाना प्रशोधन गर्न केहि समय लाग्छ।

फायरवालको लागि जहाँ हामी हजारौं ACLs माइग्रेट गर्छौं, हामीसँग धेरै नियमहरू छन्, र यसले विलम्बता परिचय गराउँछ। यो गेमिङ प्रोटोकलहरूको लागि खराब छ।

तर यदि हामीले राख्यौं ipset मा 10 ठेगानाहरू पिंग पनि कम हुनेछ।

बिन्दु यो हो कि ipset को लागि "O" (एल्गोरिथ्म जटिलता) जहिले पनि 1 को बराबर हुन्छ, त्यहाँ जतिसुकै नियमहरू भए पनि। साँचो, त्यहाँ एक सीमा छ - त्यहाँ 65535 भन्दा बढी नियमहरू हुन सक्दैन। अहिलेको लागि हामी यससँग बाँचिरहेका छौं: तपाईं तिनीहरूलाई संयोजन गर्न सक्नुहुन्छ, तिनीहरूलाई विस्तार गर्न सक्नुहुन्छ, एकमा दुई ipsets बनाउन सक्नुहुन्छ।

भण्डारण

पुनरावृत्ति प्रक्रियाको तार्किक निरन्तरताले ipset मा सेवाको लागि ग्राहकहरूको बारेमा जानकारी भण्डारण गर्दैछ।

अब हामीसँग एउटै SSH छ, र हामी एकै पटक 100 आईपीहरू लेख्दैनौं, तर हामीले सञ्चार गर्न आवश्यक पर्ने ipset को नाम सेट गर्छौं, र निम्न नियमहरू DROP। यसलाई एक नियममा रूपान्तरण गर्न सकिन्छ "यहाँ को छैन, DROP", तर यो अझ स्पष्ट छ।

अब हामीसँग नियम र सेटहरू छन्। मुख्य कार्य भनेको नियम लेख्नु अघि सेट बनाउनु हो, किनकि अन्यथा iptables ले नियम लेख्ने छैन।

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

रेखाचित्रको रूपमा, मैले भनेका सबै कुरा यस्तो देखिन्छ।

हामी कठपुतलीमा प्रतिबद्ध छौं, सबै कुरा होस्टमा पठाइन्छ, सेवाहरू यहाँ, त्यहाँ ipset, र त्यहाँ दर्ता नभएको जो कोहीलाई अनुमति छैन।

स्वीकार अस्वीकार

चाँडै संसार बचाउन वा कसैलाई चाँडै असक्षम गर्न, सबै चेनहरूको सुरुमा हामीले दुई ipsets बनायौं: rules_allow и rules_deny। यसले कसरी काम गर्छ?

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

हामी यसलाई कन्सुलमा पठाउँछौं, 2,5 सेकेन्ड पर्खनुहोस्, र यो सकियो। कन्सुलले 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 श्रृंखलामा सेवाहरूको नियमहरू। तर यसले अन्य चेन र नियमहरू र अन्य ipsets निगरानी गर्दैन।

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

BEFW ले सधैं अन्तिम ज्ञात राम्रो अवस्था सिधै state.bin बाइनरी संरचनामा भण्डार गर्छ। यदि केहि गलत भयो भने, यो सधैं यो 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 देखि काम गरेको छैन, यो नम्बर #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।

हामी निरन्तर कन्फिगरेसन विस्तार गर्न, मेट्रिक्स र अप्टिमाइजेसन बढाउँदै काम गरिरहेका छौं।

परियोजनामा ​​सामेल हुनुहोस्। परियोजना राम्रो भयो, तर, दुर्भाग्यवश, यो अझै पनि एक-व्यक्ति परियोजना हो। आउनुहोस् GitHub र केहि गर्न प्रयास गर्नुहोस्: प्रतिबद्ध, परीक्षण, केहि सुझाव, आफ्नो मूल्याङ्कन दिनुहोस्।

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

स्रोत: www.habr.com