Įmonė 2010 m buvo 50 serverių ir paprastas tinklo modelis: backend, frontend ir ugniasienė. Serverių skaičius augo, modelis tapo sudėtingesnis: sustojimai, izoliuoti VLAN su ACL, vėliau VPN su VRF, VLAN su ACL L2, VRF su ACL L3. Galva sukasi? Vėliau bus smagiau.
Kai buvo 16 000 serverių, tapo neįmanoma dirbti be ašarų, kai tiek daug nevienalyčių segmentų. Taigi mes sugalvojome kitą sprendimą. Paėmėme „Netfilter“ krūvą, įtraukėme „Consul“ kaip duomenų šaltinį ir gavome greitai paskirstytą užkardą. Jie pakeitė maršrutizatorių ACL ir naudojo juos kaip išorinę ir vidinę ugniasienę. Norėdami dinamiškai valdyti įrankį, sukūrėme BEFW sistemą, kuri buvo naudojama visur: nuo vartotojų prieigos prie produktų tinklo valdymo iki tinklo segmentų atskyrimo vienas nuo kito.
Jis jums pasakys, kaip visa tai veikia ir kodėl turėtumėte atidžiau pažvelgti į šią sistemą. Ivanas Agarkovas () yra įmonės Minsko plėtros centro Techninės priežiūros skyriaus infrastruktūros saugumo grupės vadovas. Ivanas yra SELinux gerbėjas, mėgsta Perlą ir rašo kodą. Būdamas informacijos saugos grupės vadovu, jis nuolat dirba su žurnalais, atsarginėmis kopijomis ir R&D, kad apsaugotų „Wargaming“ nuo įsilaužėlių ir užtikrintų visų įmonėje esančių žaidimų serverių veikimą.
Istorinė informacija,
Prieš pasakodamas, kaip mes tai padarėme, papasakosiu, kaip mes tai padarėme ir kodėl to reikėjo. Norėdami tai padaryti, grįžkime 9 metus atgal: 2010 m. ką tik pasirodė „World of Tanks“. Wargaming turėjo apie 50 serverių.
Įmonės serverio augimo diagrama.
Turėjome tinklo modelį. Tuo metu tai buvo optimalu.
Tinklo modelis 2010 m.
Priekinėje dalyje yra blogi vaikinai, kurie nori mus sulaužyti, bet ji turi užkardą. Galinėje sistemoje nėra ugniasienės, bet ten yra 50 serverių, mes juos visus žinome. Viskas veikia gerai.
Per 4 metus serverių parkas išaugo 100 kartų, iki 5000. Atsirado pirmieji izoliuoti tinklai – inscenizacija: jie negalėjo patekti į gamybą, o ten dažnai veikdavo dalykai, kurie gali būti pavojingi.
Tinklo modelis 2014 m.
Pagal inerciją naudojome tas pačias aparatūros dalis, o visas darbas buvo atliktas izoliuotuose VLAN: į VLAN įrašomi ACL, kurie leidžia arba užkerta kažkokį ryšį.
2016 metais serverių skaičius pasiekė 8000. Wargaming absorbavo kitas studijas, atsirado papildomų filialų tinklų. Atrodo, kad jie mūsų, bet ne visai: VLAN dažnai neveikia partneriams, tenka naudoti VPN su VRF, izoliacija tampa sudėtingesnė. ACL izoliacijos mišinys išaugo.
Tinklo modelis 2016 m.
Iki 2018 metų pradžios mašinų parkas išaugo iki 16 000. Buvo 6 segmentai, o likusių neskaičiavome, įskaitant uždarų, kuriuose buvo saugomi finansiniai duomenys. Atsirado konteinerių tinklai (Kubernetes), DevOps, debesų tinklai, prijungti per VPN, pavyzdžiui, iš IVS. Taisyklių buvo daug – buvo skaudu.
Tinklo modelis ir izoliavimo metodai 2018 m.
Išskyrimui naudojome: VLAN su ACL L2, VRF su ACL L3, VPN ir daug daugiau. Per daug.
Problemos
Visi gyvena su ACL ir VLAN. Kas negerai? Į šį klausimą atsakys Haroldas, slėpdamas skausmą.
Buvo daug problemų, bet buvo penkios didžiulės.
- Geometrinis naujų taisyklių kainų padidėjimas. Kiekvienos naujos taisyklės pridėjimas užtruko ilgiau nei ankstesnė, nes pirmiausia reikėjo pažiūrėti, ar tokia taisyklė jau yra.
- Segmentuose nėra ugniasienės. Segmentai buvo kažkaip atskirti vienas nuo kito, o viduje jau nebuvo pakankamai resursų.
- Taisyklės buvo taikomos ilgą laiką. Vieną vietinę taisyklę operatoriai galėjo parašyti ranka per valandą. Pasaulinis užtruko kelias dienas.
- Sunkumai su audito taisyklėmis. Tiksliau, tai nebuvo įmanoma. Pirmosios taisyklės buvo parašytos dar 2010 m., o dauguma jų autorių įmonėje nebedirbo.
- Žemas infrastruktūros kontrolės lygis. Tai yra pagrindinė problema – mes nelabai žinojome, kas vyksta mūsų šalyje.
Taip atrodė tinklo inžinierius 2018 m., kai išgirdo: „Reikia daugiau ACL“.
Sprendimai
2018 metų pradžioje buvo nuspręsta dėl to ką nors padaryti.
Integracijų kaina nuolat auga. Pradinis taškas buvo tas, kad dideli duomenų centrai nustojo palaikyti izoliuotus VLAN ir ACL, nes įrenginiuose pritrūko atminties.
Sprendimas: pašalinome žmogiškąjį faktorių ir maksimaliai automatizavome prieigos suteikimą.
Naujų taisyklių taikymas užtrunka ilgai. Sprendimas: paspartinkite taisyklių taikymą, padarykite jas paskirstytą ir lygiagrečią. Tam reikalinga paskirstyta sistema, kad taisyklės būtų pateiktos pačios tūkstančiui sistemų be rsync ar SFTP.
Segmentuose nėra ugniasienės. Segmentų užkarda pas mus pradėjo atsirasti, kai tame pačiame tinkle atsirado skirtingų paslaugų. Sprendimas: naudokite užkardą pagrindinio kompiuterio lygyje – pagrindinio kompiuterio ugniasienės. Beveik visur, kur turime Linux, ir visur, kur turime iptables, tai nėra problema.
Sunkumai su audito taisyklėmis. Sprendimas: laikykite visas taisykles vienoje vietoje, kad galėtumėte peržiūrėti ir valdyti, kad galėtume viską patikrinti.
Žemas infrastruktūros kontrolės lygis. Sprendimas: surašykite visas paslaugas ir prieigas tarp jų.
Tai daugiau administracinis, o ne techninis procesas. Kartais turime 200-300 naujų leidimų per savaitę, ypač per akcijas ir šventes. Be to, tai skirta tik vienai mūsų „DevOps“ komandai. Turint tiek daug leidimų, neįmanoma suprasti, kokių prievadų, IP ir integracijų reikia. Todėl mums reikėjo specialiai apmokytų paslaugų vadybininkų, kurie paklausė komandų: „Kas čia išvis yra ir kodėl tai iškėlėte?
Po visko, ką pradėjome, tinklo inžinierius 2019 m. pradėjo atrodyti taip.
konsulas
Nusprendėme, kad viską, ką radome su paslaugų vadybininkų pagalba, įdėsime į Consul ir iš ten rašysime iptables taisykles.
Kaip mes nusprendėme tai padaryti?
- Mes rinksime visas paslaugas, tinklus ir vartotojus.
- Jomis remdamiesi sukurkime iptables taisykles.
- Automatizuojame valdymą.
- ....
- PELNAS.
Consul nėra nuotolinė API, ji gali veikti kiekviename mazge ir rašyti į iptables. Belieka sugalvoti automatinius valdiklius, kurie išvalys nereikalingus daiktus, ir dauguma problemų bus išspręstos! Likusią dalį sutvarkysime eidami.
Kodėl konsulas?
Puikiai pasitvirtino. 2014–15 m. naudojome jį kaip „Vault“ užpakalinę programą, kurioje saugome slaptažodžius.
Nepraranda duomenų. Naudojimo metu „Consul“ neprarado duomenų per vieną avariją. Tai didžiulis pliusas ugniasienės valdymo sistemai.
P2P ryšiai pagreitina pokyčių plitimą. Naudojant P2P, visi pakeitimai įvyksta greitai, nereikia laukti valandų valandas.
Patogi REST API. Mes taip pat svarstėme „Apache ZooKeeper“, tačiau jis neturi REST API, todėl turėsite įdiegti ramentus.
Veikia ir kaip raktų saugykla (KV), ir kaip katalogas (paslaugų atradimas). Galite vienu metu saugoti paslaugas, katalogus ir duomenų centrus. Tai patogu ne tik mums, bet ir kaimyninėms komandoms, nes kurdami pasaulinę paslaugą galvojame plačiai.
Parašyta Go, kuris yra Wargaming krūvos dalis. Mums patinka ši kalba, turime daug „Go“ kūrėjų.
Galinga ACL sistema. „Consul“ galite naudoti ACL, kad galėtumėte valdyti, kas ką rašo. Garantuojame, kad ugniasienės taisyklės nesutaps su niekuo kitu ir dėl to neturėsime problemų.
Tačiau konsulas turi ir trūkumų.
- Duomenų centre nekeičiama, nebent turite verslo versiją. Jį gali keisti tik federacija.
- Labai priklauso nuo tinklo kokybės ir serverio apkrovos. Consul tinkamai neveiks kaip serveris užimtame serveryje, jei tinkle yra kokių nors vėlavimų, pavyzdžiui, netolygus greitis. Taip yra dėl P2P jungčių ir atnaujinimo platinimo modelių.
- Sunku stebėti prieinamumą. Konsulo statusu jis gali sakyti, kad viskas gerai, bet jis jau seniai mirė.
Daugumą šių problemų išsprendėme naudodamiesi Consul, todėl ir pasirinkome. Įmonė turi planų sukurti alternatyvų backendą, tačiau mes išmokome spręsti problemas ir šiuo metu gyvename su konsulu.
Kaip veikia konsulas
Įdiegsime nuo trijų iki penkių serverių sąlyginiame duomenų centre. Vienas ar du serveriai neveiks: jie negalės organizuoti kvorumo ir nuspręsti, kas teisus, o kas neteisus, kai duomenys nesutampa. Daugiau nei penki neturi prasmės, našumas kris.
Klientai prie serverių jungiasi bet kokia tvarka: tie patys agentai, tik su vėliavėle server = false.
Po to klientai gauna P2P jungčių sąrašą ir sukuria ryšius tarpusavyje.
Pasauliniu lygiu sujungiame kelis duomenų centrus. Jie taip pat jungia P2P ir bendrauja.
Kai norime gauti duomenis iš kito duomenų centro, užklausa siunčiama iš serverio į serverį. Ši schema vadinama Baudžiavos protokolas. Serf protokolą, kaip ir konsulą, sukūrė HashiCorp.
Keletas svarbių faktų apie konsulą
Konsulas turi dokumentus, kuriuose aprašoma, kaip tai veikia. Pateiksiu tik atrinktus faktus, kuriuos verta žinoti.
Konsulo serveriai iš rinkėjų atrenka šeimininką. Konsulas kiekvienam duomenų centrui iš serverių sąrašo pasirenka pagrindinį ir visos užklausos patenka tik į jį, nepriklausomai nuo serverių skaičiaus. Meistro sušalimas nepriveda prie perrinkimo. Jei meistras nepasirenkamas, užklausų niekas neaptarnauja.
Ar norėjote horizontalaus mastelio? Atsiprašau, ne.
Užklausa kitam duomenų centrui perduodama iš pagrindinio kompiuterio į pagrindinį, neatsižvelgiant į tai, į kurį serverį ji buvo pateikta. Pasirinktas meistras gauna 100% apkrovos, išskyrus persiuntimo užklausų apkrovą. Visi duomenų centre esantys serveriai turi naujausią duomenų kopiją, tačiau atsako tik vienas.
Vienintelis būdas padidinti mastelį yra įjungti pasenusio kliento režimą.
Pasenusiu režimu galite atsakyti be kvorumo. Tai režimas, kai atsisakome duomenų nuoseklumo, bet skaitome šiek tiek greičiau nei įprastai, o bet kuris serveris reaguoja. Natūralu, kad įrašymas tik per meistrą.
Konsulas nekopijuoja duomenų tarp duomenų centrų. Sukūrus federaciją, kiekvienas serveris turės tik savo duomenis. Dėl kitų jis visada kreipiasi į ką nors kitą.
Operacijų atomiškumas negarantuojamas už sandorio ribų. Atminkite, kad ne jūs vienintelis, kuris gali pakeisti dalykus. Jei norite kitaip, atlikite operaciją su užraktu.
Blokavimo operacijos negarantuoja užrakinimo. Užklausa perduodama iš pagrindinio pagrindinio kompiuterio, o ne tiesiogiai, todėl nėra garantijos, kad blokavimas veiks, kai blokuosite, pavyzdžiui, kitame duomenų centre.
ACL taip pat negarantuoja prieigos (daugeliu atvejų). ACL gali neveikti, nes jis saugomas viename federacijos duomenų centre – ACL duomenų centre (pirminiame DC). Jei DC jums neatsako, ACL neveiks.
Dėl vieno sušalusio meistro sušals visa federacija. Pavyzdžiui, federacijoje yra 10 duomenų centrų, vienas jų turi blogą tinklą, o vienas pagrindinis sugenda. Visi, kurie su juo bendraus, bus įsprausti į ratą: yra prašymas, atsakymo į jį nėra, siūlas užšąla. Niekaip negali žinoti, kada tai įvyks, tiesiog po valandos ar dviejų kris visa federacija. Nieko negalite padaryti.
Statusas, kvorumas ir rinkimai tvarkomi atskira gija. Perrinkimas neįvyks, statusas nieko neparodys. Manote, kad turite gyvą konsulą, klausiate, o nieko neįvyksta – atsakymo nėra. Tuo pačiu būsena rodo, kad viskas gerai.
Susidūrėme su šia problema ir turėjome iš naujo sukurti tam tikras duomenų centrų dalis, kad to išvengtume.
Verslo versija Consul Enterprise neturi kai kurių aukščiau išvardytų trūkumų. Jis turi daug naudingų funkcijų: rinkėjų atranka, paskirstymas, mastelio keitimas. Yra tik vienas „bet“ - paskirstytos sistemos licencijavimo sistema yra labai brangi.
Gyvybės įsilaužimas: rm -rf /var/lib/consul - vaistas nuo visų agento ligų. Jei kažkas neveikia, tiesiog ištrinkite duomenis ir atsisiųskite duomenis iš kopijos. Greičiausiai konsulas dirbs.
BEFW
Dabar pakalbėkime apie tai, ką pridėjome prie konsulo.
yra akronimas BACKEndFašWvisi. Turėjau kažkaip pavadinti produktą, kai sukūriau saugyklą, kad galėčiau atlikti pirmuosius bandymo įsipareigojimus. Šis vardas išlieka.
Taisyklių šablonai
Taisyklės parašytos iptables sintakse.
- -N BEFW
- -P ĮVESTIES KREPIMAS
- -A ĮVESTIS -m būsena - būsena SUSIJĘS, NUSTATYTA -j PRIIMTI
- -A ĮVESTIS -i lo -j PRIIMTI
- -A ĮVESTIS -j BEFW
Viskas patenka į BEFW grandinę, išskyrus ESTABLISHED, RELATED ir vietinis šeimininkas. Šablonas gali būti bet koks, tai tik pavyzdys.
Kuo BEFW naudingas?
Paslaugos
Mes turime paslaugą, ji visada turi prievadą, mazgą, kuriame ji veikia. Iš savo mazgo galime vietoje paklausti agento ir sužinoti, kad turime tam tikrą paslaugą. Taip pat galite įdėti žymes.
Bet kuri paslauga, kuri veikia ir užregistruota „Consul“, virsta „iptables“ taisykle. Turime SSH – open port 22. Bash scenarijus paprastas: curl ir iptables, daugiau nieko nereikia.
Klientai
Kaip atverti prieigą ne visiems, o pasirinktinai? Pridėkite IP sąrašus į KV saugyklą pagal paslaugos pavadinimą.
Pavyzdžiui, norime, kad visi dešimtojo tinklo nariai galėtų pasiekti SSH_TCP_22 paslaugą. Pridėti vieną mažą TTL laukelį? o dabar turime laikinus leidimus, pvz., dienai.
Prieigos
Sujungiame paslaugas ir klientus: turime paslaugą, kiekvienam paruošta KV saugykla. Dabar suteikiame prieigą ne visiems, o pasirinktinai.
Grupės
Jei prieigai kiekvieną kartą parašysime tūkstančius IP, pavargsime. Sugalvokime grupes – atskirą poaibį KV. Pavadinkime jį Alias (arba grupėmis) ir saugokime ten grupes pagal tą patį principą.
Prisijunkime: dabar SSH galime atidaryti ne specialiai P2P, o visai grupei ar kelioms grupėms. Lygiai taip pat yra TTL – galite pridėti prie grupės ir laikinai pašalinti iš grupės.
Integracija
Mūsų problema – žmogiškasis faktorius ir automatizavimas. Iki šiol mes tai išsprendėme tokiu būdu.
Dirbame su Puppet, jiems perduodame viską, kas susiję su sistema (programos kodą). Puppetdb (įprastas PostgreSQL) saugo ten veikiančių paslaugų sąrašą, jas galima rasti pagal išteklių tipą. Ten galite sužinoti, kas kur kreipiasi. Tam taip pat turime ištraukimo ir sujungimo užklausų sistemą.
Parašėme befw-sync – paprastą sprendimą, padedantį perkelti duomenis. Pirma, sinchronizavimo slapukus pasiekia puppetdb. Ten sukonfigūruotas HTTP API: teiraujamės, kokias paslaugas turime, ką reikia padaryti. Tada jie pateikia prašymą konsului.
Ar yra integracija? Taip: jie parašė taisykles ir leido priimti ištraukimo užklausas. Ar jums reikia tam tikro prievado ar pridėti prieglobos prie kokios nors grupės? Ištraukite užklausą, peržiūrėkite – nebereikia „Suraskite 200 kitų ACL ir pabandykite ką nors padaryti“.
Optimizavimas
Pinging localhost su tuščia taisyklių grandine užtrunka 0,075 ms.
Pridėkime prie šios grandinės 10 000 iptables adresų. Dėl to ping padidės 5 kartus: iptables yra visiškai linijinis, kiekvieno adreso apdorojimas užtrunka šiek tiek laiko.
Užkardai, į kuriuos perkeliame tūkstančius ACL, turime daug taisyklių, todėl atsiranda delsos. Tai kenkia žaidimų protokolams.
Bet jei įdėtume 10 000 adresų ipset Ping netgi sumažės.
Esmė ta, kad ipset „O“ (algoritmo sudėtingumas) visada yra lygus 1, nesvarbu, kiek taisyklių yra. Tiesa, yra apribojimas – taisyklių negali būti daugiau nei 65535. Kol kas su tuo gyvename: galima jas derinti, plėsti, daryti du ipsetus viename.
Sandėliavimas
Logiška iteracijos proceso tęsinys yra informacijos apie klientus saugojimas paslaugai ipset.
Dabar mes turime tą patį SSH ir nerašome 100 IP iš karto, o nustatome ipset pavadinimą, su kuriuo turime susisiekti, ir šią taisyklę DROP. Tai gali būti paversta viena taisykle „Kas čia nėra, DROP“, bet ji aiškiau.
Dabar turime taisykles ir rinkinius. Pagrindinė užduotis – prieš rašant taisyklę padaryti aibę, nes kitaip iptables taisyklės neparašys.
Bendroji schema
Diagramos pavidalu viskas, ką sakiau, atrodo taip.
Įsipareigojame Puppet, viskas siunčiama šeimininkui, paslaugos čia, ipset ten, o kas ten neužsiregistravę neįleidžia.
Leisti ir atmesti
Norėdami greitai išgelbėti pasaulį arba greitai ką nors išjungti, visų grandinių pradžioje sukūrėme du ipsetus: rules_allow и rules_deny. Kaip tai veikia?
Pavyzdžiui, kažkas sukuria apkrovą mūsų žiniatinklyje naudodamas robotus. Anksčiau turėdavai surasti jo IP iš žurnalų, nunešti jį tinklo inžinieriams, kad šie surastų srauto šaltinį ir jį užblokuotų. Dabar atrodo kitaip.
Išsiunčiame konsului, palaukiame 2,5 sekundės ir viskas. Kadangi „Consul“ greitai platina per P2P, jis veikia visur, bet kurioje pasaulio vietoje.
Kartą kažkaip visiškai sustabdžiau WOT dėl ugniasienės klaidos. rules_allow – tai mūsų draudimas nuo tokių atvejų. Jei kur nors suklydome su užkarda, kažkas kažkur užblokuotas, visada galime atsiųsti sąlyginį 0.0/0greitai viską pasiimti. Vėliau viską sutvarkysime rankomis.
Kiti rinkiniai
Galite pridėti bet kokius kitus rinkinius erdvėje $IPSETS$.
Kam? Kartais kam nors reikia ipset, pavyzdžiui, kad būtų galima imituoti tam tikros klasterio dalies išjungimą. Kiekvienas gali atnešti bet kokius rinkinius, pavadinti juos ir juos paims iš Konsulo. Tuo pačiu metu rinkiniai gali dalyvauti iptables taisyklėse arba veikti kaip komanda NOOP: nuoseklumą palaikys demonas.
Nariai
Anksčiau buvo taip: vartotojas prisijungė prie tinklo ir gavo parametrus per domeną. Prieš atsirandant naujos kartos ugniasienėms, Cisco nežinojo, kaip suprasti, kur yra vartotojas ir kur yra IP. Todėl prieiga buvo suteikta tik per mašinos pagrindinio kompiuterio pavadinimą.
Ką mes padarėme? Užstrigome tuo metu, kai gavome adresą. Paprastai tai yra dot1x, Wi-Fi arba VPN - viskas vyksta per RADIUS. Kiekvienam vartotojui sukuriame grupę pagal vartotojo vardą ir įdedame joje IP su TTL, kuris yra lygus jo dhcp.lease – kai tik baigsis, taisyklė išnyks.
Dabar mes galime atidaryti prieigą prie paslaugų, kaip ir kitų grupių, naudodami vartotojo vardą. Atsikratėme prieglobsčio vardų, kai jie keičiasi, ir nuėmėme tinklo inžinierių naštą, nes jiems nebereikia „Cisco“. Dabar inžinieriai patys registruoja prieigą savo serveriuose.
Izoliacija
Tuo pačiu metu pradėjome ardyti izoliaciją. Paslaugų vadovai atliko inventorizaciją, o mes išanalizavome visus savo tinklus. Suskirstykime jas į tas pačias grupes, o reikalinguose serveriuose grupės buvo pridėtos, pavyzdžiui, atmesti. Dabar ta pati inscenizacijos izoliacija baigiasi gamybos taisyklėse_neigimu, bet ne pačioje produkcijoje.
Schema veikia greitai ir paprastai: pašaliname visus ACL iš serverių, iškrauname aparatūrą, sumažiname izoliuotų VLAN skaičių.
Vientisumo kontrolė
Anksčiau turėjome specialų aktyviklį, kuris pranešdavo, kai kas nors rankiniu būdu pakeitė ugniasienės taisyklę. Rašiau didžiulę liniją ugniasienės taisyklių patikrinimui, buvo sunku. Sąžiningumą dabar kontroliuoja BEFW. Jis uoliai užtikrina, kad jo nustatytos taisyklės nesikeistų. Jei kas nors pakeis ugniasienės taisykles, viskas pasikeis atgal. „Greitai sukūriau tarpinį serverį, kad galėčiau dirbti iš namų“ – daugiau tokių parinkčių nebėra.
BEFW valdo ipset iš paslaugų ir sąrašo befw.conf, paslaugų taisyklės BEFW grandinėje. Tačiau jis nestebi kitų grandinių ir taisyklių bei kitų ipsetų.
Apsauga nuo avarijų
BEFW visada saugo paskutinę žinomą geros būseną tiesiogiai būsenos.bin dvejetainėje struktūroje. Jei kas nors negerai, jis visada grįžta į šią būseną.bin.
Tai yra draudimas nuo nestabilios konsulo veiklos, kai neatsiuntė duomenų arba kažkas suklydo ir naudojo taisykles, kurių negalima taikyti. Siekdami užtikrinti, kad neliktume be ugniasienės, BEFW grįš į naujausią būseną, jei bet kuriame etape įvyks klaida.
Kritinėse situacijose tai yra garantija, kad liksime su veikiančia užkarda. Atidarome visus pilkus tinklus tikėdamiesi, kad ateis administratorius ir sutvarkys. Kada nors įdėsiu tai į konfigūracijas, bet dabar turime tik tris pilkus tinklus: 10/8, 172/12 ir 192.168/16. Mūsų konsului tai yra svarbi savybė, padedanti mums toliau tobulėti.
Demonstracija: pranešimo metu Ivanas demonstruoja BEFW demonstracinį režimą. Lengviau žiūrėti demonstraciją . Galimas demonstracinis šaltinio kodas .
Spąstų
Papasakosiu apie klaidas, su kuriomis susidūrėme.
ipset add set 0.0.0.0/0. Kas atsitiks, jei prie ipset pridėsite 0.0.0.0/0? Ar visi IP bus pridėti? Ar bus galima prisijungti prie interneto?
Ne, gausime klaidą, kuri mums kainuos dvi prastovos valandas. Be to, klaida neveikė nuo 2016 m., Ji yra RedHat Bugzilla numeriu 1297092, ir mes ją radome atsitiktinai – iš kūrėjo ataskaitos.
Dabar tai yra griežta BEFW taisyklė 0.0.0.0/0 virsta dviem adresais: 0.0.0.0/1 и 128.0.0.0/1.
ipset atkūrimo rinkinys < failas. Ką daro ipset, kai liepiate restore? Ar manote, kad jis veikia taip pat kaip iptables? Ar atkurs duomenis?
Nieko panašaus - jis sujungia, o seni adresai niekur nedingsta, jūs neužblokuojate prieigos.
Bandydami izoliaciją radome klaidą. Dabar yra gana sudėtinga sistema – vietoj restore rankinė create temptada restore flush temp и restore temp. Pasikeitimo pabaigoje: dėl atomiškumo, nes jei tai padarysite pirmiausia flush ir šiuo metu atkeliauja koks nors paketas, jis bus išmestas ir kažkas nutiks. Taigi ten yra šiek tiek juodosios magijos.
consul kv get -datacenter=other. Kaip jau sakiau, manome, kad prašome tam tikrų duomenų, bet gausime duomenis arba klaidą. Tai galime padaryti per konsulą vietoje, tačiau tokiu atveju abu užšals.
Vietinis „Consul“ klientas yra HTTP API paketas. Bet jis tiesiog kabo ir nereaguoja tik į Ctrl+C, Ctrl+Z, ar dar ką nors kill -9 kitoje konsolėje. Su tuo susidūrėme kurdami didelį klasterį. Tačiau sprendimo kol kas neturime; ruošiamės taisyti šią klaidą „Consul“.
Konsulo vadovas neatsako. Mūsų meistras duomenų centre nereaguoja, galvojame: „Gal dabar veiks pakartotinio pasirinkimo algoritmas?
Ne, nepavyks, ir stebėjimas nieko neparodys: konsulas pasakys, kad yra įsipareigojimų indeksas, rastas vadovas, viskas gerai.
Kaip mes su tuo susitvarkome? service consul restart cron kas valandą. Jei turite 50 serverių, nieko tokio. Kai jų bus 16 000, suprasite, kaip tai veikia.
išvada
Dėl to gavome šiuos pranašumus:
- 100% visų Linux įrenginių aprėptis.
- Greitis
- Automatika.
- Išlaisvinome aparatūros ir tinklo inžinierius iš vergijos.
- Atsirado beveik neribotos integravimo galimybės: net su Kubernetes, net su Ansible, net su Python.
Trūkumai: Konsulas, su kuriuo dabar turime gyventi, ir labai didelės klaidos kainos. Pavyzdžiui, kartą 6 val. (Rusijos geriausiu laiku) kažką redagavau tinklų sąrašuose. Tuo metu BEFW tik statėme izoliaciją. Kažkur suklydau, rodos, ne tą kaukę nurodžiau, bet viskas nukrito per dvi sekundes. Stebėjimas užsidega, atbėga budintis pagalbinis asmuo: „Viską turime! Skyriaus vadovas papilkė, kai verslui paaiškino, kodėl taip atsitiko.
Klaidos kaina yra tokia didelė, kad mes sugalvojome savo sudėtingą prevencijos procedūrą. Jei tai įdiegiate didelėje gamybos vietoje, jums nereikės visiems duoti pagrindinio žetono per konsulą. Tai baigsis blogai.
Kaina. Vien kodą rašiau 400 valandų. Mano 4 žmonių komanda per mėnesį skiria 10 valandų visų palaikymui. Palyginti su bet kurios naujos kartos ugniasienės kaina, ji nemokama.
Planai. Ilgalaikis planas yra rasti alternatyvų transportą, kuris pakeistų arba papildytų konsulą. Galbūt tai bus Kafka ar kažkas panašaus. Tačiau ateinančiais metais mes gyvensime konsulu.
Greiti planai: integracija su Fail2ban, su stebėjimu, su nftables, galbūt su kitais platinimais, metrika, pažangus stebėjimas, optimizavimas. Kubernetes palaikymas irgi kažkur planuose, nes dabar turime keletą klasterių ir noro.
Daugiau iš planų:
- eismo anomalijų paieška;
- tinklo žemėlapių valdymas;
- Kubernetes palaikymas;
- visų sistemų paketų surinkimas;
- Web-UI.
Nuolat plečiame konfigūraciją, didiname metrikas ir optimizuojame.
Prisijunk prie projekto. Projektas pasirodė šaunus, bet, deja, tai vis dar vieno žmogaus projektas. Ateik pas ir bandyti ką nors padaryti: įsipareigoti, išbandyti, ką nors pasiūlyti, pateikti savo įvertinimą.
Tuo tarpu mes ruošiamės , kuris vyks balandžio 6 ir 7 dienomis Sankt Peterburge ir kviečiame didelės apkrovos sistemų kūrėjus . Patyrę pranešėjai jau žino, ką daryti, bet tiems, kurie pradeda kalbėti, rekomenduojame bent jau . Dalyvavimas konferencijoje kaip pranešėjas turi nemažai privalumų. Galite perskaityti, pavyzdžiui, pabaigoje .
Šaltinis: www.habr.com