Në vitin 2010, kompania kishte 50 serverë dhe një model të thjeshtë rrjeti: backend, frontend dhe firewall. Numri i serverëve po rritej, modeli po komplikohej: staging, VLAN të izoluar me ACL, më pas VPN me VRF, VLAN me ACL në L2, VRF me ACL në L3. Po ju lakohet koka? Do të bëhet më argëtuese.
Kur numri i serverëve arriti në 16,000, punimi pa lot me një numër kaq të madh segmentesh heterogjene u bë i pamundur. Prandaj, u mendua një zgjidhje tjetër. U mor një grup Netfilter, iu shtua Consul si burim të dhënash, dhe kështu u krijua një firewall i shpejtë dhe të shpërndarë. Kjo zëvendësoi ACL-në në routera dhe u përdor si firewall i jashtëm dhe të brendshëm. Për menaxhimin dinamik të mjetit, u zhvillua një sistem BEFW, i cili u përdor kudo: nga menaxhimi i qasjes së përdoruesve në rrjetin produktiv deri te izolimi i segmenteve të rrjetit nga njëri-tjetri.
Si funksionon gjithçka dhe pse ia vlen të shikoni këtë sistem, do të tregojë Ivan Agarov () — udhëheqësi i grupit të sigurisë së infrastrukturës në njësinë e Maintenance në Qendren e Zhvillimit të Minskut të kompanisë. Ivan është një adhurues i SELinux, i pëlqen Perl, shkruan kod. Si udhëheqës i grupit të sigurisë, ai punon rregullisht me log-et, back-up-et dhe R&D për të mbrojtur Wargaming nga hackerat dhe për të siguruar funksionimin e të gjithë serverëve të lojërave në kompaninë.
Historiku
Para se të flas se si e bëmë këtë, do të tregoj se si erdhëm në këtë pikë dhe pse ishte e nevojshme. Për këtë, do të rikthehemi në 9 vjet më parë: viti 2010, sapo ishin paraqitur World of Tanks. Kompania Wargaming kishte rreth 50 serverë.
Grafiku i rritjes së serverëve të kompanisë.
Ne kishim një model rrjeti. Për atë kohë, ishte optimal.
Modeli i rrjetit në 2010.
Në frontend jetojnë djemtë e këqinjtë që duan të na thyejnë, por aty ka një firewall. Në backend nuk ka firewall, por aty janë 50 serverë, të gjithë i njohim. Të gjitha funksionon mirë.
Në 4 vitet e fundit, parku i serverëve u rrit me 100 herë, duke arritur në 5000. U shfaqën rrjetet e para të izoluara — staging: ato nuk mund të shkojnë në prodhim, dhe aty shpesh lëviznin gjëra që mund të ishin të rrezikshme.
Modeli i rrjetit në 2014.
Për inercinë, përdorëm të njëjtin hardware, dhe gjithë puna u zhvillua në VLAN të izoluara: për VLAN shkruheshin ACL që lejojnë ose ndalojnë një lidhje të caktuar.
Në vitin 2016, numri i serverëve arriti në 8000. Wargaming përthithi estudio të tjera, u shfaqën rrjete partnere të shtesës. Duket sikur janë tonat, por nuk janë plotësisht: për partnerët, VLAN shpesh nuk funksionon, dhe është e nevojshme të përdoret VPN me VRF, izolimet bëhen më të komplikuara. Një përzierje izolimesh ACL u rrit.
Modeli rrjetor në vitin 2016.
Në fillim të vitit 2018, parku i makinave u rrit në 16,000. Ishin 6 segmente dhe të tjerat nuk i llogaritëm, përfshirë ato të mbyllura, ku ruheshin të dhënat financiare. U shfaqën rrjetet me enë (Kubernetes), DevOps, rrjetet cloud, të lidhura përmes VPN, për shembull, nga IVS. Rregullat ishin shumë të shumta — ishte e dhimbshme.
Modeli rrjetor dhe metodat e izolimit në vitin 2018.
Për izolim përdorëm: VLAN me ACL në L2, VRF me ACL në L3, VPN dhe shumë gjëra të tjera. Shumë.
Problemet
Të gjithë jetojnë me ACL dhe VLAN. Çfarë nuk shkon? Për këtë pyetje do të përgjigjet Garold, i cilin fsheh dhimbjen.
Ishte shumë probleme, por të masive — pesë.
- Rritje geometrike e çmimit për rregulla të reja. Çdo rregull i ri shtohej më gjatë se ai i mëparshmi, sepse duhej parë së pari nëse nuk kishte një rregull të tillë më parë.
- Nuk ka firewall brenda segmenteve. Segmentet u ndanë ndonjëherë nga njëra-tjetra, brenda tashmë nuk kishte mjaft burime.
- Rregullat u aplikuan me ngadalë. Me duar, një rregull lokal operatoret mund ta shkruanin për një orë. Një rregull global merrte disa ditë.
- Vështirësi me auditimin e rregullave. Saktësisht, ai ishte i pamundur. Rregullat e para u shkruan që në vitin 2010, dhe pjesa më e madhe e autorëve të tyre nuk punonte më në kompani.
- Niveli i ulët i kontrollit mbi infrastrukturën. Kjo është problemi kryesor — ne nuk e dinim mirë se çfarë ndodhte me ne.
Kështu dukej inxhinieri rrjetor në vitin 2018, kur dëgjonte: "Duhet edhe pak ACL".
Zgjidhjet
Në fillim të vitit 2018 u vendos që të merreshin masa për këtë.
Çmimi i integrimeve rritet në mënyrë të vazhdueshme. Pika fillestare ishte që qendrat e mëdha të të dhënave nuk mbështetnin më VLAN të izoluar dhe ACL, sepse kishte mbaruar memorja në pajisje.
Zgjidhja: hoqëm faktorët njerëzorë dhe automatizuam maksimalisht ofrimin e aksesit.
Rregullat e reja aplikohen ngadalë. Zgjidhja: të përshpejtohet aplikimi i rregullave, ta bëjmë atë të shpërndarë dhe paralel. Për këtë nevojitet një sistem i shpërndarë, që rregullat të dërgoheshin vetë, pa rsync ose SFTP në mijëra sisteme.
Mungesa e firewall-it brenda segmenteve. Firewalli brenda segmenteve filloi të na arrinte kur shërbime të ndryshme shfaqeshin brenda një rrjeti. Zgjidhja: përdorimi i firewalls në nivelin e hostit — firewalls të bazuara në host. Praktikisht në çdo vend kemi Linux, dhe kudo ka iptables, kështu që kjo nuk është një problem.
Vështirësi me auditetin e rregullave. Zgjidhja: të ruajmë të gjitha rregullat në një vend të vetëm për pasqyrë dhe menaxhim, kështu që mund të auditojmë gjithçka.
Nivel i ulët kontrolli mbi infrastrukturën. Zgjidhja: të bëjmë një inventarizim të gjithë shërbimeve dhe aksesit midis tyre.
Ky është më shumë një proces administrativ sesa teknik. Ndonjëherë kemi 200-300 lëshime të reja në javë, veçanërisht gjatë fushatave dhe festave. Dhe kjo është vetëm për një ekip të DevOps. Me një numër të tillë lëshimesh, është e pamundur të kuptohet cilat porte, IP, integrime nevojiten. Prandaj, na nevojiteshin menaxherë të shërbimeve të trajnuar posaçërisht, të cilët pyetnin ekipet: "Çfarë ka në të vërtetë dhe përse e keni ngritur këtë?"
Pas gjithë atij që ne lançuam, inxhinieri i rrjetit në vitin 2019 dukej kështu.
Consul
Vendosëm që gjithçka që gjetëm me ndihmën e menaxherëve të shërbimeve, ta vendosim në Consul dhe nga aty do të shkruajmë rregullat e iptables.
Si vendosëm ta bëjmë këtë?
- Do të mbledhim të gjitha shërbimet, rrjetet dhe përdoruesit.
- Do të bëjmë rregulla iptables mbi këtë bazë.
- Do ta automatizojmë kontrollin.
- ….
- PROFIT.
Consul nuk është një API i largët, ai mund të punojë në çdo nyje dhe të shkruajë në iptables. Mbetej vetëm të imagjinonim mjete automatike kontrolli, që do të pastronin të tepërtën, dhe pjesa më e madhe e problemeve do të zgjidhej! Pjesa tjetër do ta përmirësonim gjatë procesit.
Pse Consul?
E ka treguar veten mirë. Në vitet 2014-15 ne e përdorëm si backend për Vault, ku ruajmë fjalëkalimet.
Nuk humb të dhëna.. Gjatë përdorimit të Consul, nuk ka humbur asnjë të dhënë gjatë ndonjë avarie. Kjo është një avantazh i madh për sistemin e menaxhimit të firewallit.
Lidhjet P2P përshpejtojnë përhapjen e ndryshimeve.. Me P2P, të gjitha ndryshimet vijnë shpejt, nuk nevojitet të presësh me orë të tëra.
API REST i përshtatshëm. Ne shqyrtuam gjithashtu Apache ZooKeeper, por nuk ka API REST, do të duhej të vendosnim disa zgjidhje të përkohshme.
Punon si një depo e çelësave (KV), po ashtu edhe si një katalog (Zbulojnë Shërbimet).. Mund të ruash menjëherë shërbimet, katalogët, qendrat e të dhënave. Kjo është e përshtatshme jo vetëm për ne, por edhe për ekipet fqinj, pasi duke ndërtuar një shërbim global, ne mendojmë me shkallë.
Shkruar në Go, i cili është pjesë e stek Wargaming. Ne e dashuri për këtë gjuhë, kemi shumë zhvillues Go.
Një sistem të fuqishëm ACL. Me ndihmën e ACL në Consul, mund të menaxhojmë se kush dhe çfarë mund të shkruajë. Ne garantojmë që rregullat e firewall-it nuk do të përputhen më me asgjë tjetër dhe se nuk do të kemi probleme me këtë.
Por Consul ka edhe disavantazhe.
- Nuk shtrihen brenda qendrës së të dhënave, nëse nuk keni versionin biznes. Ai shtrihen vetëm nëpërmjet federatës.
- Shumë varës nga cilësia e rrjetit dhe ngarkesës së serverëve. Consul nuk do të funksionojë si një server në një server të ngarkuar, nëse ka vonesa në rrjet, për shembull, shpejtësi të paparashikueshme. Kjo është e lidhur me lidhjet P2P dhe modelet e shpërndarjes së përditësimeve.
- Sfidat e monitorimit të disponueshmërisë. Statusi i Consul mund të tregojë se gjithçka është mirë, ndërsa ai ka vdekur prej kohe.
Shumicën e këtyre problemeve i kemi zgjidhur gjatë përdorimit të Consul, prandaj e zgjodhëm atë. Kompania ka planifikuar një backend alternativ, por ne mësuam të trajtojmë problemet dhe për momentin jetojmë me Consul.
Si funksionon Consul
Në një qendër të dhënash të supozuar do të vendosim serverë - nga tre deri në pesë. Një ose dy serverë nuk do të mjaftojnë: ata nuk do të jenë në gjendje të organizojnë kuorum dhe të vendosin se kush ka të drejtë dhe kush gabon kur të dhënat nuk përputhen. Më shumë se pesë s'ka kuptim, performanca do të jetë e ulët.
Klientët lidhen me serverat në çdo rend: të njëjtat agjentë, vetëm me flamurin server = false.
Pas kësaj, klientët marrin një listë lidhjesh P2P dhe ndajnë lidhje mes tyre.
Në nivel global, ne lidhim disa qendra të të dhënave mes tyre. Ato gjithashtu lidhen P2P dhe komunikojnë.
Kur duam të marrim të dhëna nga një tjetër qendër të dhënash, kërkesa shkon nga serveri në server. Kjo skemë quhet protokolli Serf. Protokolli Serf, si dhe Consul, është një zhvillim i HashiCorp.
Disa fakti të rëndësishme për Consul
Consul ka dokumentacion që shpjegon funksionimin e tij. Do të sjell vetëm disa fakte për të cilat vlen të dini.
Serverat e Consul zgjedhin një master nga mes atyre që votojnë. Consul zgjedh masterin nga lista e serverëve për çdo qendër të dhënash, dhe të gjitha kërkesat shkojnë vetëm te ai, pavarësisht numrit të serverëve. Ngërçi i masterit nuk çon në rizgjedhje. Nëse masteri nuk është zgjedhur - kërkesat nuk shërbehen nga askush.
Dëshironit të bëni përmasim horizontal? Më vjen keq, jo.
Kërkesa në një qendër të dhënash tjetër shkon nga masteri deri te masteri, pavarësisht se në cilin server ka arritur. Masteri i zgjedhur merr 100% ngarkesës, përveç ngarkesës për përparimin e kërkesave. Një kopje e saktë e të dhënave ekziston në të gjithë serverët e qendrës së të dhënave, por përgjigjet vetëm një.
Mënyra e vetme për të shkallëzuar është të aktivizoni modalitetin stale në klient.
Në modalitetin stale mund të përgjigjeni pa kvorum. Ky është një modalitet në të cilin heqim dorë nga qëndrueshmëria e të dhënave, por lexojmë pak më shpejt se zakonisht, dhe çdo server përgjigjet. Natyrisht, regjistrimi bëhet vetëm përmes masterit.
Consul nuk kopjon të dhëna midis qendrave të të dhënave.. Në mbledhjen e federatës, çdo server do të ketë vetëm të dhënat e tij. Për të tjerat, ai gjithmonë kërkon ndihmën e dikujt tjetër.
Aksioni i atomizuar nuk garanton jashtë transaksionit. Mbani mend se diçka mund të ndryshohet jo vetëm nga ju. Nëse dëshironi ndryshe, bëni një transaksion me bllokim.
Operacionet e bllokimit nuk garantojnë bllokimin. Kërkesa shkon nga masteri në master, e jo direkt, kështu që nuk ka garanci që bllokimi do të funksionojë kur ju bëni bllokimin, për shembull, në një qendër të dhënash tjetër.
ACL gjithashtu nuk garanton qasje (në shumë raste). ACL mund të mos funksionojë, sepse ruhet në një qendër të dhënash të federatës — në qendrën e të dhënave ACL (DC Kryesor). Nëse DC juaj nuk përgjigjet, ACL do të ndalojë.
Një master i ngritur do të çojë në ngritjen e tërë federatës. Për shembull, në një federatë me 10 qendra të të dhënash, dhe në njëra prej tyre ka një rrjet të keq, dhe një master bie. Të gjithë ata që komunikojnë me të do të ngjiten në një rreth: po shkon një kërkesë, nuk ka përgjigje për të, rrjedha ngec. Nuk do të keni mundësi të dini kur do të ndodhë kjo, thjesht pas një ore ose dy do të bjerë e gjithë federata. Nuk do të keni mundësi të bëni asgjë për këtë.
Statusi, kvorumi dhe zgjedhjet përpunohen në një rrjedh të veçantë. Nuk do të ketë rizgjedhje, statusi nuk do të tregojë asgjë. Ju mendoni se keni një Consul aktiv, kërkoni, dhe nuk ndodh asgjë — nuk ka përgjigje. Por statusi tregon se gjithçka është në rregull.
Ne kemi hasur në këtë problem, na është dashur të riparojmë pjesë specifike të qendrave të të dhënave për ta shmangur atë.
Në versionin e biznesit të Consul Enterprise nuk ka disa nga disavantazhet e mësipërme.. Ai është shumë funksione të dobishme: zgjedhja e votuesve, shpërndarja, shkallëzimi. Ka vetëm një "por" - sistemi i licencimit për sistemin e shpërndarë është shumë i shtrenjtë.
Këshillë: rm -rf /var/lib/consul - ilaç për të gjitha sëmundjet e agjentit. Nëse diçka nuk funksionon, thjesht fshini të dhënat tuaja dhe ngarkoni të dhënat nga kopja. Me shumë gjasa, Consul do të funksionojë.
BEFW
Tani do të flasim për atë që kemi shtuar në Consul.
- është një akronim nga BackEndFireWall. Duhej të kishte një emër për produktin kur krijoja depo, në të cilin të vendosja testet e para. Ky emër mbeti.
Shabllonet e rregullave
Rregullat janë shkruar në sintaksën e iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state—state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Të gjitha shkojnë në zinxhirin BEFW, përveç TË KRIJUARA, RELATED dhe localhost. Shablloni mund të jetë çfarëdo, është thjesht një shembull.
Çfarë dobi ka BEFW?
Shërbimet
Kemi një shërbim, gjithmonë ka një port, nodo, në të cilin funksionon. Nga nodoja jonë mund të pyesim lokalish agjentin dhe të kuptojmë se kemi një shërbim. Gjithashtu mund të vendosim etiketat.
Cdo shërbim që është aktiv dhe regjistruar në Consul, kthehet në një rregull të iptables. Kemi SSH - hapim portin 22. Skripti i Bash-it është i thjeshtë: curl dhe iptables, nuk ka nevojë për gjë tjetër.
Klientët
Si të hapim qasje jo për të gjithë, por përzgjedhës? Me emrin e shërbimit, vendosni listat e IP-ve në depozitat KV.
Për shembull, duam që të gjithë nga rrjeti i dhjetë të mund të aksesojnë shërbimin SSH_TCP_22. Shtojmë një fushë të vogël TTL? dhe tani kemi lejet e përkohshme, për shembull, për një ditë.
Qasjet
Lidhim shërbimet dhe klientët: kemi një shërbim, për çdo njësi ka depozitë KV të gatshme. Tani ne ofrojmë qasje jo për të gjithë, por përzgjedhës.
Grupet
Nëse çdo herë do të shkruajmë mijëra IP për qasje, do të lodhemi. Do të krijojmë grupe - një nëngrup të veçantë në KV. Do ta quajmë Alias (ose grupe) dhe do të ruajmë atje grupet sipas të njëjtit parim.
Lidhim: tani mund të hapim SSH jo veçanërisht në P2P, por në një grup të tërë ose disa grupe. Po ashtu ka TTL - mund të shtojmë në grup dhe të largojmë nga grupi përkohësisht.
Integrimi
Problemi ynë është faktori njerëzor dhe automatizimi. Për momentin e kemi zgjidhur kështu.
Ne punojmë me Puppet dhe i transferojmë gjithçka që ka të bëjë me sistemin (kodin e aplikacioneve). Në puppetdb (një PostgreSQL i zakonshëm) ruhet lista e shërbimeve që janë aktivizuar atje, mund t'i gjejmë ato sipas llojit të burimeve. Atje gjithashtu mund të gjejmë se kush e thërret cilën. Po ashtu, kemi një sistem pull request dhe merge request për këtë.
Kemi shkruar befw-sync — një zgjidhje shumë të thjeshtë që ndihmon në transferimin e të dhënave. Fillimisht cookies sync i drejtohen puppetdb. Atje është e konfiguruar HTTP API: kërkojmë cilat shërbime kemi, çfarë duhet bërë. Më pas bëjnë një kërkesë në Consul.
A ka integrim? Po: kemi shkruar rregulla, lejuam pranimin e Pull Request. A duhen ndonjë port ose të shtojmë një host në ndonjë grup? Pull Request, shqyrtim — pa ndonjë “Gjej 200 ACL të tjera dhe provoj diçka me këtë.”
Optimizimi
Ping localhost me një zinxhir rregullash të zbrazët zë 0,075 ms.
Do të shtojmë në këtë zinxhir 10,000 adresat e iptables. Si rezultat, ping do të rritet 5 herë: iptables është plotësisht lineare, trajtimi i çdo adrese merr njëfarë kohe.
Për firewall-in, në të cilin migrojmë mijëra ACL, kemi shumë rregulla, dhe kjo sjell vonesë. Kjo është keq për protokollet e lojërave.
Por nëse ne vendosim 10,000 adresat në ipset ping do të shkurtohet edhe më shumë.
Kuptimi është se "O" (kompleksiteti i algoritmit) për ipset është gjithmonë 1, sa herë që rregullat janë atje. E vërtetë, ka një kufizim — rregullat nuk mund të jenë më shumë se 65,535. Deri tani po e mbajmë kështu: mund t'i kombinojmë, të zgjerojmë, të bëjmë dy ipset në një.
Ruajtja
Një vazhdim logjik i procesit të iteracioneve është ruajtja e informacionit mbi klientët për shërbimin në ipset.
Tani kemi të njëjtin SSH, dhe nuk shkruajmë menjëherë 100 IP, por caktojmë emrin e ipset me të cilin duhet të komunikojmë, dhe rregullin tjetër DROP. Mund ta ndryshojmë në një rregull "Kush nuk është këtu, atëherë DROP", por kështu është më e dukshme.
Tani kemi rregulla dhe sete. Detyra kryesore është të bëjmë një set para se të shkruajmë një rregull, sepse përndryshe iptables nuk do ta regjistrojë rregullin.
Schema e përgjithshme
Në formën e një skeme, gjithçka që kam treguar duket kështu.
Po commit-ojmë në Puppet, gjithçka dërgohet në host, shërbimet janë këtu, ipset atje, dhe kush nuk është regjistruar atje, nuk lejohet.
Lejo & amp; moho
Për të shpërndarë shpejt botën ose për të çaktivizuar dikë shpejt, në fillim të të gjitha zinxhirëve krijuam dy ipset: rules_allow dhe rules_deny. Si funksionon kjo?
Për shembull, dikush krijon ngarkesë në Web-in tonë me bota. Më parë duheshin gjetur log-et e IP-së së tij, t'i drejtoheshin inxhinierëve rrjetë që të gjenin burimin e trafikut dhe ta bllokonin atë. Tani kjo duket ndryshe.
Dërgojmë në Consul, presim 2.5 s, dhe është gati. Duke qenë se Consul ndan shpejt përmes P2P, funksionon kudo, në çdo pjesë të botës.
Një herë e ndalova plotësisht WOT-in, duke u ngatërruar me fireëall-in. rules_allow Kjo është sigurimi ynë për raste të tilla. Nëse gabojmë diku me fireëall-in, diçka do të bllokohet diku, gjithmonë mund të dërgojmë një 0.0/0, për ta ngritur gjithçka shpejt. Më pas do t'i rregullojmë gjithçka me duar.
Grupet e tjera
Mund të shtoni çdo grup tjetër në hapësirë $IPSETS$.
Pse? Ndonjëherë dikush ka nevojë për ipset, për shembull, për të imituar fikjen e ndonjë pjese të klasit. Çdokush mund të sjellë çdo grup, t'i japë emra dhe ata do të merren nga Consul. Këto grupe mund si të marrin pjesë në rregullat iptables, ashtu edhe të jenë si një komandë NOOP: konsistenca do të mbështetet nga demoni.
Përdoruesit
Më parë, përdoruesi lidhej me rrjetin dhe merrte parametrat përmes domain-it. Para se të shfaqeshin fireëall-et e brezit të ri, Cisco nuk dinte të kuptonte se ku ishte përdoruesi dhe ku ishte IP. Prandaj, qasjeja jepeshin vetëm përmes hostname-it të makinës.
Çfarë bëmë ne? U përfshim në momentin e marrjes së adresës. Zakonisht kjo është dot1x, Wi-Fi ose VPN — gjithçka kalon përmes RADIUS. Për çdo përdorues krijojmë një grup sipas emrit të përdoruesit dhe vendosim në të IP me TTL, që është i barabartë me dhcp.lease e tij — sapo të përfundojë, rregulli do të zhduket.
Tani mund të hapim aksesin në shërbime, ashtu si në grupet e tjera, sipas emrit të përdoruesit. E shpëtuam veten nga dhimbja me hostname-in, kur ato ndodhin të ndryshojnë, dhe e heqëm ngarkesën nga inxhinierët rrjetë, sepse ata nuk kanë më nevojë për Cisco. Tani inxhinierët vetë përcaktojnë qasjet në serverat e tyre.
Izolimi
Paralelisht, filluam të shqyrtonim izolimin. Menaxherët e shërbimeve bënë një inventar dhe ne analizuam të gjitha rrjetet tona. Do t'i ndajmë ato në grupe të tilla, dhe në serverët përkatës grupet i shtuam, për shembull, në deny. Tani e njëjta izolim e stagingut përfundon në rules_deny të prodhimit, por jo në prodhimin vetë.
Skema funksionon shpejt dhe thjeshtë: heqim të gjitha ACL-të nga serverët, ngarkojmë pajisjet, ulim numrin e VLAN-eve të izoluara.
Kontrolli i integritetit
Më parë, na kishte një trigger të veçantë që informonte kur dikush ndryshonte rregullin e firewall-it manualisht. Unë shkrova një lintr të madh për kontrollin e rregullave të firewall-it, ishte e vështirë. Tani, integritetin e kontrollon BEFW. Ai e ndjek me rigorozitet që rregullat që ai krijon të mos ndryshojnë. Nëse dikush ndryshon rregullat e firewall-it, ai do t'i kthejë sërish në gjendjen e mëparshme. "E ngrita shpejt një proxy për të punuar nga shtëpia" — këto mundësi nuk ekzistojnë më.
BEFW kontrollon ipset nga shërbimet dhe lista në befw.conf, rregullat e shërbimeve në zinxhirin BEFW. Por nuk ndjek zinxhirë të tjerë dhe rregulla dhe ipset të tjera.
Mbrojtje nga defektet
BEFW gjithmonë ruan gjendjen e fundit të suksesshme drejtpërdrejt në strukturën binar state.bin. Nëse ndodhi ndonjë problem, ai gjithmonë kthehet prapa në këtë state.bin.
Kjo është një sigurim nga puna jo e qëndrueshme e Consul, kur ai nuk dërgon të dhëna ose dikush gabon dhe përdor rregulla që nuk mund të aplikohen. Që të mos mbetemi pa firewall, BEFW do të kthehet në gjendjen e fundit, nëse ndonjëherë ndodh një gabim.
Në situata kritike, kjo është garancia që ne do të qëndrojmë me një firewall funksional. Ne hapim të gjitha rrjetet e grisë në shpresë se administratori do të vijë dhe do ta rregullojë. Ndonjëherë do ta nxjerr këtë në konfigurime, por tani kemi thjesht tre rrjete gri: 10/8, 172/12 dhe 192.168/16. Në kuadër të Consul tonë, kjo është një veçori e rëndësishme që ndihmon në avancimin më tej.
Demo: gjatë prezantimit, Ivan tregon modalitetin demo të funksionimit të BEFW. Është më e lehtë të shikohet demoja në . Kodi burimor i demos është i disponueshëm .
Pengesa
Do t'ju flas për bug-at me të cilat na u desh të përballemi.
ipset add set 0.0.0.0/0. Çfarë do të ndodhë nëse shtoni në ipset 0.0.0.0/0? A do të shtohen të gjitha IP-të? A do të hapet qasja në internet?
Jo, do të marrim një bug që na kushtoi dy orë ndalesë. Për më tepër, bug-u nuk punon që nga viti 2016, ndodhet në RedHat Bugzilla me numrin #1297092, dhe ne e gjetëm atë rastësisht — nga raporti i zhvilluesit.
Tani në BEFW ka një rregull të fortë që 0.0.0.0/0 shndërrohet në dy adresa: 0.0.0.0/1 dhe 128.0.0.0/1.
ipset restore set < file. Çfarë bën ipset kur i thoni restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Nuk ka asgjë të ngjashme — ai bën një bashkim, dhe adresat e vjetra nuk zhduken, qasja nuk e mbyllni.
E gjetëm bug-un kur testonim izolimin. Tani ka një sistem mjaft të komplikuar — në vend të restore po krijohet create temp, pastaj restore flush temp dhe restore temp. Në fund swap: për atomikën, sepse nëse fillimisht bëni flush dhe në këtë moment do të vijë një paketë, ajo do të refuzohet dhe diçka do të shkojë keq. Prandaj ka pak magji të zezë.
consul kv get -datacenter=other. Siç e thashë edhe më parë, mendojmë se po kërkojmë disa të dhëna, por do të marrim ose të dhëna, ose një gabim. Mund ta bëjmë këtë përmes Consul lokal, por dhe në këtë rast do të ngrijë, dhe e dyta.
Klienti lokal i Consul është një mbulim mbi API-në HTTP. Por ai thjesht ngrin dhe nuk përgjigjet as në Ctrl+C, as në Ctrl+Z, asgjë, vetëm në kill -9 në konsolën fqinjësore. Kemi hasur këtë kur ndërtuam një grumbull të madh. Por për momentin nuk kemi ndonjë zgjidhje, po e përgatisim për ta rregulluar këtë gabim në Consul.
Kryesori i Consul nuk po përgjigjet. Ne nuk kemi përgjigje nga masteri në data-qendër, mendojmë: "Me siguri tani do të aktivizohet algoritmi i ripërzgjedhjes?"
Jo, nuk do të aktivizohet, dhe monitorimi nuk do të tregojë asgjë: Consul do të thotë se indeksi i angazhimit ekziston, lideri është gjetur, të gjitha janë në rregull.
Si po e lutemi këtë? service consul restart në cron çdo orë. Nëse keni 50 serverë - nuk është aq e frikshme. Kur të keni 16,000, do ta kuptoni se si funksionon.
Përfundimi
Në fund, morëm këto përfitime:
- 100% mbulimin e të gjitha makinave Linux.
- Shpejtësia.
- Automatizimin.
- Çliruan harduerin dhe inxhinierët e rrjetit nga skllavëria.
- Kemi përmirësuar mundësitë për integrim, të cilat janë praktikisht të pakufizuara: me Kubernetes, me Ansible, me Python.
Kundrat: Consul, me të cilin tani duhet të jetojmë, dhe një çmim shumë i lartë për gabim. Si një shembull, një herë në 6 pasdite (ora kryesore në Rusi) po rregulloja diçka në listat e rrjetit. Atëherë sapo po ndërtoshim izolimin në BEFW. Gabova diku, mendon se caktova një maskë të gabuar, por gjithçka u shemb në dy sekonda. Monitorimi ndizet, dhe vijnë mbështetësit: "Gjithçka është bllokuar!" Shefi i departamentit bëri lesht kur shpjegonte biznesit pse ndodhi kjo.
Çmimi i gabimit është aq i lartë, saqë shpikëm një procedurë komplekse për parandalimin. Nëse do ta zbatoni këtë në një prodhim të madh, mos jepni master-tokenin mbi Consul për të gjithë sa herë. Kjo do të përfundojë keq.
Kostoja. Kam shkruar kodin për 400 orë vetëm. Në mbështetje, ekipi im prej 4 personash shpenzon 10 orë në muaj për të gjithë. Krahasuar me çmimin e çdo firewalla të brezi të ri, kjo është falas.
Planet. Plani afatgjatë është të gjejmë një transport alternativ si zëvendësim apo shtesë për Consul. Ndoshta do të jetë Kafka ose diçka e ngjashme. Por në vitet në vazhdim do të jetojmë me Consul.
Planet më të afërta: integrimi me Fail2ban, me monitorimin, me nftables, ndoshta, me distribucione të tjera, metrika, monitorim të avancuar, optimizim. Në planet është edhe mbështetje për Kubernetes, sepse tani kemi disa klasterë dhe dëshirë.
Edhe nga planet:
- kërkimi i anomali në trafik;
- menaxhimi i hartës së rrjetit;
- mbështetje për Kubernetes;
- ndërtimi i paketave për të gjitha sistemet;
- Web-UI.
Përherë punojmë për zgjerimin e konfigurimit, rritjen e metrikave dhe optimizimin.
Bashkohuni me projektin. Projekti doli i shkëlqyer, por, fatkeqësisht, deri tani është një projekt i një njeriu. Ejani në dhe provojeni diçka: bëni commit, testoni, propozojeni ndonjë gjë, jepni vlerësimin tuaj.
Ndërkohë, po përgatitemi për , e cila do të mbahet më 6 dhe 7 prill në Shën Petersburg, dhe ftojmë zhvilluesit e sistemeve me ngarkesë të lartë . Folësit me përvojë e dinë tashmë se çfarë duhet të bëjnë, kurse ne fillestarëve në prezantime rekomandojmë të paktën . Pjesëmarrja në konferencë si folës ka disa avantazhe. Cilat, mund të lexoni, për shembull, në fund .
Burimi: habr.com
