Në vitin 2010, kompania kishte 50 serverë dhe një model të thjeshtë rrjetor: backend, frontend dhe firewall. Numri i serverëve u rrit, modeli u komplikuar: staging, VLAN të izoluara me ACL, pastaj VPN me VRF, VLAN me ACL në L2, VRF me ACL në L3. Është e vështirë për të imagjinuar? Do të bëhet më argëtuese.
Kur serverët arritën në 16,000, ishte e pamundur të funksiononim pa lot me një numër kaq të madh segmentesh të llojllojshme. Prandaj, u shpik një zgjidhje tjetër. Merret staku Netfilter, shtohet Consul si burim të dhënash, dhe rezultati është një firewall i shpejtë dhe të shpërndarë. Ai zëvendësoi ACL-të në routerat dhe u përdor si firewall i jashtëm dhe i brendshëm. Për menaxhim dinamik, është zhvilluar një sistem BEFW, i cili u aplikua kudo: nga menaxhimi i aksesit të përdoruesve në rrjetin produktiv deri te izolimi i segmenteve të rrjetit njëri nga tjetri.
Si funksionon gjithçka dhe pse duhet t'i kushtoni vëmendje këtij sistemi, do na tregojë Ivan Agarikov () — kreu i grupit të sigurisë infrastrukturore në divizionin e Mantenancës në Qendrën e Zhvillimit në Minsk të kompanisë. Ivan është një fan i SELinux, do Perl, shkruan kod. Si kreu i grupit të SIG, punon rregullisht me log-et, backup-et dhe R&D, për të mbrojtur Wargaming nga hakerat dhe për të siguruar funksionimin e të gjithë serverëve të lojrave në kompani.
Kronologjia historike
Para se të tregoj se si e bëmë këtë, do të flas se si arritëm këtu dhe pse ishte e nevojshme. Për këtë, le të kthehemi në 9 vjet më parë: viti 2010, kur sapo ishin shfaqur World of Tanks. Kompania Wargaming kishte rreth 50 serverë.
Grafiku i rritjes së serverëve të kompanisë.
Ne kemi pasur një model rrjeti. Në atë kohë ishte optimal.
Modeli rrjetor në 2010.
Në frontend jetojnë djemtë e këqij që duan të na thyejnë, por aty ka një firewall. Në backend nuk ka firewall, por aty janë 50 serverë, ne i njohim të gjithë. Çdo gjë funksionon mirë.
Në 4 vjet, parku i serverëve u rrit 100 herë, deri në 5000. U shfaqën rrjetet e para të izoluara — staging: ato nuk mund të shkojnë në prodhim, dhe aty shpesh kishte gjëra që mund të ishin të rrezikshme.
Modeli rrjetor në 2014.
Me inercinë vazhduam të përdorim të njëjtat pajisje, dhe e gjithë puna u zhvillua në VLAN të izoluara: për VLAN shkruhen ACL, të cilat lejojnë ose ndalojnë një lidhje të caktuar.
Në vitin 2016, numri i serverëve arriti në 8000. Wargaming bleu studiot e tjera dhe u shfaqën rrjetet e reja partnere. Disa duken tonat, por nuk janë plotësisht: për partnerët, VLAN shpesh nuk punon, kështu që ne përdorim VPN me VRF, izolimet komplikohet. Një përzierje e izolimeve ACL është rritur.
Modeli rrjetor në 2016.
Në fillim të vitit 2018, parku i makinerive u rrit në 16,000. Kishim 6 segmente, dhe të tjerët nuk i kemi llogaritur, duke përfshirë ato të mbyllura, ku ruhej informacioni financiar. Rrjetet kontejner (Kubernetes), DevOps, rrjetet e reja në re, të lidhura përmes VPN, për shembull, nga IVS. Kishte shumë rregulla - ishte e dhimbshme.
Modeli rrjetor dhe mënyrat e izolimit në 2018.
Për izolimin, ne përdorëm: VLAN me ACL në L2, VRF me ACL në L3, VPN dhe shumë më tepër. Shumë të shumta.
Problemet
Të gjithë jetojnë me ACL dhe VLAN. Çfarë është e gabuar? Këtij pyetje do t'i përgjigjet Garold, i cili fsheh dhimbjen.
Ishte shumë problematik, por masivisht - pesë.
- Rritja geometrike e çmimit për rregullat e reja. Çdo rregull i ri merrej më gjatë se ai i mëparshmi, sepse duhej fillimisht të shikohej nëse tashmë ekziston një rregull i tillë.
- Nuk ka firewall brenda segmenteve. Segmentet ishin ndarë ndaras, brenda nuk kishte burime të mjaftueshme.
- Rregullat zbatoheshin ngadalë. Një operator mund të shkruajë një rregull lokal me dorë brenda një ore. Një global zgjaste disa ditë.
- Vështirësi me audiencën e rregullave. Më saktë, ai ishte i pamundur. Rregullat e para u shkruan ende në vitin 2010, dhe shumica e autorëve të tyre nuk punonin më në kompani.
- Niveli i ulët i kontrollit mbi infrastrukturën. Kjo është problemi kryesor - ne nuk e dinim mirë se çfarë po ndodhte realisht.
Kështu dukej inxhinieri rrjetor në vitin 2018, kur dëgjoi: "Na nevojitet edhe pak ACL".
Zgjidhjet
Në fillim të vitit 2018, u vendos të bëhej diçka për këtë.
Çmimi i integrimeve po rritet vazhdimisht. Pika e nisjes ishte se qendrat e mëdha të të dhënave pushuan së mbështeturi VLAN dhe ACL të izoluara, sepse përfundoi memoria në pajisje.
Zgjidhja: heqja e faktorëve njerëzorë dhe sa më shumë automatizimin e ofrimit të qasjes.
Rregullat e reja aplikohen ngadalë. Zgjidhja: përshpejtimi i aplikimit të rregullave, duke e bërë atë të shpërndarë dhe paralel. Për këtë nevojitet një sistem i shpërndarë, në mënyrë që rregullat të dërgoheshin vetë, pa rsync ose SFTP në një mijë sisteme.
Mungesa e firewall-it brenda segmenteve. Firewall brenda segmenteve filloi të na arrijë kur në një rrjet të vetëm shfaqeshin shërbime të ndryshme. Zgjidhja: të përdorim firewall në nivel hosti — host-based firewalls. Praktikisht kudo kemi Linux, dhe kudo ka iptables, kjo nuk është problem.
Vështirësi me auditet e rregullave. Zgjidhja: të ruajmë të gjitha rregullat në një vend të vetëm për shqyrtim dhe menaxhim, kështu që mund të auditojmë gjithçka.
Nivel i ulët kontrolli mbi infrastrukturën. Zgjidhja: të kryejmë një inventarizim të të gjitha shërbimeve dhe qasjeve midis tyre.
Ky është një proces më administrativ sesa teknik. Ndonjëherë kemi 200-300 lëshime të reja në javë, veçanërisht gjatë fushatave dhe festave. Kjo është vetëm për një ekip të DevOps tanë. Me këtë numër të lëshimeve, është e pamundur të identifikosh se cilat porte, IP, integrime janë të nevojshme. Prandaj na duhej menaxherë shërbimesh të trajnuar posaçërisht, të cilët intervistuan ekipet: 'Çfarë ka dhe pse e keni ngritur këtë?'
Pas gjithë asaj që lançuam, inxhinieri rrjetit në vitin 2019 dukej tashmë kështu.
Consul
Vendosëm që gjithçka që gjetëm me ndihmën e menaxherëve të shërbimeve do ta vendosnim në Consul dhe nga aty do të shkruajmë rregullat e iptables.
Si e vendosëm ta bëjmë këtë?
- Të mbledhim të gjitha shërbimet, rrjetet dhe përdoruesit.
- Të krijojmë rregulla iptables mbi bazën e tyre.
- Të automatizojmë kontrollin.
- ….
- PROFIT.
Consul nuk është një API i distancuar, ai mund të funksionojë në çdo nod dhe të shkruajë në iptables. Mbete vetëm të krijosh mjete automatike kontrolli, të cilat do të pastrojnë të tepërtat, dhe një pjesë e madhe e problemeve do të zgjidhen! Të tjerat do t'i përshtatim gjatë procesit.
Përse Consul?
E ka treguar veten mirë. Në vitet 2014-15 e kemi përdorur si backend për Vault, ku ruajmë fjalëkalimet.
Nuk humbet të dhëna.. Gjatë përdorimit, Consul nuk ka humbur të dhëna asnjëherë gjatë një aksidenti. Kjo është një avantazh i madh për sistemin e menaxhimit të firewall-it.
Lidhjet P2P përshpejtojnë shpërndarjen e ndryshimeve.. Me P2P, të gjitha ndryshimet mbërrijnë shpejt, nuk nevojitet të presësh me orë.
REST API i përshtatshëm. Kemi shqyrtuar gjithashtu Apache ZooKeeper, por ai nuk ka REST API, do të duhet të përdorim zgjidhje të zakonshme.
Funksionon si një magazinë çelësh (KV), ashtu si një katalog (Service Discovery).. Mund të ruajmë menjëherë shërbime, kataloga dhe qendrat e të dhënave. Kjo është e përshtatshme jo vetëm për ne, por edhe për ekipet fqinje, sepse duke ndërtuar një shërbim global, mendojmë në mënyrë të zgjeruar.
Është shkruar në Go, që bën pjesë në stakun e Wargaming. Ne kemi dashuri për këtë gjuhë, kemi shumë zhvillues Go.
Një sistem i fuqishëm ACL. Me ndihmën e ACL në Consul mund të menaxhojmë se kush dhe çfarë mund të shkruaj. Garantojmë që rregullat e firewall-it nuk do të ndërthuren me asgjë dhe nuk do të kemi probleme me këtë.
Por Consul ka edhe disavantazhe.
- Nuk shkallëzohet brenda një qendre të të dhënave nëse nuk keni versionin biznes. Ai shkallëzohet vetëm përmes federatës.
- Shumë varësie nga cilësia e rrjetit dhe ngarkesa e serverëve. Consul nuk do të funksionojë siç duhet si server në një server të ngarkuar nëse rrjeti ka ndonjë vonesë, për shembull, shpejtësia e paqarë. Kjo është e lidhur me lidhjet P2P dhe modelet e shpërndarjes së azhurnimeve.
- Vështirësi me monitorimin e disponueshmërisë.. Në statusin e Consul mund të thotë se gjithçka është në rregull, kur ai ka vdekur prej kohësh.
Shumicën e këtyre problemeve i zgjidhëm gjatë përdorimit të Consul, prandaj e zgjodhëm. Në kompani ka plane për një backend alternativ, por kemi mësuar të luftojmë me problemet dhe për momentin jetojmë me Consul.
Si funksionon Consul
Në një qendër të dhënash hipotetike do të vendosim serverë — nga tre në pesë. Një ose dy serverë nuk do të mjaftonin: ata nuk do të ishin në gjendje të organizonin quorum dhe të zgjidhnin se kush është i drejtë dhe kush është gabim, kur të dhënat nuk përputhen. Më shumë se pesë nuk ka kuptim, performanca do të bjerë.
Klientët i lidhin me serverët në rend të rastësishëm: po ashtu agjentët, vetëm me flamurin server = false.
Pas kësaj, klientët marrin një listë lidhjesh P2P dhe ndërtosin lidhje mes tyre.
Në nivel global ne i lidhim disa qendra të të dhënave. Ato gjithashtu lidhen P2P dhe komunikojnë.
Kur dëshirojmë të marrim të dhëna nga një tjetër qendër të dhënash, kërkesa shkon nga serveri në server. Ky skemë quhet protokolli Serf. Protokolli Serf, ashtu si edhe Consul, është një zhvillim i HashiCorp.
Disa fakte të rëndësishme për Consul
Consul ka dokumentacion që përshkruan funksionimin e tij. Unë do të jap vetëm disa fakte selektive që duhet të dini.
Serverat e Consul zgjedhin një mjeshtër nga ata që votojnë. Consul zgjedh një mjeshtër nga lista e serverëve për secilën qendër të dhënash, dhe të gjitha kërkesat shkojnë vetëm tek ai, pavarësisht nga numri i serverëve. Ndalimi i mjeshtrit nuk rezulton në ripërcaktim. Nëse nuk është zgjedhur asnjë mjeshtër — kërkesat nuk përpunohen nga askush.
A donit shkallëzim horizontal? Më falni, jo.
Kërkesa për në një qendër të të dhënave tjetër shkon nga masteri te masteri, pavarësisht se në cilin server ka ardhur. Masteri i zgjedhur merr 100% ngarkesës, përveç ngarkesës për përpara të kërkesave. Një kopje aktuale e të dhënave është në të gjithë serverët e qendrës së të dhënave, por vetëm një nga ata përgjigjet.
Mënyra e vetme për të shkallëzuar është të aktivizoni modalitetin stale në klient.
Në modalitetin stale mund të përgjigjeni pa një kuorum. Kjo është një gjendje në të cilën heqim dorë nga konsistenca e të dhënave, por lexojmë pak më shpejt se zakonisht, dhe përgjigjet çdo server. Natyrisht, shkruani vetëm përmes masterit.
Consul nuk kopjon të dhëna ndërmjet qendrave të të dhënave.. Kur ndodh grumbullimi i federatës, çdo server do të ketë vetëm të dhënat e veta. Për të tjerat, ai gjithmonë do të drejtohet te dikush tjetër.
Atomikshmëria e operacioneve nuk garanton jashtë transaksionit.. Kini kujdes, sepse mund të ndryshoni diçka jo vetëm ju. Nëse dëshironi ndryshe, kryeni një transaksion me bllokim.
Operacione bllokuese nuk garanton bllokim.. Kërkesa shkon nga masteri te masteri, e jo direkt, kështu që nuk ka garanci që bllokimi do të funksionojë kur bëni bllokimin, për shembull, në një qendër të dhënash tjetër.
ACL gjithashtu nuk garanton akses (në shumë raste).. ACL mund të mos funksionojë, sepse ruhet në një qendër të të dhënave të federatës — në qendrën e të dhënave ACL (Primary DC). Nëse DC nuk ju përgjigjet, ACL nuk do të funksionojë.
Një master i ngrirë do të shkaktojë ngrirjen e gjithë federatës.. Për shembull, në një federatë me 10 qendra të të dhënave, dhe në njëra prej tyre ka një rrjet të keq, dhe një master bie. Të gjithë ata që komunikojnë me të do të ngrijnë në mënyrë të përhershme: po ndodh një kërkesë, nuk ka përgjigje, dhe thread-i ngec. Nuk do të keni mundësi të dini kur do të ndodhi, vetëm pas një ore ose dy do të bjerë e gjithë federata. Nuk do të bëni dot asgjë për këtë.
Statusi, kuorumi dhe zgjedhjet trajtohen nga një rrjedhë e veçantë. Rizgjedhje nuk do të ndodhin, statusi nuk do të tregojë asgjë. Mendoni se keni një Consul aktiv, kërkoni, dhe nuk ndodh asgjë — nuk ka përgjigje. Në të njëjtën kohë, statusi tregon se gjithçka është në rregull.
Ne kemi hasur në këtë problem, na është dashur të rindërtojmë pjesë specifike të qendrave të të dhënave për ta shmangur atë.
Në versionin e biznesit të Consul Enterprise nuk ka disa nga mangësitë më lart.. Ka shumë funksione të dobishme: zgjedhja e votuesve, shpërndarja, shkallëzimi. Ka vetëm një «por» — sistemi i licencës për sistemin e shpërndarë është shumë i shtrenjtë.
Hack i dobishëm: rm -rf /var/lib/consul — ilaçi për të gjitha sëmundjet e agjentit. Nëse ndonjë gjë nuk funksionon, thjesht hiqni të dhënat tuaja dhe ngarkoni të dhënat nga një kopje. Me shumë gjasa, Consul do të punojë.
BEFW
Tani le të flasim për atë që kemi shtuar në Consul.
— është një akronim për BackEndFireWall. Duhej të gjenim një emër për produktin kur krijova depozitën për të vendosur komitet e para testuese. Ky emërtim mbeti.
Shabllonet e rregullave
Rregullat shkruhen 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ç ESTABLISHED, RELATED dhe localhost. Shablloni mund të jetë i çfarëdo lloji, është thjesht një shembull.
Çfarë është e dobishme BEFW?
Shërbimet
Kemi një shërbim, gjithmonë ka një port, nodën mbi të cilin funksionon ai. Nga nodi ynë mund të kërkojmë lokalisht agjentin dhe të mësojmë se kemi ndonjë shërbim. Gjithashtu mund të vendosim etiketa.
Çdo shërbim që është aktiv dhe regjistruar në Consul shndërrohet në rregull të iptables. Kemi SSH — hapim portin 22. Skripti Bash është i thjeshtë: curl dhe iptables, nuk nevojiten gjëra më shumë.
Klientët
Si të hapim qasje jo për të gjithë, por për disa? Duke përdorur emrin e shërbimit për të grumbulluar lista IP në magazinën KV.
Për shembull, duam që të gjithë nga rrjeti i dhjetë të mund të kenë qasje në shërbimin SSH_TCP_22. Shtojmë një fushë të vogël TTL? dhe tani kemi lehtësira të përkohshme, për shembull, për një ditë.
Qasjet
Lidhim shërbimet dhe klientët: kemi një shërbim, për secilin është gati një magazinë KV. Tani jepim qasje jo për të gjithë, por për disa.
Grupet
Nëse do të shkruajmë mijëra IP për qasje çdo herë, do të lodhemi. Do të shpikim grupe — një subset të veçantë në KV. Do ta quajmë Alias (ose grupe) dhe do të ruajmë aty grupe sipas të njëjtit parim.
Lidhim: tani mund të hapim SSH jo konkretisht në P2P, por në një grup të tërë ose disa grupe. Po ashtu ka TTL — mund të shtojmë dhe të largojmë përkohësisht në grup.
Integrimi
Problemi ynë — faktorët njerëzorë dhe automatizimi. Deri tani e kemi zgjidhur kështu.
Ne punojmë me Puppet dhe transferojmë gjithçka që lidhet me sistemin (kodin e aplikacioneve). Në puppetdb (PostgreSQL standard) ruhet lista e shërbimeve që janë aktive, të cilat mund të gjenden sipas llojit të burimit. Po ashtu, mund të gjejmë se kush i drejtohet këndej. Gjithashtu, kemi një sistem të kërkesave për tërheqje dhe për bashkim për këtë.
Kemi shkruar befw-sync — një zgjidhje të thjeshtë që ndihmon në transferimin e të dhënave. Së pari, cookie-t e sync drejtohen në puppetdb. Atje është e konfiguruar HTTP API: kërkojmë cilat shërbime kemi, çfarë duhet bërë. Pastaj bëjnë një kërkesë në Consul.
A ka integrim? Po: kemi shkruar rregulla, lejuar pranim të Kërkesave për Tërheqje. A nevojitet ndonjë port ose të shtojmë një host në ndonjë grup? Kërkesë për Tërheqje, rishikim — asgjë më shumë se "Gjeje 200 ACL të tjera dhe provoni të bëni diçka me këtë".
Optimizimi
Ping localhost me një zinxhir rregullash të zbrazët zgjat 0.075 ms.
Do të shtojmë në këtë zinxhir 10,000 adresat e iptables. Si rezultat, ping-u do të rritet 5 herë: iptables është plotësisht linear, procesi për secilën adresë merr një kohë të caktuar.
Për firewall-in, në të cilin migrojmë mijëra ACL, kemi shumë rregulla, dhe kjo krijon vonesa. Kjo është e keqe për protokollet e lojërave.
Por nëse e vendosim 10,000 adresat në ipset ping-u madje do të pakësohet.
Koncesi është se "O" (kompleksiteti i algorithmit) për ipset është gjithmonë i barabartë me 1, sa herë rregulla që të ketë. E vërteta është se ka një kufizim — numri i rregullave nuk mund të kalojë 65535. Deri tani po jetojmë me këtë: mund t'i kombinojmë, zgjerim, 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ë një emër ipseti, me të cilin duhet të komunikojmë, dhe rregullin e ardhshëm DROP. Mund ta riformatojmë në një rregull "Kush nuk është këtu, atëherë DROP", por kështu është më e qartë.
Tani kemi rregulla dhe sete. Detyra kryesore është të krijojmë një set para se të shkruajmë një rregull, sepse ndryshe iptables nuk do të regjistrojë rregullin.
Skema e përgjithshme
Në formën e skemës, çdo gjë që kam treguar duket kështu.
Bëjmë commit në Puppet, gjithçka dërgohet në host, shërbimet janë këtu, ipset atje, ndërsa ata që nuk janë regjistruar atje, nuk lejohet të hyjnë.
Lejo & ndalo
Për të shpëtuar botën shpejt ose për të çaktivizuar dikë shpejt, në fillim të çdo zinxhiri kemi bërë dy ipset: rules_allow dhe rules_deny. Si funksionon kjo?
Për shembull, dikush krijon ngarkesë në Web-in tonë me bota. Më parë duhej të gjenim IP-në e tij në log-e, për ta çuar tek inxhinierët rrjetë dhe ata të gjenin burimin e trafikut dhe ta bllokonin. Tani kjo duket ndryshe.
Dërgojmë në Consul, presim 2.5 sekonda, dhe është gati. Duke qenë se Consul shpërndan shpejt përmes P2P, ai punon kudo, në çdo pjesë të botës.
Një herë e ndaluam plotësisht WOT-in, duke e thënë gabim me firewall-in. rules_allow — është sigurimi ynë nga këto raste. Nëse gabojmë ndonjëherë me firewall-in, ndonjë gjë ndalon, mund të dërgojmë një 'conditional' për ta rregulluar shpejt. Pastaj ne gjithmonë mund t’i rregullojmë gjërat me duar. 0.0/0Të tjera sete
Mund të shtoni çdo set tjetër në hapësirë
$IPSETS$ Pse? Ndonjëherë dikush ka nevojë për ipset, për shembull, për të imituar ndalimin e një pjese të klasterit. Çdo njeri mund të sjellë çdo set, t’i japë emrin dhe ata do të merren nga Consul. Në të njëjtën kohë, setet mund të marrin pjesë në rregullat e iptables, ose të jenë si një komandë NOOP: konsistenca do të mbështetet nga demoni..
Më parë ishte kështu: përdoruesi lidhej në rrjet dhe merrte parametrat përmes domenit. Para shfaqjes së firewall-eve të reja, Cisco nuk dinte të kuptonte ku ishte përdoruesi dhe ku ishte IP. Prandaj, hyrja jepeshin vetëm përmes hostname-it të makinës. Çfarë bëmë ne? U ndërhymë në momentin e marrjes së adresës. Zakonisht kjo është dot1x, Wi-Fi ose VPN — gjithçka shkon përmes RADIUS. Për çdo përdorues krijojmë një grup me emrin e përdoruesit dhe vendosim në të IP-në me TTL, e cila është e barabartë me dhcp.lease e tij — sa herë të skadojë, rregulli do të zhduket.Tani mund të hapim aksesin në shërbime, ashtu si në grupe të tjera, sipas username. Ne u shpëtuam nga dhimbja me hostname, kur ato ndryshojnë, dhe ia hoqëm ngarkesën inxhinierëve rrjetë, sepse nuk u duhet më Cisco. Tani inxhinierët vetë shkruajnë akseset në serverët e tyre.
Përdoruesit
Për paralel, filluam të shqyrtojmë izolimin. Menaxherët e shërbimeve bënë një inventar, dhe ne analizuam të gjitha rrjetet tona. Do t’i rendisim ato në grupe të ngjashme, dhe në serverët e nevojshëm grupeve i shtuam, për shembull, në deny. Tani izolimi i njëllojtë i stadyng-it kalon në rules_deny në prodhimin, por jo në vetë prodhimin.
Skema punon shpejt dhe thjeshtë: hiqim të gjitha ACL nga serverët, shkarkojmë pajisjet, ulim numrin e VLAN-ve të izoluar.
Kontrolli i integritetit
Izolimi
Në mënyrë paralele filluam të heqim izolimin. Menaxherët e shërbimit bënë një inventar, dhe ne analizuam të gjitha rrjetet tona. Do t'i grupojmë në grupe të ngjashme, dhe grupet e nevojshme në serverët e nevojshëm do t'i shtojmë, për shembull, në deny. Tani, e njëjta izolim e staging është në rules_deny të prodhimit, por jo në vetë prodhimin.
Schema punon shpejt dhe thjeshtë: heqim të gjitha ACL nga serverët, shkarkojmë pajisjet, zvogëlojmë numrin e VLAN-ve të izoluara.
Kontrolli i integritetit
Deri më parë kishim një trigger të veçantë që informonte kur dikush ndryshonte manualisht rregullin e firewall-it. Unë shkrova një linters të madh për kontrollin e rregullave të firewall-it, ishte e komplikuar. Tani integritetin e kontrollet BEFW. Ai ndjek me zell që rregullat që krijon të mos ndryshohen. Nëse dikush ndryshon rregullat e firewall-it, ai do t'i kthejë të gjitha përsëri. 'Këtu 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ë dhe rregulla të tjera dhe ipset të tjera.
Mbrojtja nga dështimet
BEFW gjithmonë ruan gjendjen e fundit të suksesshme drejtpërdrejt në strukturën binare state.bin. Nëse diçka shkon keq, ai gjithmonë kthehet pas në këtë state.bin.
Kjo është një sigurim nga punimi i paqëndrueshëm i Consul, kur ai nuk dërgoi të dhënat ose dikush bëri një gabim dhe përdori rregulla që nuk mund të aplikohen. Që të mos mbetemi pa firewall, BEFW do të kthehet në gjendjen e fundit nëse në ndonjë pikë ndodh një gabim.
Në situata kritike kjo është një garanci që do të mbetemi me një firewall në punë. Ne hapim të gjitha rrjetet gri në shpresë se admini do të vijë dhe do ta rregullojë. Disa herë do ta nxjerr këtë në konfigurime, por tani kemi thjesht tre rrjete gri: 10/8, 172/12 dhe 192.168/16. Brenda Consul tonë kjo është një veçori e rëndësishme që ndihmon në zhvillimin më tej.
Demo: gjatë prezantimit, Ivan demonstron modin demo të punës së BEFW. Është më e lehtë të shikosh demonstratën në . Kodi burimor i demostratës është i disponueshëm .
ProHoster Sofiyadakı digər server provayderlərindən nə ilə fərqlənir?
Do të flas për gabimet me të cilat u përballëm.
ipset add set 0.0.0.0/0. Çfarë ndodh nëse shtoni në ipset 0.0.0.0/0? Do të shtohen të gjitha IP? Do të hapet qasje në internet?
Jo, do të marrim një bug që na kostoi dy orë qëndrimi. Nga ana tjetër, bug-u nuk ka funksionuar që nga viti 2016, është 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 kthehet 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' Asgjë e tillë — ai bën një merge dhe adresat e vjetra nuk zhduken, ju nuk e mbyllni qasjen.? Вы думаете, он работает также, как iptables? Восстановит данные?
Ne gjetëm bug-un kur testonim izolimin. Tani ka një sistem të mjaftueshëm të komplikuar — në vend të
kryhet Asgjë e tillë — ai bën një merge dhe adresat e vjetra nuk zhduken, ju nuk e mbyllni qasjen. create temp restore flush temp, pastaj restore temp dhe . Në fund swap: për atomaritet, sepse nëse e kryen fillimisht. Në fund swap: për atomikshmërinë, sepse nëse fillimisht bëjmë flush dhe në këtë moment do të vijë ndonjë pako, ajo do të hidhet dhe diçka do të shkojë keq. Kështu që aty ka pak magji të zezë.
consul kv get -datacenter=other. Siç e kam thënë, ne mendojmë se po kërkojmë ndonjë të dhënë, por do të marrim ose të dhëna, ose një gabim. Ne mund ta bëjmë këtë lokalisht përmes Consul, por edhe në këtë rast do të ngecim dhe atë dhe këtë.
Klienti lokal Consul është një mbështjellës mbi API-në HTTP. Por ai ngrihet dhe nuk përgjigjet as për Ctrl+C, as për Ctrl+Z, as për asgjë, vetëm për kill -9 në konsolën fqinjë. Ne u ballafaqua me këtë kur ndërtuam një grup të madh. Por nuk kemi ende një zgjidhje, jemi duke u përgatitur për të korrigjuar këtë gabim në Consul.
Lideri i Consul-it nuk po përgjigjet. Kemi një master në data-qendër që nuk po përgjigjet, ne mendojmë: "Mbase tani do të funksionojë algoritmi i rinumërimit?"
Jo, nuk do të funksionojë, dhe monitorimi nuk do të tregojë asgjë: Consul do të thotë se indekset e angazhimit janë aty, lideri është gjetur, gjithçka është mirë.
Si po luftojmë me këtë? service consul restart në cron çdo orë. Nëse keni 50 serverë - nuk është e frikshme. Kur do të jenë 16,000, do ta kuptoni se si funksionon.
Përfundim
Si rezultat, morëm avantazhet e mëposhtme:
- 100% mbulim të gjitha makinerive Linux.
- Shpejtësia.
- Automatizimin.
- Çlirimi i paisjeve dhe inxhinierëve rrjetë nga skllavëria.
- Kemi mundësi integrimi që janë praktikisht të pakufizuara: qoftë me Kubernetes, qoftë me Ansible, qoftë me Python.
Disavantazhet: Consul, me të cilin tani duhet të jetojmë, dhe një çmim shumë i lartë gabimi. Si një shembull, një herë në orën 6 të pasdites (kohë kryesore në Rusi) e ndryshova diçka në listat e rrjeteve. Ne po ndërtoshim izolimin në BEFW. Unë gabova ndoshta, duke treguar maskën e gabuar, por gjithçka ra brenda dy sekondash. Monitorimi ndez, përfundon ndihma: "Kemi gjithçka të bllokuar!" Shefi i departamentit u bë thinj kur shpjegoi biznesit pse ndodhi kjo.
Çmimi i gabimit është kaq i lartë, saqë ne shpikëm një procedurë të komplikuar parandaluese. Nëse do ta implementoni këtë në një prodhim të madh, mos jepni master-token mbi Consul të gjithëve pa kriter. Kjo do të përfundojë keq.
Kostoja. Unë kam shkruar kodin 400 orë në vetmi. Për mbështetje, ekipi im prej 4 personash shpenzon 10 orë në muaj për të gjithë. Krahasuar me çmimin e çdo firewalle të gjeneratës së re, kjo është falas.
Planet. Plani afatgjatë është të kërkojmë një transport alternativ përveç Consul, ndoshta do të jetë Kafka ose diçka e ngjashme. Por në vitet e ardhshme do të jetojmë me Consul.
Planifikimet e afërta: integrimi me Fail2ban, monitorimi, me nftables, ndoshta edhe me distribucione të tjera, metrikat, monitorimi i zgjeruar, optimizimi. Mbështetje për Kubernetes gjithashtu është në planet, sepse tani kemi disa klasterë dhe dëshirë.
Gjithashtu në planet:
- kërkimi i anomalisë në trafik;
- menaxhimi i hartës së rrjetit;
- mbështetje për Kubernetes;
- ndërtimi i pakove për të gjitha sistemet;
- Web-UI.
Përsëri, ne punojmë vazhdimisht për të zgjeruar konfigurimin, rritur metrikat dhe optimizimin.
Bashkohuni me projektin. Projekti doli të jetë shumë i mirë, por, fatkeqësisht, deri tani është një projekt i një personi. Ejani në dhe provoni të bëni diçka: bëni commit, testoni, sugjeroni diçka, jepni vlerësimin tuaj.
Ndërkohë, po përgatitemi për , i cili 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ë se çfarë të bëjnë, ndërsa për fillestarët në fjalime rekomandojmë të paktën . Pjesëmarrja në konferencë si folës ka disa përfitime. Cilat, mund të lexoni, për shembull, në fund .
Burimi: habr.com
