Në vitin 2010 kompania kishte 50 serverë dhe një model të thjeshtë rrjeti: backend, frontend dhe firewall. Numri i serverëve u rrit, modeli u bë më kompleks: vënie në skenë, VLAN të izoluara me ACL, pastaj VPN me VRF, VLAN me ACL në L2, VRF me ACL në L3. Koka po rrotullohet? Më vonë do të jetë më argëtuese.
Kur kishte 16 serverë, u bë e pamundur të punohej pa lot me kaq shumë segmente heterogjene. Kështu që ne dolëm me një zgjidhje tjetër. Ne morëm stivën e Netfilter, shtuam Konsullin në të si burim të dhënash dhe morëm një mur zjarri të shpërndarë shpejt. Ata zëvendësuan ACL-të në ruterat dhe i përdorën ato si një mur zjarri i jashtëm dhe i brendshëm. Për të menaxhuar në mënyrë dinamike mjetin, ne zhvilluam sistemin BEFW, i cili u përdor kudo: nga menaxhimi i aksesit të përdoruesit në rrjetin e produktit deri te izolimi i segmenteve të rrjetit nga njëri-tjetri.
Ai do t'ju tregojë se si funksionon gjithçka dhe pse duhet ta shikoni më nga afër këtë sistem. Ivan Agarkov () është kreu i grupit të sigurisë së infrastrukturës të divizionit të mirëmbajtjes në qendrën e zhvillimit të kompanisë në Minsk. Ivan është një fans i SELinux, e do Perl dhe shkruan kode. Si kreu i grupit të sigurisë së informacionit, ai punon rregullisht me regjistrat, kopjet rezervë dhe R&D për të mbrojtur Wargaming nga hakerat dhe për të siguruar funksionimin e të gjithë serverëve të lojërave në kompani.
Informacioni historik
Para se t'ju tregoj se si e bëmë këtë, do t'ju tregoj se si arritëm në këtë në radhë të parë dhe pse ishte e nevojshme. Për ta bërë këtë, le të kthehemi 9 vjet pas: 2010, sapo u shfaq World of Tanks. Wargaming kishte afërsisht 50 serverë.
Grafiku i rritjes së serverit të kompanisë.
Ne kishim një model rrjeti. Për atë kohë ishte optimale.
Modeli i rrjetit në 2010.
Ka njerëz të këqij në pjesën e përparme që duan të na thyejnë, por ai ka një mur zjarri. Nuk ka asnjë mur zjarri në backend, por ka 50 serverë atje, ne i dimë të gjithë. Gjithçka funksionon mirë.
Në 4 vjet, flota e serverëve u rrit 100 herë, në 5000. U shfaqën rrjetet e para të izoluara - inskenimi: ata nuk mund të shkonin në prodhim dhe shpesh kishte gjëra që mund të ishin të rrezikshme.
Modeli i rrjetit në 2014.
Nga inercia, ne përdorëm të njëjtat pjesë të harduerit dhe e gjithë puna u krye në VLAN të izoluar: ACL-të shkruhen në VLAN, të cilat lejojnë ose mohojnë një lloj lidhjeje.
Në vitin 2016, numri i serverëve arriti në 8000. Wargaming thithi studio të tjera dhe u shfaqën rrjete shtesë të filialeve. Duket se janë tonat, por jo plotësisht: VLAN shpesh nuk funksionon për partnerët, duhet të përdorni VPN me VRF, izolimi bëhet më i ndërlikuar. Përzierja e izolimit ACL u rrit.
Modeli i rrjetit në 2016.
Në fillim të vitit 2018, flota e makinerive ishte rritur në 16 000. Kanë qenë 6 segmente dhe nuk kemi llogaritur pjesën tjetër, përfshirë ato të mbyllura në të cilat ruheshin të dhënat financiare. Janë shfaqur rrjetet e kontejnerëve (Kubernetes), DevOps, rrjetet cloud të lidhura përmes VPN, për shembull, nga një IVS. Kishte shumë rregulla - ishte e dhimbshme.
Modeli i rrjetit dhe metodat e izolimit në 2018.
Për izolim kemi përdorur: VLAN me ACL në L2, VRF me ACL në L3, VPN dhe shumë më tepër. Shume.
Problemet
Të gjithë jetojnë me ACL dhe VLAN. Çfarë nuk shkon? Kësaj pyetje do t'i përgjigjet Haroldi, duke fshehur dhimbjen.
Kishte shumë probleme, por ishin pesë të mëdha.
- Rritje gjeometrike e çmimit për rregullat e reja. Çdo rregull i ri duhej më shumë për t'u shtuar se ai i mëparshmi, sepse fillimisht ishte e nevojshme të shihej nëse ekzistonte tashmë një rregull i tillë.
- Nuk ka mur zjarri brenda segmenteve. Segmentet ishin disi të ndara nga njëri-tjetri dhe tashmë nuk kishte burime të mjaftueshme brenda.
- Rregullat u zbatuan për një kohë të gjatë. Operatorët mund të shkruajnë një rregull lokal me dorë në një orë. Ajo globale zgjati disa ditë.
- Vështirësitë me rregullat e auditimit. Më saktë, nuk ishte e mundur. Rregullat e para u shkruan në vitin 2010 dhe shumica e autorëve të tyre nuk punonin më për kompaninë.
- Niveli i ulët i kontrollit të infrastrukturës. Ky është problemi kryesor - ne nuk e dinim shumë mirë se çfarë po ndodhte në vendin tonë.
Kështu dukej një inxhinier rrjeti në vitin 2018 kur dëgjoi: "Duhet më shumë ACL".
Zgjidhjet
Në fillim të vitit 2018, u vendos që të bëhej diçka për këtë.
Çmimi i integrimeve është vazhdimisht në rritje. Pika e fillimit ishte se qendrat e mëdha të të dhënave ndaluan mbështetjen e VLAN-ve dhe ACL-ve të izoluara, sepse pajisjet u mbaruan nga memoria.
Zgjidhja: hoqëm faktorin njerëzor dhe automatizuam sigurimin e aksesit në maksimum.
Rregullat e reja kërkojnë shumë kohë për t'u zbatuar. Zgjidhja: përshpejtoni zbatimin e rregullave, bëjeni atë të shpërndarë dhe paralel. Kjo kërkon një sistem të shpërndarë në mënyrë që rregullat të dorëzohen vetë, pa rsync ose SFTP në një mijë sisteme.
Nuk ka mur zjarri brenda segmenteve. Një mur zjarri brenda segmenteve filloi të na vinte kur u shfaqën shërbime të ndryshme brenda të njëjtit rrjet. Zgjidhja: përdorni një mur zjarri në nivel pritës - mure zjarri të bazuara në host. Pothuajse kudo ku kemi Linux, dhe kudo që kemi iptables, ky nuk është problem.
Vështirësitë me rregullat e auditimit. Zgjidhja: Mbani të gjitha rregullat në një vend për rishikim dhe menaxhim, në mënyrë që të mund të auditojmë gjithçka.
Niveli i ulët i kontrollit mbi infrastrukturën. Zgjidhja: bëni një inventar të të gjitha shërbimeve dhe akseseve ndërmjet tyre.
Ky është më shumë një proces administrativ sesa teknik. Ndonjëherë kemi 200-300 publikime të reja në javë, veçanërisht gjatë promovimeve dhe festave. Për më tepër, kjo është vetëm për një ekip të DevOps-ve tanë. Me kaq shumë lëshime, është e pamundur të shihet se cilat porte, IP dhe integrime nevojiten. Prandaj, na duheshin menaxherë shërbimi të trajnuar posaçërisht, të cilët pyesnin ekipet: "Çfarë ka gjithsesi dhe pse e ngritët?"
Pas gjithçkaje që nisëm, një inxhinier rrjeti në 2019 filloi të dukej kështu.
konsull
Ne vendosëm që gjithçka që gjenim me ndihmën e menaxherëve të shërbimit të vendosnim në Konsull dhe prej andej do të shkruanim rregullat iptables.
Si vendosëm ta bënim këtë?
- Ne do të mbledhim të gjitha shërbimet, rrjetet dhe përdoruesit.
- Le të krijojmë rregulla iptables bazuar në to.
- Ne automatizojmë kontrollin.
- ....
- FITIMI.
Konsulli nuk është një API në distancë, ai mund të ekzekutohet në çdo nyje dhe të shkruajë në iptables. Mbetet vetëm të dalim me kontrolle automatike që do të pastrojnë gjërat e panevojshme dhe shumica e problemeve do të zgjidhen! Ne do të përpunojmë pjesën tjetër ndërsa shkojmë.
Pse konsull?
E ka dëshmuar veten mirë. Në 2014-15, ne e përdorëm atë si një backend për Vault, në të cilin ruajmë fjalëkalimet.
Nuk humbet të dhënat. Gjatë kohës së përdorimit, Konsulli nuk humbi të dhënat gjatë një aksidenti të vetëm. Ky është një plus i madh për një sistem të menaxhimit të murit të zjarrit.
Lidhjet P2P përshpejtojnë përhapjen e ndryshimit. Me P2P, të gjitha ndryshimet vijnë shpejt, nuk ka nevojë të presësh me orë të tëra.
API i përshtatshëm REST. Ne konsideruam gjithashtu Apache ZooKeeper, por ai nuk ka një API REST, kështu që do t'ju duhet të instaloni paterica.
Punon si një kasafortë çelësash (KV) dhe si një drejtori (Zbulimi i shërbimit). Ju mund të ruani shërbimet, katalogët dhe qendrat e të dhënave menjëherë. Kjo është e përshtatshme jo vetëm për ne, por edhe për ekipet fqinje, sepse kur ndërtojmë një shërbim global, ne mendojmë shumë.
Shkruar në Go, e cila është pjesë e pirgut Wargaming. Ne e duam këtë gjuhë, kemi shumë zhvillues Go.
Sistemi i fuqishëm ACL. Në Consul, ju mund të përdorni ACL për të kontrolluar se kush shkruan çfarë. Ne garantojmë që rregullat e murit të zjarrit nuk do të mbivendosen me asgjë tjetër dhe nuk do të kemi probleme me këtë.
Por konsulli ka edhe të metat e veta.
- Nuk shkallëzohet brenda një qendre të dhënash nëse nuk keni një version biznesi. Është i shkallëzueshëm vetëm nga federata.
- Shumë varet nga cilësia e rrjetit dhe ngarkesa e serverit. Konsulli nuk do të funksionojë siç duhet si server në një server të zënë nëse ka ndonjë vonesë në rrjet, për shembull, shpejtësi të pabarabartë. Kjo është për shkak të lidhjeve P2P dhe modeleve të shpërndarjes së përditësimit.
- Vështirësia e monitorimit të disponueshmërisë. Në statusin e Konsullit ai mund të thotë se gjithçka është në rregull, por ai ka vdekur shumë kohë më parë.
Ne i zgjidhëm shumicën e këtyre problemeve gjatë përdorimit të Konsullit, prandaj e zgjodhëm atë. Kompania ka plane për një backend alternativ, por ne kemi mësuar të përballemi me problemet dhe aktualisht po jetojmë me Konsullin.
Si punon konsulli
Ne do të instalojmë tre deri në pesë serverë në një qendër të dhënash të kushtëzuar. Një ose dy serverë nuk do të funksionojnë: ata nuk do të jenë në gjendje të organizojnë një kuorum dhe të vendosin se kush ka të drejtë dhe kush ka gabuar kur të dhënat nuk përputhen. Më shumë se pesë nuk ka kuptim, produktiviteti do të bjerë.
Klientët lidhen me serverët në çdo mënyrë: të njëjtët agjentë, vetëm me flamurin server = false.
Pas kësaj, klientët marrin një listë të lidhjeve P2P dhe ndërtojnë lidhje mes tyre.
Në nivel global, ne lidhim disa qendra të dhënash. Ata gjithashtu lidhin P2P dhe komunikojnë.
Kur duam të marrim të dhëna nga një qendër tjetër e të dhënave, kërkesa shkon nga serveri në server. Kjo skemë quhet Protokolli i serbit. Protokolli i Serf, si Konsulli, është zhvilluar nga HashiCorp.
Disa fakte të rëndësishme për Konsullin
Konsulli ka dokumentacion që përshkruan se si funksionon. Unë do të jap vetëm fakte të zgjedhura që ia vlen të dihen.
Serverët e konsullit zgjedhin një master nga radhët e votuesve. Konsulli zgjedh një master nga lista e serverëve për çdo qendër të dhënash dhe të gjitha kërkesat shkojnë vetëm tek ai, pavarësisht nga numri i serverëve. Ngrirja e masterit nuk çon në rizgjedhje. Nëse masteri nuk zgjidhet, kërkesat nuk shërbehen nga askush.
Dëshironi shkallëzim horizontal? Na vjen keq, jo.
Një kërkesë për një qendër tjetër të dhënash shkon nga master në master, pavarësisht se në cilin server erdhi. Masteri i zgjedhur merr 100% të ngarkesës, me përjashtim të ngarkesës në kërkesat e para. Të gjithë serverët në qendrën e të dhënave kanë një kopje të përditësuar të të dhënave, por vetëm njëri përgjigjet.
Mënyra e vetme për të shkallëzuar është aktivizimi i modalitetit të ndenjur në klient.
Në modalitetin e ndenjur, mund të përgjigjeni pa kuorum. Ky është një mënyrë në të cilën ne heqim dorë nga qëndrueshmëria e të dhënave, por lexojmë pak më shpejt se zakonisht dhe çdo server përgjigjet. Natyrisht, regjistrimi vetëm përmes masterit.
Konsulli nuk kopjon të dhënat ndërmjet qendrave të të dhënave. Kur mblidhet një federatë, çdo server do të ketë vetëm të dhënat e veta. Për të tjerët, ai gjithmonë i drejtohet dikujt tjetër.
Atomiciteti i operacioneve nuk garantohet jashtë një transaksioni. Mos harroni se nuk jeni i vetmi që mund t'i ndryshoni gjërat. Nëse e dëshironi ndryshe, kryeni një transaksion me një bravë.
Operacionet e bllokimit nuk garantojnë kyçje. Kërkesa shkon nga master në master, dhe jo drejtpërdrejt, kështu që nuk ka asnjë garanci që bllokimi do të funksionojë kur bllokoni, për shembull, në një qendër tjetër të dhënash.
ACL gjithashtu nuk garanton akses (në shumë raste). ACL mund të mos funksionojë sepse ruhet në një qendër të të dhënave federate - në qendrën e të dhënave ACL (DC Primar). Nëse DC nuk ju përgjigjet, ACL nuk do të funksionojë.
Një mjeshtër i ngrirë do të bëjë që e gjithë federata të ngrijë. Për shembull, ka 10 qendra të dhënash në një federatë, dhe një ka një rrjet të keq, dhe një master dështon. Kushdo që komunikon me të do të ngrijë në një rreth: ka një kërkesë, nuk ka përgjigje për të, filli ngrin. Nuk mund të dihet se kur do të ndodhë kjo, vetëm për një ose dy orë do të bjerë e gjithë federata. Nuk mund të bëni asgjë për këtë.
Statusi, kuorumi dhe zgjedhjet trajtohen nga një temë e veçantë. Rizgjedhja nuk do të ndodhë, statusi nuk do të tregojë asgjë. Ju mendoni se keni një Konsull të gjallë, ju pyesni, dhe asgjë nuk ndodh - nuk ka përgjigje. Në të njëjtën kohë, statusi tregon se gjithçka është në rregull.
Ne e kemi hasur këtë problem dhe na është dashur të rindërtojmë pjesë të veçanta të qendrave të të dhënave për ta shmangur atë.
Versioni i biznesit i Consul Enterprise nuk ka disa nga disavantazhet e mësipërme. Ka shumë funksione të dobishme: përzgjedhjen e votuesve, shpërndarjen, shkallëzimin. Ekziston vetëm një "por" - sistemi i licencimit për një sistem të shpërndarë është shumë i shtrenjtë.
Hakerimi i jetës: rm -rf /var/lib/consul - një kurë për të gjitha sëmundjet e agjentit. Nëse diçka nuk funksionon për ju, thjesht fshini të dhënat tuaja dhe shkarkoni të dhënat nga një kopje. Me shumë mundësi, konsulli do të punojë.
BEFW
Tani le të flasim për atë që i kemi shtuar Konsullit.
është një akronim për BackEndFinatWtë gjitha. Më duhej ta emëroja produktin disi kur krijova depon, në mënyrë që të vendosja në të testet e para. Ky emër mbetet.
Modelet e rregullave
Rregullat janë shkruar në sintaksë iptables.
- -N BEFW
- -P HIQJA E HYRJES
- -A INPUT -m gjendja-gjendja LIDHUR,KRIJUAR -j ACCEPT
- -A HYRJE -i lo -j PRANOJ
- -A HYRJE -j BEFW
Gjithçka shkon në zinxhirin BEFW, përveç ESTABLISHED, RELATED dhe localhost. Modeli mund të jetë çdo gjë, ky është vetëm një shembull.
Si është i dobishëm BEFW?
Sherbime
Ne kemi një shërbim, ai gjithmonë ka një port, një nyje në të cilën funksionon. Nga nyja jonë, ne mund të pyesim lokalisht agjentin dhe të zbulojmë se kemi një lloj shërbimi. Ju gjithashtu mund të vendosni etiketa.
Çdo shërbim që funksionon dhe regjistrohet te Konsulli kthehet në një rregull iptables. Ne kemi SSH - portin e hapur 22. Skripti Bash është i thjeshtë: curl dhe iptables, asgjë tjetër nuk nevojitet.
klientët
Si të hapni akses jo për të gjithë, por në mënyrë selektive? Shtoni listat IP në ruajtjen e KV sipas emrit të shërbimit.
Për shembull, ne duam që të gjithë në rrjetin e dhjetë të kenë mundësi të hyjnë në shërbimin SSH_TCP_22. Të shtohet një fushë e vogël TTL? dhe tani kemi leje të përkohshme, për shembull, për një ditë.
Akseset
Ne lidhim shërbimet dhe klientët: kemi një shërbim, ruajtja e KV është gati për secilin. Tani ne u japim akses jo të gjithëve, por në mënyrë selektive.
grupet
Nëse shkruajmë mijëra IP për akses çdo herë, do të lodhemi. Le të dalim me grupime - një nëngrup i veçantë në KV. Le ta quajmë Alias (ose grupe) dhe t'i ruajmë grupet atje sipas të njëjtit parim.
Le të lidhemi: tani mund të hapim SSH jo posaçërisht për P2P, por për një grup të tërë ose disa grupe. Në të njëjtën mënyrë, ekziston TTL - mund të shtoni në një grup dhe ta hiqni nga grupi përkohësisht.
integrim
Problemi ynë është faktori njerëzor dhe automatizimi. Deri tani e kemi zgjidhur në këtë mënyrë.
Ne punojmë me Puppet dhe transferojmë gjithçka që lidhet me sistemin (kodin e aplikacionit) tek ata. Puppetdb (i rregullt PostgreSQL) ruan një listë shërbimesh që funksionojnë atje, ato mund të gjenden sipas llojit të burimit. Aty mund të mësoni se kush ku po aplikon. Ne gjithashtu kemi një kërkesë për tërheqje dhe një sistem kërkesash për bashkim për këtë.
Ne kemi shkruar befw-sync, një zgjidhje e thjeshtë që ndihmon në transferimin e të dhënave. Së pari, skedarët e sinkronizimit aksesohen nga puppetdb. Aty është konfiguruar një API HTTP: ne kërkojmë se çfarë shërbimesh kemi, çfarë duhet bërë. Pastaj i bëjnë një kërkesë konsullit.
A ka integrim? Po: ata shkruan rregullat dhe lejuan që Kërkesat për tërheqje të pranohen. Keni nevojë për një port të caktuar apo shtoni një host në ndonjë grup? Tërhiqe Kërkesë, rishiko - jo më "Gjeni 200 ACL të tjera dhe përpiquni të bëni diçka për të."
optimization
Pining localhost me një zinxhir rregullash bosh kërkon 0,075 ms.
Le të shtojmë 10 adresa iptables në këtë zinxhir. Si rezultat, ping-u do të rritet 000 herë: iptables është plotësisht linear, përpunimi i secilës adresë kërkon pak kohë.
Për një mur zjarri ku ne migrojmë mijëra ACL, ne kemi shumë rregulla, dhe kjo paraqet vonesë. Kjo është e keqe për protokollet e lojërave.
Por nëse vendosim 10 adresa në ipset Pingu madje do të ulet.
Çështja është se "O" (kompleksiteti i algoritmit) për ipset është gjithmonë i barabartë me 1, pavarësisht sa rregulla ka. Vërtetë, ka një kufizim - nuk mund të ketë më shumë se 65535 rregulla. Tani për tani jetojmë me këtë: mund t'i kombinoni, zgjeroni, bëni dy ipset në një.
ruajtje
Një vazhdim logjik i procesit të përsëritjes është ruajtja e informacionit për klientët për shërbimin në ipset.
Tani kemi të njëjtin SSH dhe nuk shkruajmë 100 IP menjëherë, por vendosim emrin e ipset-it me të cilin duhet të komunikojmë dhe rregullin e mëposhtëm DROP. Mund të shndërrohet në një rregull "Kush nuk është këtu, HIQ", por është më e qartë.
Tani kemi rregulla dhe grupe. Detyra kryesore është të krijoni një grup përpara se të shkruani rregullin, sepse përndryshe iptables nuk do ta shkruajnë rregullin.
Skema e pergjithshme
Në formën e një diagrami, gjithçka që thashë duket kështu.
Ne angazhohemi për Puppet, gjithçka dërgohet te hosti, shërbimet këtu, ipset atje dhe kushdo që nuk është i regjistruar atje nuk lejohet.
Lejo & refuzo
Për të shpëtuar shpejt botën ose për të çaktivizuar shpejt dikë, në fillim të të gjitha zinxhirëve bëmë dy ipset: rules_allow и rules_deny. Si punon?
Për shembull, dikush po krijon një ngarkesë në ueb-in tonë me bot. Më parë, duhej të gjeje IP-në e tij nga regjistrat, t'ia çoje inxhinierëve të rrjetit, në mënyrë që ata të gjenin burimin e trafikut dhe ta ndalonin. Tani duket ndryshe.
E dërgojmë te Konsulli, presim 2,5 sekonda dhe është bërë. Meqenëse Konsulli shpërndan shpejt përmes P2P, ai funksionon kudo, në çdo pjesë të botës.
Një herë unë disi ndalova plotësisht WOT për shkak të një gabimi me murin e zjarrit. rules_allow - ky është sigurimi ynë ndaj rasteve të tilla. Nëse kemi bërë një gabim diku me murin e zjarrit, diçka është bllokuar diku, ne gjithmonë mund të dërgojmë një të kushtëzuar 0.0/0për të marrë shpejt gjithçka. Më vonë do të rregullojmë gjithçka me dorë.
Komplete të tjera
Mund të shtoni çdo grup tjetër në hapësirë $IPSETS$.
Per cfare? Ndonjëherë dikush ka nevojë për ipset, për shembull, për të imituar mbylljen e një pjese të grupit. Kushdo mund të sjellë çdo grup, t'i emërojë ato dhe ato do të merren nga Konsulli. Në të njëjtën kohë, grupet ose mund të marrin pjesë në rregullat iptables ose të veprojnë si një ekip NOOP: Konsistenca do të ruhet nga demon.
Anëtarët
Më parë, ishte kështu: përdoruesi u lidh me rrjetin dhe merrte parametra përmes domenit. Para ardhjes së mureve të zjarrit të gjeneratës së re, Cisco nuk dinte të kuptonte se ku ishte përdoruesi dhe ku ishte IP. Prandaj, qasja u dha vetëm përmes emrit të hostit të makinës.
çfarë bëmë? Kemi ngecur në momentin që morëm adresën. Zakonisht kjo është dot1x, Wi-Fi ose VPN - gjithçka kalon përmes RADIUS. Për çdo përdorues, ne krijojmë një grup sipas emrit të përdoruesit dhe vendosim një IP në të me një TTL që është e barabartë me dhcp.lease të tij - sapo të skadojë, rregulli do të zhduket.
Tani mund të hapim akses në shërbime, si grupet e tjera, me emrin e përdoruesit. Ne e kemi hequr dhimbjen nga emrat e hosteve kur ato ndryshojnë dhe ia kemi hequr barrën inxhinierëve të rrjetit sepse ata nuk kanë më nevojë për Cisco. Tani vetë inxhinierët regjistrojnë akses në serverët e tyre.
Izolimi
Në të njëjtën kohë, filluam të çmontojmë izolimin. Menaxherët e shërbimit morën një inventar dhe ne analizuam të gjitha rrjetet tona. Le t'i ndajmë në të njëjtat grupe dhe në serverët e nevojshëm grupet u shtuan, për shembull, për të mohuar. Tani i njëjti izolim skenik përfundon në rregullat_mohimi i prodhimit, por jo në vetë produksionin.
Skema funksionon shpejt dhe thjesht: ne heqim të gjitha ACL-të nga serverët, shkarkojmë harduerin dhe zvogëlojmë numrin e VLAN-ve të izoluara.
Kontrolli i integritetit
Më parë, ne kishim një shkas të veçantë që raportonte kur dikush ndryshonte manualisht një rregull të murit të zjarrit. Po shkruaja një liter të madh për të kontrolluar rregullat e murit të zjarrit, ishte e vështirë. Integriteti tani kontrollohet nga BEFW. Ai siguron me zell që rregullat që ai bën të mos ndryshojnë. Nëse dikush ndryshon rregullat e firewall-it, ai do të ndryshojë gjithçka përsëri. "Kam krijuar shpejt një përfaqësues që të mund të punoja nga shtëpia" - nuk ka më mundësi të tilla.
BEFW kontrollon ipset nga shërbimet dhe lista në befw.conf, rregullat e shërbimeve në zinxhirin BEFW. Por nuk monitoron zinxhirë dhe rregulla të tjera dhe ipset të tjera.
Mbrojtja nga përplasja
BEFW ruan gjithmonë gjendjen e fundit të mirë të njohur drejtpërdrejt në strukturën binare të gjendjes. Nëse diçka shkon keq, ajo gjithmonë kthehet në këtë gjendje.bin.
Ky është sigurim ndaj funksionimit të paqëndrueshëm të Konsullit, kur nuk ka dërguar të dhëna ose dikush ka gabuar dhe ka përdorur rregulla që nuk mund të zbatohen. Për të siguruar që ne të mos mbetemi pa një mur zjarri, BEFW do të kthehet në gjendjen më të fundit nëse ndodh një gabim në çdo fazë.
Në situata kritike, kjo është një garanci që do të na mbetet një mur zjarri që funksionon. Ne hapim të gjitha rrjetet gri me shpresën që administratori të vijë dhe ta rregullojë. Një ditë do ta vendos këtë në konfigurime, por tani kemi vetëm tre rrjete gri: 10/8, 172/12 dhe 192.168/16. Brenda Konsullit tonë, kjo është një veçori e rëndësishme që na ndihmon të zhvillohemi më tej.
Demo: gjatë raportit, Ivan demonstron modalitetin demo të BEFW. Është më e lehtë të shikosh demonstrimin . Ofrohet kodi burimor i demonstrimit .
Grackë
Unë do t'ju tregoj për defektet që kemi hasur.
ipset add set 0.0.0.0/0. Çfarë ndodh nëse shtoni 0.0.0.0/0 në ipset? A do të shtohen të gjitha IP-të? A do të jetë e disponueshme qasja në internet?
Jo, do të kemi një problem që na kushtoi dy orë pushim. Për më tepër, defekti nuk ka funksionuar që nga viti 2016, ai ndodhet në RedHat Bugzilla me numrin #1297092 dhe e gjetëm rastësisht - nga raporti i një zhvilluesi.
Tani është një rregull i rreptë në BEFW që 0.0.0.0/0 kthehet në dy adresa: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < skedar. Çfarë bën ipset kur i thua restore? A mendoni se funksionon njësoj si iptables? A do të rikuperojë të dhënat?
Asgjë e tillë - bën një shkrirje, dhe adresat e vjetra nuk shkojnë askund, ju nuk e bllokoni hyrjen.
Ne gjetëm një defekt gjatë testimit të izolimit. Tani ekziston një sistem mjaft kompleks - në vend të restore duke u mbajtur create temp, atëherë restore flush temp и restore temp. Në fund të shkëmbimit: për atomicitetin, sepse nëse e bëni atë së pari flush dhe në këtë moment arrin një paketë, ajo do të hidhet dhe diçka do të shkojë keq. Pra, ka pak magji të zezë atje.
konsull kv marr -datacenter=tjetër. Siç thashë, ne mendojmë se po kërkojmë disa të dhëna, por ose do të marrim të dhëna ose një gabim. Ne mund ta bëjmë këtë nëpërmjet konsullit lokal, por në këtë rast të dyja do të ngrijnë.
Klienti i Konsullit lokal është një mbështjellës mbi API-në HTTP. Por ai thjesht varet dhe nuk i përgjigjet Ctrl+C, ose Ctrl+Z, ose ndonjë gjë tjetër, vetëm kill -9 në tastierën tjetër. Ne e hasëm këtë kur po ndërtonim një grup të madh. Por ne nuk kemi ende një zgjidhje; ne po përgatitemi ta rregullojmë këtë gabim në Konsullin.
Kreu i konsullit nuk po përgjigjet. Masteri ynë në qendrën e të dhënave nuk po përgjigjet, ne mendojmë: "Ndoshta algoritmi i rizgjedhjes do të funksionojë tani?"
Jo, nuk do të funksionojë dhe monitorimi nuk do të tregojë asgjë: Konsulli do të thotë se ka një indeks angazhimi, një drejtues është gjetur, gjithçka është në rregull.
Si ta trajtojmë këtë? service consul restart në cron çdo orë. Nëse keni 50 serverë, nuk ka punë të madhe. Kur të jenë 16 të tilla, do të kuptoni se si funksionon.
Përfundim
Si rezultat, ne morëm avantazhet e mëposhtme:
- Mbulim 100% i të gjitha makinerive Linux.
- Speed.
- Automatizimi.
- Ne çliruam inxhinierët e pajisjeve dhe rrjeteve nga skllavëria.
- Janë shfaqur mundësi integrimi që janë pothuajse të pakufishme: edhe me Kubernetes, madje edhe me Ansible, madje edhe me Python.
Cons: Konsulli, me të cilin tani duhet të jetojmë, dhe kostoja shumë e lartë e gabimit. Si shembull, një herë në orën 6:XNUMX (prime time në Rusi) po redaktoja diçka në listat e rrjeteve. Ne po ndërtonim vetëm izolimin në BEFW në atë kohë. Kam bërë një gabim diku, duket se tregova maskën e gabuar, por gjithçka ra në dy sekonda. Monitorimi ndizet, personi ndihmës në detyrë vjen me vrap: "Kemi gjithçka!" Shefi i departamentit u gri kur i shpjegoi biznesit pse ndodhi kjo.
Kostoja e gabimit është aq e lartë sa ne kemi dalë me procedurën tonë komplekse të parandalimit. Nëse e zbatoni këtë në një vend të madh prodhimi, nuk keni nevojë t'i jepni të gjithëve një shenjë master mbi Konsullin. Kjo do të përfundojë keq.
Kosto. Kam shkruar kodin vetëm për 400 orë. Ekipi im prej 4 personash shpenzon 10 orë në muaj në mbështetje për të gjithë. Krahasuar me çmimin e çdo muri zjarri të gjeneratës së re, është falas.
Planet. Plani afatgjatë është gjetja e transportit alternativ për të zëvendësuar ose plotësuar Konsullin. Ndoshta do të jetë Kafka ose diçka e ngjashme. Por në vitet e ardhshme ne do të jetojmë në Konsull.
Planet e menjëhershme: integrim me Fail2ban, me monitorim, me nftables, mundësisht me shpërndarje të tjera, metrikë, monitorim të avancuar, optimizim. Mbështetja e Kubernetes është gjithashtu diku në plane, sepse tani kemi disa grupime dhe dëshirë.
Më shumë nga planet:
- kërkimi për anomali në trafik;
- menaxhimi i hartave të rrjetit;
- Mbështetje Kubernetes;
- montimi i paketave për të gjitha sistemet;
- Ueb-UI.
Ne po punojmë vazhdimisht për zgjerimin e konfigurimit, rritjen e metrikës dhe optimizimin.
Bashkohuni me projektin. Projekti doli të ishte i lezetshëm, por, për fat të keq, është ende një projekt me një person. Eja ne dhe përpiquni të bëni diçka: angazhohuni, testoni, sugjeroni diçka, jepni vlerësimin tuaj.
Ndërkohë ne po përgatitemi për , e cila do të zhvillohet më 6 dhe 7 prill në Shën Petersburg dhe ne ftojmë zhvilluesit e sistemeve me ngarkesë të lartë . Folësit me përvojë tashmë e dinë se çfarë të bëjnë, por për ata që janë të rinj në të folur ne rekomandojmë të paktën . Pjesëmarrja në konferencë si folës ka një sërë përparësish. Ju mund të lexoni se cilat, për shembull, në fund .
Burimi: www.habr.com