Ընկերությունը 2010թ կար 50 սերվեր և պարզ ցանցային մոդել՝ backend, frontend և firewall: Սերվերների թիվն աճեց, մոդելը դարձավ ավելի բարդ՝ բեմականացում, մեկուսացված VLAN-ներ ACL-ներով, այնուհետև VPN-ներ VRF-ներով, VLAN-ներ ACL-ներով L2-ով, VRF-ներ ACL-ներով L3-ով: Գլուխը պտտվում է? Հետագայում ավելի զվարճալի կլինի:
Երբ կար 16 սերվեր, անհնարին դարձավ առանց արցունքների աշխատել այդքան տարասեռ հատվածներով։ Այսպիսով, մենք եկանք մեկ այլ լուծում. Մենք վերցրեցինք Netfilter ստեկը, դրան ավելացրինք Consul-ը որպես տվյալների աղբյուր և ստացանք արագ բաշխված firewall: Նրանք փոխարինեցին ACL-ները երթուղիչների վրա և օգտագործեցին դրանք որպես արտաքին և ներքին firewall: Գործիքը դինամիկ կառավարելու համար մենք մշակեցինք BEFW համակարգը, որն օգտագործվում էր ամենուր՝ սկսած օգտատերերի մուտքը դեպի արտադրանքի ցանց կառավարելուց մինչև ցանցի հատվածները միմյանցից մեկուսացնելը:
Նա ձեզ կասի, թե ինչպես է այդ ամենն աշխատում, և ինչու պետք է ավելի ուշադիր նայեք այս համակարգին: Իվան Ագարկով () ընկերության Մինսկի զարգացման կենտրոնում տեխնիկական սպասարկման բաժնի ենթակառուցվածքի անվտանգության խմբի ղեկավարն է: Իվանը SELinux-ի երկրպագու է, սիրում է Perl-ը և գրում է կոդ: Որպես տեղեկատվական անվտանգության խմբի ղեկավար՝ նա պարբերաբար աշխատում է լոգերի, կրկնօրինակների և R&D-ի հետ՝ Wargaming-ը հաքերներից պաշտպանելու և ընկերության բոլոր խաղային սերվերների աշխատանքը ապահովելու համար։
Պատմական տեղեկատվություն
Նախքան ձեզ կասեմ, թե ինչպես մենք դա արեցինք, ես ձեզ կասեմ, թե ի սկզբանե ինչպես հասանք դրան և ինչու էր դա անհրաժեշտ: Դա անելու համար գնանք 9 տարի հետ՝ 2010 թվականը, հենց նոր հայտնվեց Տանկերի աշխարհը: Wargaming-ն ուներ մոտավորապես 50 սերվեր:
Ընկերության սերվերի աճի աղյուսակ.
Մենք ունեինք ցանցային մոդել: Այն ժամանակ դա օպտիմալ էր։
Ցանցային մոդելը 2010 թ.
Առջևում կան վատ տղաներ, ովքեր ցանկանում են կոտրել մեզ, բայց այն ունի firewall: Backend-ում չկա firewall, բայց այնտեղ կա 50 սերվեր, մենք բոլորին գիտենք: Ամեն ինչ լավ է աշխատում։
4 տարվա ընթացքում սերվերների նավատորմը աճել է 100 անգամ՝ հասնելով 5000-ի: Ի հայտ եկան առաջին մեկուսացված ցանցերը՝ բեմականացում. դրանք չէին կարող գնալ արտադրության, և հաճախ այնտեղ վազում էին այնպիսի բաներ, որոնք կարող էին վտանգավոր լինել:
Ցանցային մոդելը 2014 թ.
Իներցիայով մենք օգտագործեցինք նույն սարքաշարը, և ամբողջ աշխատանքն իրականացվեց մեկուսացված VLAN-ների վրա. ACL-ները գրված են VLAN-ներում, որոնք թույլ են տալիս կամ մերժում ինչ-որ կապ:
2016 թվականին սերվերների թիվը հասավ 8000-ի: Wargaming-ը կլանեց այլ ստուդիաներ, և հայտնվեցին լրացուցիչ մասնաճյուղային ցանցեր: Թվում է, թե դրանք մերն են, բայց ոչ այնքան. VLAN-ը հաճախ չի աշխատում գործընկերների համար, դուք պետք է օգտագործեք VPN-ը VRF-ով, մեկուսացումը դառնում է ավելի բարդ: ACL մեկուսացման խառնուրդն աճեց:
Ցանցային մոդելը 2016 թ.
2018 թվականի սկզբին մեքենաների պարկը հասել է 16-ի, եղել է 000 հատված, իսկ մնացածը չենք հաշվել, այդ թվում՝ փակները, որոնցում պահվում են ֆինանսական տվյալներ։ Հայտնվել են կոնտեյներային ցանցեր (Kubernetes), DevOps, VPN-ի միջոցով միացված ամպային ցանցեր, օրինակ՝ IVS-ից։ Շատ կանոններ կային՝ ցավալի էր։
Ցանցի մոդելը և մեկուսացման մեթոդները 2018 թ.
Մեկուսացման համար մենք օգտագործել ենք՝ VLAN ACL-ով L2-ով, VRF-ով ACL-ով L3-ով, VPN և շատ ավելին: Չափից շատ.
Problems
Բոլորն ապրում են ACL-ով և VLAN-ով: Ինչ է պատահել? Այս հարցին կպատասխանի Հարոլդը՝ թաքցնելով ցավը։
Խնդիրները շատ էին, բայց զանգվածային հինգը։
- Նոր կանոնների համար գների երկրաչափական բարձրացում. Յուրաքանչյուր նոր կանոն ավելանալու համար ավելի երկար էր տևում, քան նախորդը, քանի որ նախ անհրաժեշտ էր տեսնել, թե արդյոք արդեն կա այդպիսի կանոն:
- Սեգմենտների ներսում firewall չկա. Սեգմենտներն ինչ-որ կերպ անջատված էին միմյանցից, իսկ ներսում արդեն բավականաչափ ռեսուրսներ չկային։
- Կանոնները երկար ժամանակ կիրառվում էին։ Օպերատորները կարող էին մեկ ժամում ձեռքով գրել մեկ տեղական կանոն: Համաշխարհայինը տեւեց մի քանի օր։
- Աուդիտի կանոնների հետ կապված դժվարություններ. Ավելի ճիշտ՝ հնարավոր չէր։ Առաջին կանոնները գրվել են դեռ 2010 թվականին, և դրանց հեղինակների մեծ մասն այլևս չի աշխատել ընկերությունում։
- Ենթակառուցվածքի վերահսկման ցածր մակարդակ. Սա է հիմնական խնդիրը. մենք այնքան էլ լավ չգիտեինք, թե ինչ է կատարվում մեր երկրում։
Ահա թե ինչպիսի տեսք ուներ ցանցային ինժեները 2018 թվականին, երբ լսեց. «Պետք է ևս ACL»:
Решения
2018 թվականի սկզբին որոշվեց ինչ-որ բան անել դրա դեմ։
Ինտեգրումների գինը անընդհատ աճում է։ Ելակետն այն էր, որ տվյալների մեծ կենտրոնները դադարեցրին մեկուսացված VLAN և ACL-ների աջակցությունը, քանի որ սարքերի հիշողությունը սպառվեց:
Լուծում․ մենք հանեցինք մարդկային գործոնը և ավտոմատացրինք մուտքի առավելագույն հնարավորությունը։
Նոր կանոնների կիրառումը երկար ժամանակ է պահանջում։ Լուծում` արագացնել կանոնների կիրառումը, դարձնել այն բաշխված և զուգահեռ: Սա պահանջում է բաշխված համակարգ, որպեսզի կանոններն ինքնուրույն առաքվեն՝ առանց rsync կամ SFTP հազար համակարգերի:
Սեգմենտների ներսում firewall չկա: Սեգմենտների ներսում firewall-ը սկսեց մեզ մոտ հայտնվել, երբ տարբեր ծառայություններ հայտնվեցին նույն ցանցում: Լուծում. օգտագործեք firewall-ը հյուրընկալողի մակարդակում՝ հոսթինգի վրա հիմնված firewalls: Գրեթե ամենուր, որտեղ մենք ունենք Linux, և ամենուր, որտեղ մենք ունենք iptables, սա խնդիր չէ:
Աուդիտի կանոնների հետ կապված դժվարություններ. Լուծում. Պահպանեք բոլոր կանոնները մեկ տեղում՝ վերանայման և կառավարման համար, որպեսզի մենք կարողանանք ստուգել ամեն ինչ:
Ենթակառուցվածքների նկատմամբ վերահսկողության ցածր մակարդակ: Լուծում. գույքագրեք բոլոր ծառայությունների և դրանց միջև եղած մուտքերը:
Սա ավելի շատ վարչական գործընթաց է, քան տեխնիկական: Երբեմն մենք շաբաթական ունենում ենք 200-300 նոր թողարկում, հատկապես ակցիաների և տոների ժամանակ։ Ավելին, սա մեր DevOps-ի միայն մեկ թիմի համար է: Այսքան թողարկումներով անհնար է տեսնել, թե ինչ նավահանգիստներ, IP-ներ և ինտեգրումներ են անհրաժեշտ: Հետևաբար, մեզ պետք էին հատուկ վերապատրաստված սպասարկման մենեջերներ, ովքեր թիմերին հարցրին.
Այն ամենից հետո, ինչ մենք գործարկեցինք, 2019-ին ցանցային ինժեները սկսեց այսպիսի տեսք ունենալ.
Հյուպատոս
Մենք որոշեցինք, որ այն ամենը, ինչ գտնում ենք ծառայության մենեջերների օգնությամբ, կդնենք հյուպատոսի մեջ և այնտեղից կգրենք iptables-ի կանոնները:
Ինչպե՞ս որոշեցինք դա անել:
- Մենք հավաքելու ենք բոլոր ծառայությունները, ցանցերը և օգտվողները:
- Եկեք դրանց հիման վրա ստեղծենք iptables կանոններ։
- Մենք ավտոմատացնում ենք վերահսկողությունը:
- ....
- ՇԱՀՈՒՅԹ.
Consul-ը հեռավոր API չէ, այն կարող է աշխատել յուրաքանչյուր հանգույցի վրա և գրել iptables-ում: Մնում է միայն գալ ավտոմատ հսկողություններ, որոնք կմաքրեն ավելորդ բաները, և խնդիրների մեծ մասը կլուծվի: Մնացածը մենք կմշակենք, երբ գնանք:
Ինչու՞ հյուպատոս:
Լավ է ապացուցել: 2014-15 թվականներին մենք այն օգտագործել ենք որպես Vault-ի հետին պլան, որտեղ մենք պահում ենք գաղտնաբառերը:
Չի կորցնում տվյալները. Օգտագործման ընթացքում հյուպատոսը տվյալներ չի կորցրել մեկ վթարի ժամանակ: Սա հսկայական պլյուս է firewall-ի կառավարման համակարգի համար:
P2P կապերն արագացնում են փոփոխությունների տարածումը. P2P-ով բոլոր փոփոխություններն արագ են կատարվում, ժամերով սպասելու կարիք չկա:
Հարմար REST API: Մենք դիտարկել ենք նաև Apache ZooKeeper-ը, սակայն այն չունի REST API, այնպես որ դուք ստիպված կլինեք տեղադրել հենակներ:
Աշխատում է և որպես բանալի պահոց (KV) և որպես գրացուցակ (Ծառայությունների հայտնաբերում). Դուք կարող եք միանգամից պահել ծառայություններ, կատալոգներ և տվյալների կենտրոններ: Սա հարմար է ոչ միայն մեզ, այլեւ հարեւան թիմերին, քանի որ գլոբալ ծառայություն կառուցելիս մենք մեծ մտածում ենք։
Գրված է Go-ում, որը Wargaming փաթեթի մի մասն է: Մենք սիրում ենք այս լեզուն, մենք ունենք շատ Go-ի մշակողներ:
Հզոր ACL համակարգ: Consul-ում դուք կարող եք օգտագործել ACL-ները՝ վերահսկելու համար, թե ով ինչ է գրում: Մենք երաշխավորում ենք, որ firewall-ի կանոնները չեն համընկնի որևէ այլ բանի հետ, և մենք խնդիրներ չենք ունենա այս հարցում:
Սակայն հյուպատոսն ունի նաև իր թերությունները.
- Չի ծավալվում տվյալների կենտրոնի ներսում, քանի դեռ չունեք բիզնես տարբերակ: Այն ընդլայնելի է միայն ֆեդերացիայի կողմից:
- Շատ կախված է ցանցի որակից և սերվերի բեռնվածությունից: Հյուպատոսը ճիշտ չի աշխատի որպես սերվեր զբաղված սերվերի վրա, եթե ցանցում ուշացումներ կան, օրինակ՝ անհավասար արագություն: Դա պայմանավորված է P2P միացումներով և բաշխման թարմացման մոդելներով:
- Դժվարության մոնիտորինգի առկայությունը. Հյուպատոսի կարգավիճակում նա կարող է ասել, որ ամեն ինչ լավ է, բայց վաղուց մահացել է։
Այս խնդիրների մեծ մասը մենք լուծել ենք հյուպատոս օգտագործելիս, ինչի պատճառով էլ ընտրել ենք այն: Ընկերությունը պլաններ ունի այլընտրանքային հետին պլանի համար, բայց մենք սովորել ենք հաղթահարել խնդիրները և ներկայումս ապրում ենք հյուպատոսի հետ:
Ինչպես է աշխատում հյուպատոսը
Պայմանական տվյալների կենտրոնում մենք կտեղադրենք երեքից հինգ սերվեր: Մեկ կամ երկու սերվեր չի աշխատի. նրանք չեն կարողանա քվորում կազմակերպել և որոշել, թե ով է ճիշտ և ով սխալ, երբ տվյալները չեն համընկնում: Հինգից ավելին անիմաստ է, արտադրողականությունը կնվազի:
Հաճախորդները սերվերներին միանում են ցանկացած հերթականությամբ՝ նույն գործակալները, միայն դրոշով server = false.
Դրանից հետո հաճախորդները ստանում են P2P կապերի ցուցակ և կապեր են ստեղծում միմյանց միջև:
Համաշխարհային մակարդակում մենք կապում ենք մի քանի տվյալների կենտրոններ: Նրանք նաև միացնում են P2P-ը և շփվում:
Երբ մենք ցանկանում ենք տվյալներ առբերել այլ տվյալների կենտրոնից, հարցումն անցնում է սերվերից սերվեր: Այս սխեման կոչվում է Սերֆի արձանագրություն. Ճորտերի արձանագրությունը, ինչպես հյուպատոսը, մշակվել է HashiCorp-ի կողմից:
Մի քանի կարևոր փաստ հյուպատոսի մասին
Հյուպատոսն ունի փաստաթղթեր, որոնք նկարագրում են, թե ինչպես է այն աշխատում: Ես կտամ միայն ընտրված փաստեր, որոնք արժե իմանալ։
Հյուպատոսների սպասարկողներն ընտրողներից ընտրում են վարպետին. Հյուպատոսը յուրաքանչյուր տվյալների կենտրոնի համար սերվերների ցանկից վարպետ է ընտրում, և բոլոր հարցումները գնում են միայն նրան՝ անկախ սերվերների քանակից: Վարպետի սառեցումը չի հանգեցնում վերընտրության. Եթե վարպետը ընտրված չէ, հարցումները չեն սպասարկվում որևէ մեկի կողմից:
Ցանկանու՞մ էիք հորիզոնական մասշտաբում: Կներեք, ոչ:
Մեկ այլ տվյալների կենտրոնի հարցումն անցնում է վարպետից վարպետ՝ անկախ նրանից, թե որ սերվերին է այն եկել: Ընտրված վարպետը ստանում է բեռնվածության 100%-ը, բացառությամբ առաջընթացի հարցումների բեռի: Տվյալների կենտրոնի բոլոր սերվերներն ունեն տվյալների արդիական պատճեն, բայց միայն մեկն է արձագանքում:
Սանդղակի չափման միակ միջոցը հաճախորդի վրա հնացած ռեժիմը միացնելն է:
Հնացած ռեժիմում դուք կարող եք պատասխանել առանց քվորումի: Սա մի ռեժիմ է, որտեղ մենք հրաժարվում ենք տվյալների հետևողականությունից, բայց կարդում ենք սովորականից մի փոքր ավելի արագ, և ցանկացած սերվեր արձագանքում է: Բնականաբար, ձայնագրությունը միայն վարպետի միջոցով։
Հյուպատոսը չի պատճենում տվյալները տվյալների կենտրոնների միջև. Երբ ֆեդերացիան հավաքվում է, յուրաքանչյուր սերվեր կունենա միայն իր տվյալները: Մյուսների համար նա միշտ դիմում է ուրիշին:
Գործառնությունների ատոմականությունը երաշխավորված չէ գործարքից դուրս. Հիշեք, որ դուք միակը չեք, ով կարող է փոխել իրերը։ Եթե այլ կերպ եք ուզում, գործարք կատարեք կողպեքով։
Արգելափակման գործողությունները չեն երաշխավորում կողպումը. Հարցումը գնում է վարպետից վարպետ, և ոչ ուղղակիորեն, այնպես որ երաշխիք չկա, որ արգելափակումը կաշխատի, երբ դուք արգելափակեք, օրինակ, մեկ այլ տվյալների կենտրոնում:
ACL-ը նույնպես չի երաշխավորում մուտքը (շատ դեպքերում). ACL-ը կարող է չաշխատել, քանի որ այն պահվում է մեկ դաշնային տվյալների կենտրոնում՝ ACL տվյալների կենտրոնում (Primary DC): Եթե DC-ն ձեզ չպատասխանի, ACL-ը չի աշխատի:
Մեկ սառեցված վարպետը կհանգեցնի ամբողջ ֆեդերացիայի սառեցմանը. Օրինակ, ֆեդերացիայում կա 10 տվյալների կենտրոն, և մեկը վատ ցանց ունի, և մեկ վարպետը ձախողվում է: Նրա հետ շփվող բոլորը կխրվեն օղակի մեջ՝ խնդրանք կա, պատասխան չկա, թելը սառչում է։ Ոչ մի կերպ չի կարելի իմանալ, թե դա երբ կլինի, ընդամենը մեկ-երկու ժամից ամբողջ ֆեդերացիան կտապալվի: Դուք ոչինչ չեք կարող անել դրա դեմ:
Կարգավիճակը, քվորումը և ընտրությունները վարվում են առանձին թեմայով: Վերընտրություն չի լինելու, կարգավիճակը ոչինչ ցույց չի տալու. Կարծում ես, որ կենդանի հյուպատոս ունես, հարցնում ես, ու ոչինչ չի լինում, պատասխան չկա։ Միաժամանակ, կարգավիճակը ցույց է տալիս, որ ամեն ինչ լավ է։
Մենք բախվել ենք այս խնդրին և ստիպված ենք եղել վերակառուցել տվյալների կենտրոնների հատուկ մասեր՝ դրանից խուսափելու համար:
Consul Enterprise-ի բիզնես տարբերակը չունի վերը նշված որոշ թերություններ. Այն ունի բազմաթիվ օգտակար գործառույթներ՝ ընտրողների ընտրություն, բաշխում, մասշտաբավորում։ Կա միայն մեկ «բայց»՝ բաշխված համակարգի լիցենզավորման համակարգը շատ թանկ է:
Life hacking: rm -rf /var/lib/consul - դեղամիջոց գործակալի բոլոր հիվանդությունների համար: Եթե ինչ-որ բան ձեզ մոտ չի աշխատում, պարզապես ջնջեք ձեր տվյալները և ներբեռնեք տվյալները պատճենից: Ամենայն հավանականությամբ, հյուպատոսը կաշխատի։
BEFW
Հիմա եկեք խոսենք այն մասին, թե ինչ ենք ավելացրել հյուպատոսին:
-ի հապավումն է BackEndFզայրույթWբոլորը. Ես ստիպված էի ինչ-որ կերպ անվանել ապրանքը, երբ ստեղծեցի պահոցը, որպեսզի դրա մեջ տեղադրեի առաջին փորձարկման պարտավորությունները: Այս անունը մնում է.
Կանոնների ձևանմուշներ
Կանոնները գրված են iptables շարահյուսությամբ:
- -N BEFW
- -P INPUT DOP
- -A INPUT -m վիճակ — վիճակ ԿԱՊ, ՍՏԵՂԾՎԱԾ -j ԸՆԴՈՒՆԵԼ
- -A INPUT -i lo -j ԸՆԴՈՒՆԵԼ
- -A INPUT -j BEFW
Ամեն ինչ գնում է BEFW շղթայի մեջ, բացի ESTABLISHED, RELATED և localhost. Կաղապարը կարող է լինել ցանկացած, սա ընդամենը օրինակ է:
Ինչպե՞ս է BEFW-ն օգտակար:
Ծառայություններ
Մենք ունենք ծառայություն, այն միշտ ունի պորտ, հանգույց, որի վրա այն աշխատում է: Մեր հանգույցից մենք կարող ենք տեղականորեն հարցնել գործակալին և պարզել, որ մենք ունենք ինչ-որ ծառայություն: Կարող եք նաև պիտակներ տեղադրել։
Ցանկացած ծառայություն, որն աշխատում է և գրանցված է հյուպատոսում, վերածվում է iptables կանոնի: Մենք ունենք SSH՝ բաց պորտ 22: Bash սկրիպտը պարզ է՝ curl և iptables, ուրիշ ոչինչ պետք չէ:
Հաճախորդներ
Ինչպե՞ս բացել մուտքը ոչ բոլորի համար, այլ ընտրովի: Ավելացրեք IP ցուցակները KV պահեստին ծառայության անունով:
Օրինակ, մենք ցանկանում ենք, որ տասներորդ ցանցում գտնվող բոլորը կարողանան մուտք գործել SSH_TCP_22 ծառայություն: Ավելացնե՞լ մեկ փոքր TTL դաշտ: իսկ հիմա մենք ունենք ժամանակավոր թույլտվություններ, օրինակ՝ մեկ օրով։
Մուտքեր
Մենք կապում ենք ծառայություններն ու հաճախորդները. մենք ունենք ծառայություն, յուրաքանչյուրի համար KV պահեստավորումը պատրաստ է: Այժմ մենք մուտք ենք տալիս ոչ բոլորին, այլ ընտրովի։
Խումբ
Եթե ամեն անգամ մուտքի համար հազարավոր IP-ներ գրենք, կհոգնենք։ Եկեք խմբավորումներով հանդես գանք՝ առանձին ենթաբազմություն KV-ում: Եկեք այն անվանենք Alias (կամ խմբեր) և այնտեղ պահենք խմբերը նույն սկզբունքով։
Եկեք միացնենք. այժմ մենք կարող ենք բացել SSH ոչ թե հատուկ P2P-ի, այլ մի ամբողջ խմբի կամ մի քանի խմբերի համար։ Նույն կերպ, կա TTL - կարող եք ավելացնել խմբին և ժամանակավորապես հեռացնել խմբից:
Ինտեգրում
Մեր խնդիրը մարդկային գործոնն ու ավտոմատացումն է։ Մինչ այժմ մենք դա լուծել ենք այսպես.
Մենք աշխատում ենք Puppet-ի հետ և նրանց փոխանցում ենք այն ամենը, ինչ վերաբերում է համակարգին (հավելվածի կոդը): Puppetdb (սովորական PostgreSQL) պահպանում է այնտեղ աշխատող ծառայությունների ցանկը, որոնք կարելի է գտնել ըստ ռեսուրսի տեսակի: Այնտեղ կարող եք իմանալ, թե ով որտեղ է դիմում։ Մենք նաև դրա համար ունենք ձգման հարցում և միաձուլման հարցումների համակարգ:
Մենք գրել ենք befw-sync, պարզ լուծում, որն օգնում է տվյալների փոխանցմանը: Նախ, համաժամացման թխուկները հասանելի են puppetdb-ի կողմից: Այնտեղ կազմաձևված է HTTP API. մենք խնդրում ենք, թե ինչ ծառայություններ ունենք, ինչ պետք է անել: Հետո նրանք խնդրանքով դիմում են հյուպատոսին.
Կա՞ ինտեգրացիա։ Այո, նրանք գրել են կանոնները և թույլ են տվել, որ Pull Requests ընդունվեն: Ձեզ անհրաժեշտ է որոշակի նավահանգիստ կամ որևէ խմբին հոսթ ավելացնել: Քաշեք հարցումը, վերանայեք. այլևս «Գտեք 200 այլ ACL և փորձեք ինչ-որ բան անել դրա դեմ»:
Օպտիմալացում
Դատարկ կանոնների շղթայով localhost-ի օգտագործումը տևում է 0,075 ms:
Եկեք այս շղթային ավելացնենք 10 iptables հասցե: Արդյունքում պինգը կավելանա 000 անգամ՝ iptables-ը լիովին գծային է, յուրաքանչյուր հասցեի մշակումը որոշակի ժամանակ է պահանջում։
Firewall-ի համար, որտեղ մենք տեղափոխում ենք հազարավոր ACL-ներ, մենք ունենք շատ կանոններ, և սա բերում է ուշացում: Սա վատ է խաղային արձանագրությունների համար:
Բայց եթե դնենք 10 հասցե ipset-ում Պինգը նույնիսկ կնվազի։
Բանն այն է, որ «O»-ն (ալգորիթմի բարդությունը) ipset-ի համար միշտ հավասար է 1-ի՝ անկախ նրանից, թե քանի կանոն կա։ Ճիշտ է, կա սահմանափակում՝ չի կարող լինել ավելի քան 65535 կանոն։ Առայժմ մենք ապրում ենք սրանով՝ կարող ես դրանք համատեղել, ընդլայնել, երկու իպսեթ անել մեկում։
Պահեստավորում
Կրկնման գործընթացի տրամաբանական շարունակությունը հաճախորդների մասին տեղեկատվության պահպանումն է ծառայության համար ipset-ում:
Հիմա մենք ունենք նույն SSH-ը, և մենք միանգամից 100 IP չենք գրում, այլ դնում ենք այն ipset-ի անունը, որի հետ պետք է շփվենք, և հետևյալ կանոնը. DROP. Այն կարող է փոխակերպվել մեկ կանոնի «Ով այստեղ չէ, ԿԱՑԻՐ», բայց դա ավելի պարզ է:
Այժմ մենք ունենք կանոններ և դրույթներ: Հիմնական խնդիրն այն է, որ նախքան կանոնը գրելը մի շարք պատրաստելն է, քանի որ հակառակ դեպքում iptables-ը կանոնը չի գրի։
Ընդհանուր սխեմա
Դիագրամի տեսքով իմ ասած ամեն ինչ այսպիսի տեսք ունի.
Մենք պարտավորվում ենք Puppet-ին, ամեն ինչ ուղարկվում է հյուրընկալողին, ծառայությունները՝ այստեղ, ipset՝ այնտեղ, և ով գրանցված չէ այնտեղ, չի թույլատրվում:
Թույլատրել և մերժել
Աշխարհը արագ փրկելու կամ ինչ-որ մեկին արագ անջատելու համար բոլոր շղթաների սկզբում մենք երկու իպսեթ արեցինք. rules_allow и rules_deny. Ինչպես է դա աշխատում?
Օրինակ, ինչ-որ մեկը բոտերով բեռ է ստեղծում մեր վեբում: Նախկինում լոգերից պետք է գտնեիր նրա IP-ն, տանեիր ցանցի ինժեներներին, որպեսզի նրանք գտնեին տրաֆիկի աղբյուրը և արգելեին նրան։ Հիմա այլ տեսք ունի:
Մենք այն ուղարկում ենք հյուպատոսին, սպասեք 2,5 վայրկյան, և դա արված է: Քանի որ Consul-ը արագ բաշխում է P2P-ի միջոցով, այն աշխատում է ամենուր, աշխարհի ցանկացած մասում:
Մի անգամ ես ինչ-որ կերպ ամբողջովին դադարեցրեցի WOT-ը firewall-ի սխալի պատճառով: rules_allow - Սա մեր ապահովագրությունն է նման դեպքերից։ Եթե մենք ինչ-որ տեղ սխալ ենք թույլ տվել firewall-ի հետ, ինչ-որ բան ինչ-որ տեղ արգելափակված է, մենք միշտ կարող ենք պայմանական ուղարկել 0.0/0արագ վերցնել ամեն ինչ: Ավելի ուշ մենք ամեն ինչ ձեռքով կշտկենք։
Այլ հավաքածուներ
Դուք կարող եք ավելացնել ցանկացած այլ հավաքածուներ տարածության մեջ $IPSETS$.
Ինչի համար? Երբեմն ինչ-որ մեկին անհրաժեշտ է ipset, օրինակ՝ նմանակելու կլաստերի որոշ մասի անջատումը: Յուրաքանչյուր ոք կարող է բերել ցանկացած հավաքածու, անվանել դրանք, և դրանք կվերցվեն հյուպատոսից: Միևնույն ժամանակ, սեթերը կարող են կամ մասնակցել iptables կանոններին կամ գործել որպես թիմ NOOPՀետևողականությունը կպահպանվի դեյմոնի կողմից:
Անդամներ
Նախկինում դա այսպիսին էր՝ օգտատերը միացել է ցանցին և տիրույթի միջոցով ստացել պարամետրեր։ Մինչև նոր սերնդի firewalls-ի հայտնվելը Cisco-ն չգիտեր ինչպես հասկանալ, թե որտեղ է օգտատերը և որտեղ է IP-ն: Հետևաբար, մուտքը տրվել է միայն մեքենայի հոսթի անվան միջոցով:
Ի՞նչ արեցինք։ Մենք խրվել ենք հասցեն ստանալու պահին։ Սովորաբար սա dot1x, Wi-Fi կամ VPN է. ամեն ինչ անցնում է RADIUS-ով: Յուրաքանչյուր օգտատիրոջ համար մենք ստեղծում ենք խումբ ըստ օգտվողի անունով և տեղադրում ենք IP TTL-ով, որը հավասար է իր dhcp.lease-ին. հենց որ ժամկետը լրանա, կանոնը կվերանա:
Այժմ մենք կարող ենք մուտք գործել ծառայություններ, ինչպես մյուս խմբերը, օգտվողի անունով: Մենք վերացրել ենք հոսթների անունների ցավը, երբ դրանք փոխվում են, և մենք հանել ենք ցանցի ինժեներների բեռը, քանի որ նրանք այլևս կարիք չունեն Cisco-ի: Այժմ ինժեներներն իրենք են գրանցում մուտքը իրենց սերվերների վրա:
Մեկուսացում
Միաժամանակ մենք սկսեցինք ապամոնտաժել մեկուսացումը: Ծառայությունների ղեկավարները գույքագրեցին, և մենք վերլուծեցինք մեր բոլոր ցանցերը: Եկեք դրանք բաժանենք նույն խմբերի, և անհրաժեշտ սերվերների վրա խմբերն ավելացվեցին, օրինակ, հերքելու համար։ Հիմա նույն բեմական մեկուսացումն ավարտվում է արտադրության կանոններով_ժխտում, բայց ոչ բուն արտադրության մեջ։
Սխեման աշխատում է արագ և պարզ. մենք հեռացնում ենք բոլոր ACL-ները սերվերներից, բեռնաթափում ենք սարքավորումները և նվազեցնում մեկուսացված VLAN-ների քանակը:
Ամբողջականության վերահսկում
Նախկինում մենք ունեինք հատուկ ձգան, որը հայտնում էր, երբ ինչ-որ մեկը ձեռքով փոխում էր firewall-ի կանոնը: Ես գրում էի հսկա լինտեր՝ firewall-ի կանոնները ստուգելու համար, դժվար էր։ Ամբողջականությունն այժմ վերահսկվում է BEFW-ի կողմից: Նա նախանձախնդրորեն վստահեցնում է, որ իր սահմանած կանոնները չփոխվեն։ Եթե ինչ-որ մեկը փոխի firewall-ի կանոնները, այն կփոխի ամեն ինչ: «Ես արագ ստեղծեցի վստահված անձ, որպեսզի կարողանամ աշխատել տնից», - այլևս նման տարբերակներ չկան:
BEFW-ն վերահսկում է ipset-ը befw.conf-ի ծառայություններից և ցանկից, BEFW շղթայի ծառայությունների կանոնները: Բայց դա չի վերահսկում այլ շղթաներ և կանոններ և այլ իպսեթեր:
Վթարի պաշտպանություն
BEFW-ն միշտ պահում է վերջին հայտնի լավ վիճակը անմիջապես state.binary կառուցվածքում: Եթե ինչ-որ բան սխալ է, այն միշտ վերադառնում է այս state.bin:
Սա ապահովագրություն է հյուպատոսի անկայուն գործունեությունից, երբ այն չի ուղարկել տվյալներ կամ ինչ-որ մեկը սխալ է թույլ տվել և օգտագործել կանոններ, որոնք չեն կարող կիրառվել: Ապահովելու համար, որ մենք չմնանք առանց firewall-ի, BEFW-ն կվերադառնա վերջին վիճակին, եթե որևէ փուլում սխալ տեղի ունենա:
Կրիտիկական իրավիճակներում սա երաշխիք է, որ մենք կմնանք աշխատող firewall-ով: Բոլոր մոխրագույն ցանցերը բացում ենք այն հույսով, որ ադմինը կգա ու կշտկի։ Մի օր ես սա կդնեմ կոնֆիգուրացիաների մեջ, բայց հիմա մենք ընդամենը երեք մոխրագույն ցանց ունենք՝ 10/8, 172/12 և 192.168/16: Մեր հյուպատոսի շրջանակներում սա կարևոր հատկանիշ է, որն օգնում է մեզ հետագա զարգանալ:
Դեմո. զեկույցի ընթացքում Իվանը ցուցադրում է BEFW-ի դեմո ռեժիմը: Ավելի հեշտ է դիտել ցուցադրությունը . Դեմո աղբյուրի կոդը հասանելի է .
Որոգայթներ
Ես ձեզ կպատմեմ մեր հանդիպած սխալների մասին:
ipset ավելացնել հավաքածու 0.0.0.0/0: Ի՞նչ կլինի, եթե ipset-ին ավելացնեք 0.0.0.0/0: Բոլոր IP-ները կավելացվեն? Արդյո՞ք հասանելի կլինի ինտերնետը:
Ո՛չ, մենք վրիպակ կստանանք, որը մեզ համար արժեցել է երկու ժամ պարապուրդ: Ավելին, սխալը չի աշխատում 2016 թվականից ի վեր, այն գտնվում է RedHat Bugzilla-ում՝ #1297092 համարով, և մենք այն գտել ենք պատահաբար՝ մշակողի զեկույցից:
Այժմ BEFW-ում խիստ կանոն է, որ 0.0.0.0/0 վերածվում է երկու հասցեի. 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < ֆայլ. Ի՞նչ է անում ipset-ը, երբ ասում ես restore? Ի՞նչ եք կարծում, այն նույնն է աշխատում, ինչ iptables-ը: Արդյո՞ք այն կվերականգնի տվյալները:
Նման ոչինչ. այն միաձուլվում է, և հին հասցեները ոչ մի տեղ չեն գնում, դուք չեք արգելափակում մուտքը:
Մեկուսացման փորձարկման ժամանակ մենք սխալ ենք հայտնաբերել: Հիմա բավականին բարդ համակարգ կա՝ փոխարենը restore անցկացվում է create temp, ապա restore flush temp и restore temp. Փոխանակման վերջում. ատոմականության համար, որովհետև եթե դա անես առաջինը flush և այս պահին ինչ-որ փաթեթ է հասնում, այն կվերացվի, և ինչ-որ բան սխալ կլինի: Այսպիսով, այնտեղ մի քիչ սև մոգություն կա:
հյուպատոս kv ստանալ -datacenter=այլ. Ինչպես ասացի, մենք կարծում ենք, որ որոշակի տվյալներ ենք խնդրում, բայց մենք կամ տվյալներ կստանանք, կամ սխալ: Մենք կարող ենք դա անել տեղական հյուպատոսի միջոցով, բայց այս դեպքում երկուսն էլ կսառչեն:
Տեղական Consul հաճախորդը HTTP API-ի վրա փաթաթված է: Բայց այն պարզապես կախված է և չի արձագանքում Ctrl+C-ին, կամ Ctrl+Z-ին կամ որևէ այլ բանի, միայն kill -9 հաջորդ վահանակում: Մենք դրան հանդիպեցինք, երբ մենք կառուցում էինք մեծ կլաստեր: Բայց մենք դեռ լուծում չունենք, մենք պատրաստվում ենք ուղղել այս սխալը հյուպատոսում:
Հյուպատոսի ղեկավարը չի արձագանքում. Տվյալների կենտրոնի մեր վարպետը չի արձագանքում, մենք մտածում ենք. «Միգուցե վերընտրման ալգորիթմը հիմա կաշխատի»:
Ոչ, չի ստացվի, և մոնիտորինգը ոչինչ ցույց չի տա. հյուպատոսը կասի, որ կա պարտավորությունների ինդեքս, առաջնորդ է գտնվել, ամեն ինչ լավ է։
Ինչպե՞ս ենք մենք վարվում սրա հետ: service consul restart cron-ում ամեն ժամ: Եթե ունես 50 սերվեր, մեծ խնդիր չկա: Երբ դրանք լինեն 16-ը, կհասկանաք, թե ինչպես է դա աշխատում։
Ամփոփում
Արդյունքում մենք ստացանք հետևյալ առավելությունները.
- Բոլոր Linux մեքենաների 100% ծածկույթ:
- Արագություն
- Ավտոմատացում.
- Մենք ստրկությունից ազատեցինք ապարատային և ցանցային ինժեներներին:
- Ինտեգրման հնարավորություններ են հայտնվել, որոնք գրեթե անսահման են՝ նույնիսկ Kubernetes-ի, նույնիսկ Ansible-ի, նույնիսկ Python-ի հետ:
ԴեմՀյուպատոս, որի հետ մենք հիմա պետք է ապրենք, և սխալի շատ բարձր արժեքը: Օրինակ՝ մի անգամ երեկոյան ժամը 6-ին (փրայմ թայմ Ռուսաստանում) ինչ-որ բան էի խմբագրում ցանցերի ցուցակներում։ Մենք այդ ժամանակ պարզապես մեկուսացում էինք անում BEFW-ում: Ինչ-որ տեղ սխալվեցի, կարծես թե սխալ դիմակ եմ ցույց տվել, բայց ամեն ինչ ընկավ երկու վայրկյանում։ Մոնիտորինգը վառվում է, հերթապահը վազելով գալիս է՝ «Մենք ամեն ինչ ունենք»։ Բաժնի պետը մոխրացել է, երբ բիզնեսին բացատրել է, թե ինչու է դա տեղի ունեցել։
Սխալների արժեքը այնքան բարձր է, որ մենք մշակել ենք կանխարգելման մեր սեփական բարդ ընթացակարգը: Եթե դուք դա իրականացնում եք մեծ արտադրական վայրում, ապա ձեզ հարկավոր չէ բոլորին տալ գլխավոր նշան հյուպատոսի վրա: Սա վատ կավարտվի։
Արժեքը 400 ժամ մենակ կոդ եմ գրել։ 4 հոգուց բաղկացած իմ թիմը ամսական 10 ժամ է ծախսում բոլորին աջակցելու համար: Համեմատած ցանկացած նոր սերնդի firewall-ի գնի հետ՝ այն անվճար է:
Պլաններ. Երկարաժամկետ պլանը հյուպատոսին փոխարինելու կամ լրացնելու այլընտրանքային փոխադրամիջոց գտնելն է: Միգուցե դա կլինի Կաֆկան կամ նման մի բան։ Բայց առաջիկա տարիներին մենք կապրենք հյուպատոսի վրա։
Անմիջական պլաններ՝ ինտեգրում Fail2ban-ի հետ, մոնիտորինգի հետ, nftable-ների հետ, հնարավոր է այլ բաշխումների, չափումների, առաջադեմ մոնիտորինգի, օպտիմալացման հետ: Kubernetes-ի աջակցությունը նույնպես ինչ-որ տեղ պլանների մեջ է, քանի որ այժմ մենք ունենք մի քանի կլաստերներ և ցանկություն:
Ավելի շատ պլաններից.
- երթևեկության մեջ անոմալիաների որոնում;
- ցանցային քարտեզների կառավարում;
- Kubernetes աջակցություն;
- բոլոր համակարգերի համար փաթեթների հավաքում;
- Վեբ-UI.
Մենք անընդհատ աշխատում ենք կոնֆիգուրացիան ընդլայնելու, չափումների մեծացման և օպտիմալացման վրա:
Միացե՛ք նախագծին։ Նախագիծը հիանալի ստացվեց, բայց, ցավոք, այն դեռ մեկ անձի համար նախատեսված նախագիծ է: Արի արի և փորձիր ինչ-որ բան անել՝ պարտավորվել, փորձարկել, ինչ-որ բան առաջարկել, տալ քո գնահատականը։
Մինչդեռ մենք պատրաստվում ենք , որը տեղի կունենա ապրիլի 6-ին և 7-ին Սանկտ Պետերբուրգում, և հրավիրում ենք բարձր բեռնվածության համակարգերի մշակողների. . Փորձառու խոսնակներն արդեն գիտեն, թե ինչ պետք է անել, բայց նրանց, ովքեր նոր են խոսում, խորհուրդ ենք տալիս գոնե . Համաժողովին որպես բանախոս մասնակցելն ունի մի շարք առավելություններ. Որոնք կարող եք կարդալ, օրինակ, վերջում .
Source: www.habr.com