În 2010 compania existau 50 de servere și un model de rețea simplu: backend, frontend și firewall. Numărul de servere a crescut, modelul a devenit mai complex: staging, VLAN-uri izolate cu ACL-uri, apoi VPN-uri cu VRF-uri, VLAN-uri cu ACL-uri pe L2, VRF-uri cu ACL-uri pe L3. Capul se învârte? Va fi mai distractiv mai târziu.
Când erau 16 de servere, a devenit imposibil să lucrezi fără lacrimi cu atâtea segmente eterogene. Așa că am venit cu o altă soluție. Am luat stiva Netfilter, am adăugat Consul ca sursă de date și am primit un firewall rapid distribuit. Au înlocuit ACL-urile pe routere și le-au folosit ca firewall extern și intern. Pentru a gestiona în mod dinamic instrumentul, am dezvoltat sistemul BEFW, care a fost folosit peste tot: de la gestionarea accesului utilizatorilor la rețeaua de produse până la izolarea segmentelor de rețea unele de altele.
El vă va spune cum funcționează totul și de ce ar trebui să aruncați o privire mai atentă asupra acestui sistem. Ivan Agarkov () este șeful grupului de securitate a infrastructurii al diviziei de întreținere de la centrul de dezvoltare Minsk al companiei. Ivan este un fan SELinux, iubește Perl și scrie cod. În calitate de șef al grupului de securitate a informațiilor, el lucrează în mod regulat cu jurnalele, copiile de rezervă și cercetarea și dezvoltarea pentru a proteja Wargaming de hackeri și pentru a asigura funcționarea tuturor serverelor de jocuri din companie.
istorie
Înainte să vă spun cum am făcut-o, vă voi spune cum am ajuns la asta în primul rând și de ce a fost nevoie. Pentru a face acest lucru, să ne întoarcem cu 9 ani: 2010, tocmai a apărut World of Tanks. Wargaming avea aproximativ 50 de servere.
Diagrama de creștere a serverului companiei.
Aveam un model de rețea. Pentru acea vreme era optim.
Model de rețea în 2010.
Sunt băieți răi pe front care vor să ne spargă, dar are un firewall. Nu există firewall pe backend, dar există 50 de servere acolo, le știm pe toate. Totul merge bine.
În 4 ani, flota de servere a crescut de 100 de ori, până la 5000. Au apărut primele rețele izolate - punerea în scenă: nu puteau merge în producție, iar acolo rulau adesea lucruri care puteau fi periculoase.
Model de rețea în 2014.
Prin inerție, am folosit aceleași piese hardware și toată munca a fost efectuată pe VLAN-uri izolate: ACL-urile sunt scrise pe VLAN-uri, care permit sau interzice un fel de conexiune.
În 2016, numărul de servere a ajuns la 8000 XNUMX. Wargaming a absorbit alte studiouri și au apărut rețele suplimentare de afiliați. Par a fi ale noastre, dar nu chiar: VLAN-ul de multe ori nu funcționează pentru parteneri, trebuie să utilizați VPN cu VRF, izolarea devine mai complicată. Amestecul de izolație ACL a crescut.
Model de rețea în 2016.
Până la începutul anului 2018, flota de utilaje crescuse la 16 000. Erau 6 segmente, iar restul nu le-am numărat, inclusiv cele închise în care erau stocate date financiare. Au apărut rețelele de containere (Kubernetes), DevOps, rețelele cloud conectate prin VPN, de exemplu, de la un IVS. Erau o mulțime de reguli - a fost dureros.
Model de rețea și metode de izolare în 2018.
Pentru izolare am folosit: VLAN cu ACL pe L2, VRF cu ACL pe L3, VPN și multe altele. Prea mult.
Probleme
Toată lumea trăiește cu ACL și VLAN. Ce s-a întâmplat? La această întrebare îi va răspunde Harold, ascunzând durerea.
Au fost multe probleme, dar au fost cinci masive.
- Creșterea geometrică a prețului pentru reguli noi. Fiecare regulă nouă a durat mai mult să fie adăugată decât cea anterioară, pentru că mai întâi era necesar să vedem dacă există deja o astfel de regulă.
- Fără firewall în interiorul segmentelor. Segmentele erau cumva separate unele de altele și deja nu erau suficiente resurse în interior.
- Regulile au fost aplicate mult timp. Operatorii ar putea scrie manual o regulă locală într-o oră. Cel global a durat câteva zile.
- Dificultăți cu regulile de audit. Mai exact, nu a fost posibil. Primele reguli au fost scrise încă din 2010, iar majoritatea autorilor lor nu mai lucrau pentru companie.
- Nivel scăzut de control al infrastructurii. Aceasta este principala problemă - nu știam prea bine ce se întâmplă în țara noastră.
Așa arăta un inginer de rețea în 2018 când a auzit: „Am nevoie de mai mult ACL”.
Soluții
La începutul lui 2018, s-a decis să se facă ceva în privința asta.
Prețul integrărilor este în continuă creștere. Punctul de plecare a fost că centrele mari de date au încetat să mai suporte VLAN-uri și ACL-uri izolate, deoarece dispozitivele au rămas fără memorie.
Soluție: am eliminat factorul uman și am automatizat asigurarea accesului la maximum.
Aplicarea noilor reguli durează mult. Soluție: accelerați aplicarea regulilor, faceți-o distribuită și paralelă. Acest lucru necesită un sistem distribuit, astfel încât regulile să fie livrate singure, fără rsync sau SFTP la o mie de sisteme.
Fără firewall în interiorul segmentelor. Un firewall în segmente a început să vină la noi când au apărut servicii diferite în cadrul aceleiași rețele. Soluție: utilizați un firewall la nivel de gazdă - firewall-uri bazate pe gazdă. Aproape peste tot avem Linux și peste tot avem iptables, aceasta nu este o problemă.
Dificultăți cu regulile de audit. Soluție: păstrați toate regulile într-un singur loc pentru revizuire și gestionare, astfel încât să putem audita totul.
Nivel scăzut de control asupra infrastructurii. Soluție: faceți un inventar al tuturor serviciilor și acceselor dintre ele.
Acesta este mai mult un proces administrativ decât unul tehnic. Uneori avem 200-300 de lansări noi pe săptămână, mai ales în timpul promoțiilor și sărbătorilor. În plus, aceasta este doar pentru o echipă a DevOps-ului nostru. Cu atât de multe versiuni, este imposibil să vedem ce porturi, IP-uri și integrări sunt necesare. Prin urmare, aveam nevoie de manageri de service special instruiți, care să întrebe echipele: „Totuși, ce există și de ce ați adus în discuție?”
După tot ce am lansat, un inginer de rețea în 2019 a început să arate așa.
Consul
Am decis că vom pune tot ce am găsit cu ajutorul managerilor de servicii în Consul și de acolo vom scrie regulile iptables.
Cum ne-am hotărât să facem asta?
- Vom colecta toate serviciile, rețelele și utilizatorii.
- Să creăm reguli iptables pe baza lor.
- Automatizăm controlul.
- ....
- PROFIT.
Consul nu este un API la distanță, poate rula pe fiecare nod și poate scrie în iptables. Rămâne doar să vină cu controale automate care vor curăța lucrurile inutile, iar majoritatea problemelor vor fi rezolvate! Vom rezolva restul pe măsură ce mergem.
De ce consul?
S-a dovedit bine. În 2014-15, l-am folosit ca backend pentru Vault, în care stocăm parolele.
Nu pierde date. În timpul utilizării, Consul nu a pierdut date în timpul unui singur accident. Acesta este un mare plus pentru un sistem de management firewall.
Conexiunile P2P accelerează răspândirea schimbării. Cu P2P, toate modificările vin rapid, nu este nevoie să așteptați ore întregi.
API REST convenabil. Am luat în considerare și Apache ZooKeeper, dar nu are API REST, așa că va trebui să instalați cârje.
Funcționează atât ca seif de chei (KV) cât și ca director (descoperire servicii). Puteți stoca servicii, cataloage și centre de date simultan. Acest lucru este convenabil nu numai pentru noi, ci și pentru echipele vecine, deoarece atunci când construim un serviciu global, gândim mare.
Scris în Go, care face parte din stiva Wargaming. Ne place acest limbaj, avem mulți dezvoltatori Go.
Sistem ACL puternic. În Consul, puteți utiliza ACL-uri pentru a controla cine scrie ce. Vă garantăm că regulile firewall nu se vor suprapune cu nimic altceva și nu vom avea probleme cu acest lucru.
Dar Consul are și dezavantajele lui.
- Nu se extinde într-un centru de date decât dacă aveți o versiune business. Este scalabil doar de federație.
- Foarte dependent de calitatea rețelei și de încărcarea serverului. Consul nu va funcționa corect ca server pe un server ocupat dacă există întârzieri în rețea, de exemplu, viteza neuniformă. Acest lucru se datorează conexiunilor P2P și actualizării modelelor de distribuție.
- Dificultate în monitorizarea disponibilității. În statut de Consul poate spune că totul este în regulă, dar a murit cu mult timp în urmă.
Majoritatea acestor probleme le-am rezolvat folosind Consul, motiv pentru care l-am ales. Compania are planuri pentru un backend alternativ, dar am învățat să facem față problemelor și locuim în prezent cu Consul.
Cum funcționează Consul
Vom instala trei până la cinci servere într-un centru de date condiționat. Unul sau două servere nu vor funcționa: nu vor putea să organizeze un cvorum și să decidă cine are dreptate și cine greșește atunci când datele nu se potrivesc. Mai mult de cinci nu are sens, productivitatea va scădea.
Clienții se conectează la servere în orice ordine: aceiași agenți, doar cu steag server = false.
După aceasta, clienții primesc o listă de conexiuni P2P și construiesc conexiuni între ei.
La nivel global, conectăm mai multe centre de date. De asemenea, se conectează P2P și comunică.
Când dorim să recuperăm date de la un alt centru de date, cererea trece de la server la server. Această schemă se numește Protocolul iobagilor. Protocolul Serf, ca și Consul, este dezvoltat de HashiCorp.
Câteva fapte importante despre Consul
Consul are documentație care descrie cum funcționează. Voi oferi doar fapte selectate care merită cunoscute.
Serverele consul aleg un maestru dintre alegători. Consul selectează un master din lista de servere pentru fiecare centru de date, iar toate solicitările ajung doar la acesta, indiferent de numărul de servere. Înghețarea maestrului nu duce la realegere. Dacă masterul nu este selectat, cererile nu sunt deservite de nimeni.
Ai vrut scalare orizontală? Scuze, nu.
O solicitare către un alt centru de date trece de la master la master, indiferent de serverul la care a venit. Master-ul selectat primește 100% din încărcare, cu excepția încărcăturii la cererile de transmitere. Toate serverele din centrul de date au o copie actualizată a datelor, dar numai unul răspunde.
Singura modalitate de scalare este să activați modul învechit pe client.
În modul învechit, puteți răspunde fără cvorum. Acesta este un mod în care renunțăm la consistența datelor, dar citim puțin mai repede decât de obicei și orice server răspunde. Desigur, înregistrarea numai prin master.
Consul nu copiază datele între centrele de date. Când o federație este asamblată, fiecare server va avea doar propriile sale date. Pentru alții, el se îndreaptă mereu către altcineva.
Atomicitatea operațiunilor nu este garantată în afara unei tranzacții. Amintește-ți că nu ești singurul care poate schimba lucrurile. Dacă doriți altfel, efectuați o tranzacție cu blocare.
Operațiunile de blocare nu garantează blocarea. Solicitarea trece de la master la master, și nu direct, așa că nu există nicio garanție că blocarea va funcționa atunci când blocați, de exemplu, într-un alt centru de date.
De asemenea, ACL nu garantează accesul (în multe cazuri). Este posibil ca ACL să nu funcționeze, deoarece este stocat într-un centru de date al federației - în centrul de date ACL (DC principal). Dacă DC nu vă răspunde, ACL nu va funcționa.
Un maestru înghețat va face ca întreaga federație să înghețe. De exemplu, există 10 centre de date într-o federație și unul are o rețea proastă, iar un master eșuează. Toți cei care comunică cu el vor îngheța într-un cerc: există o cerere, nu există răspuns la aceasta, firul se blochează. Nu există nicio modalitate de a ști când se va întâmpla asta, doar într-o oră sau două va cădea întreaga federație. Nu poți face nimic în privința asta.
Statutul, cvorumul și alegerile sunt gestionate de un fir separat. Nu va avea loc realegerea, starea nu va arăta nimic. Crezi că ai un Consul viu, întrebi, și nu se întâmplă nimic - nu există niciun răspuns. În același timp, starea arată că totul este în regulă.
Am întâmpinat această problemă și a trebuit să reconstruim anumite părți ale centrelor de date pentru a o evita.
Versiunea business a Consul Enterprise nu are unele dintre dezavantajele de mai sus. Are multe funcții utile: selectarea alegătorilor, distribuirea, scalarea. Există un singur „dar” - sistemul de licențiere pentru un sistem distribuit este foarte scump.
Viața hacking: rm -rf /var/lib/consul - un remediu pentru toate bolile agentului. Dacă ceva nu funcționează pentru dvs., ștergeți datele și descărcați datele dintr-o copie. Cel mai probabil, Consul va lucra.
BEFW
Acum să vorbim despre ce am adăugat la Consul.
este un acronim pentru BACKEndFmânieWtoate. A trebuit să numesc produsul cumva când am creat depozitul pentru a pune primele comite de testare în el. Acest nume rămâne.
Șabloane de reguli
Regulile sunt scrise în sintaxa iptables.
- -N BEFW
- -P CĂDERARE INTRARE
- -A INPUT -m stare — stare RELATED,STABLISHED -j ACCEPT
- -A INTRARE -i lo -j ACCEPT
- -A INTRARE -j BEFW
Totul intră în lanțul BEFW, cu excepția ESTABLISHED, RELATED și localhost. Șablonul poate fi orice, acesta este doar un exemplu.
Cum este util BEFW?
Servicii
Avem un serviciu, are întotdeauna un port, un nod pe care rulează. Din nodul nostru, putem să întrebăm local agentul și să aflăm că avem un fel de serviciu. Puteți pune și etichete.
Orice serviciu care rulează și este înregistrat la Consul se transformă într-o regulă iptables. Avem SSH - portul deschis 22. Scriptul Bash este simplu: curl și iptables, nu este nevoie de nimic altceva.
Clienti
Cum să deschideți accesul nu tuturor, ci selectiv? Adăugați liste de IP la stocarea KV după numele serviciului.
De exemplu, dorim ca toți cei din a zecea rețea să poată accesa serviciul SSH_TCP_22. Adăugați un câmp TTL mic? iar acum avem permise temporare, de exemplu, pentru o zi.
Accesuri
Conectăm servicii și clienți: avem un serviciu, depozitarea KV este pregătită pentru fiecare. Acum oferim acces nu tuturor, ci selectiv.
Grupuri
Dacă scriem mii de IP-uri pentru acces de fiecare dată, vom obosi. Să venim cu grupări - un subset separat în KV. Să-i spunem Alias (sau grupuri) și să stocăm grupuri acolo după același principiu.
Să ne conectăm: acum putem deschide SSH nu special pentru P2P, ci pentru un întreg grup sau mai multe grupuri. În același mod, există TTL - puteți adăuga la un grup și elimina temporar din grup.
integrare
Problema noastră este factorul uman și automatizarea. Până acum am rezolvat-o astfel.
Lucrăm cu Puppet și le transferăm tot ceea ce se referă la sistem (codul aplicației). Puppetdb (PostgreSQL obișnuit) stochează o listă de servicii care rulează acolo, acestea pot fi găsite după tipul de resursă. Acolo poți afla cine aplică unde. Avem, de asemenea, un sistem de solicitare de extragere și solicitare de îmbinare pentru aceasta.
Am scris befw-sync, o soluție simplă care ajută la transferul de date. În primul rând, cookie-urile de sincronizare sunt accesate de puppetdb. Acolo este configurat un API HTTP: solicităm ce servicii avem, ce trebuie făcut. Apoi fac o cerere la Consul.
Există integrare? Da: au scris regulile și au permis acceptarea cererilor de tragere. Aveți nevoie de un anumit port sau adăugați o gazdă la un grup? Pull Request, revizuiți - nu mai „Găsiți alte 200 de ACL-uri și încercați să faceți ceva în privința asta”.
Optimizare
Trimiterea ping localhost cu un lanț de reguli gol durează 0,075 ms.
Să adăugăm 10 de adrese iptables la acest lanț. Ca rezultat, ping-ul va crește de 000 ori: iptables este complet liniar, procesarea fiecărei adrese durează ceva timp.
Pentru un firewall în care migrăm mii de ACL-uri, avem o mulțime de reguli, iar acest lucru introduce latență. Acest lucru este rău pentru protocoalele de jocuri.
Dar dacă punem 10 de adrese în ipset Ping-ul chiar va scădea.
Ideea este că „O” (complexitatea algoritmului) pentru ipset este întotdeauna egal cu 1, indiferent de câte reguli există. Adevărat, există o limitare - nu pot exista mai mult de reguli 65535. Deocamdată trăim cu asta: le puteți combina, extinde, face două ipseturi într-unul.
Depozitare
O continuare logică a procesului de iterație este stocarea informațiilor despre clienții serviciului în ipset.
Acum avem același SSH și nu scriem 100 de IP-uri deodată, ci setăm numele ipsetului cu care trebuie să comunicăm și următoarea regulă DROP. Poate fi convertit într-o singură regulă „Cine nu este aici, DROP”, dar este mai clar.
Acum avem reguli și seturi. Sarcina principală este să faci un set înainte de a scrie regula, pentru că altfel iptables nu va scrie regula.
Schema generală
Sub formă de diagramă, tot ce am spus arată așa.
Ne angajăm la Puppet, totul este trimis gazdei, servicii aici, ipset acolo, iar oricine nu este înregistrat acolo nu are voie.
Permite și respinge
Pentru a salva rapid lumea sau a dezactiva rapid pe cineva, la începutul tuturor lanțurilor am făcut două ipseturi: rules_allow и rules_deny. Cum functioneaza?
De exemplu, cineva creează o încărcare pe web-ul nostru cu ajutorul roboților. Anterior, trebuia să-i găsești IP-ul din jurnale, să-l duci inginerilor de rețea, pentru ca aceștia să găsească sursa traficului și să-l interzică. Arată diferit acum.
Îl trimitem la Consul, așteptăm 2,5 secunde și este gata. Deoarece Consul distribuie rapid prin P2P, funcționează peste tot, în orice parte a lumii.
Odată am oprit cumva complet WOT din cauza unei greșeli cu firewall-ul. rules_allow - aceasta este asigurarea noastră împotriva unor astfel de cazuri. Dacă am greșit undeva cu firewall-ul, ceva este blocat undeva, putem trimite oricând o condițional 0.0/0pentru a ridica repede totul. Mai târziu vom repara totul manual.
Alte seturi
Puteți adăuga orice alte seturi în spațiu $IPSETS$.
Pentru ce? Uneori, cineva are nevoie de ipset, de exemplu, pentru a emula oprirea unei părți a clusterului. Oricine poate aduce orice seturi, le poate numi, iar acestea vor fi ridicate de la Consul. În același timp, seturile pot fie să participe la regulile iptables, fie să acționeze ca o echipă NOOP: Consecvența va fi menținută de demon.
utilizatori
Anterior, era așa: utilizatorul se conecta la rețea și primea parametri prin intermediul domeniului. Înainte de apariția firewall-urilor de nouă generație, Cisco nu știa cum să înțeleagă unde se află utilizatorul și unde este IP-ul. Prin urmare, accesul a fost acordat numai prin numele de gazdă al mașinii.
Ce am facut? Ne-am blocat în momentul în care am primit adresa. De obicei, acesta este dot1x, Wi-Fi sau VPN - totul trece prin RADIUS. Pentru fiecare utilizator, creăm un grup după numele de utilizator și plasăm în el un IP cu un TTL care este egal cu dhcp.lease - de îndată ce expiră, regula va dispărea.
Acum putem deschide accesul la servicii, ca și alte grupuri, după numele de utilizator. Am scăpat de durerea numelor de gazdă atunci când se schimbă și le-am scăpat de sarcina inginerilor de rețea, deoarece nu mai au nevoie de Cisco. Acum inginerii înșiși înregistrează accesul pe serverele lor.
Izolație
În același timp, am început să demontăm izolația. Managerii de servicii au făcut un inventar și ne-am analizat toate rețelele. Să le împărțim în aceleași grupuri, iar pe serverele necesare au fost adăugate grupurile, de exemplu, pentru a refuza. Acum aceeași izolare în scenă ajunge în regulile_negarea producției, dar nu și în producția în sine.
Schema funcționează rapid și simplu: eliminăm toate ACL-urile de pe servere, descarcăm hardware-ul și reducem numărul de VLAN-uri izolate.
Controlul integrității
Anterior, aveam un declanșator special care raporta când cineva schimba manual o regulă de firewall. Scriam un linter uriaș pentru verificarea regulilor firewall-ului, a fost dificil. Integritatea este acum controlată de BEFW. El se asigură cu zel că regulile pe care le face nu se schimbă. Dacă cineva schimbă regulile firewall-ului, totul va schimba înapoi. „Am configurat rapid un proxy pentru a putea lucra de acasă” – nu mai există astfel de opțiuni.
BEFW controlează ipsetul din serviciile și lista din befw.conf, regulile serviciilor din lanțul BEFW. Dar nu monitorizează alte lanțuri și reguli și alte ipseturi.
Protecție împotriva accidentelor
BEFW stochează întotdeauna ultima stare bună cunoscută direct în structura binară state.bin. Dacă ceva nu merge bine, se întoarce întotdeauna la această stare.bin.
Aceasta este asigurare împotriva funcționării instabile a Consulului, când nu a trimis date sau cineva a greșit și a folosit reguli care nu pot fi aplicate. Pentru a ne asigura că nu rămânem fără un firewall, BEFW va reveni la cea mai recentă stare dacă apare o eroare în orice etapă.
În situații critice, aceasta este o garanție că vom rămâne cu un firewall funcțional. Deschidem toate rețelele gri în speranța că administratorul va veni și va repara. Într-o zi voi pune asta în configurații, dar acum avem doar trei rețele gri: 10/8, 172/12 și 192.168/16. În cadrul Consulului nostru, aceasta este o caracteristică importantă care ne ajută să ne dezvoltăm în continuare.
Demo: în timpul raportului, Ivan demonstrează modul demo al BEFW. Este mai ușor să urmărești demonstrația . Cod sursă demo disponibil .
Capcane
Vă voi spune despre bug-urile pe care le-am întâlnit.
ipset add set 0.0.0.0/0. Ce se întâmplă dacă adăugați 0.0.0.0/0 la ipset? Vor fi adăugate toate IP-urile? Va fi disponibil acces la internet?
Nu, vom primi o eroare care ne-a costat două ore de oprire. Mai mult, bug-ul nu a funcționat din 2016, este localizat în RedHat Bugzilla sub numărul #1297092 și l-am găsit din întâmplare - dintr-un raport al dezvoltatorului.
Acum este o regulă strictă la BEFW că 0.0.0.0/0 se transformă în două adrese: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < fișier. Ce face ipset când îi spui restore? Crezi că funcționează la fel ca iptables? Va recupera datele?
Nimic de genul asta - face o fuziune, iar adresele vechi nu merg nicăieri, nu blochezi accesul.
Am găsit o eroare când am testat izolarea. Acum există un sistem destul de complex - în loc de restore efectuat create temp, atunci restore flush temp и restore temp. La sfârșitul schimbului: pentru atomicitate, pentru că dacă o faci mai întâi flush și în acest moment sosește un pachet, acesta va fi aruncat și ceva va merge prost. Deci există un pic de magie neagră acolo.
consul kv get -datacenter=other. După cum am spus, credem că solicităm niște date, dar vom obține fie date, fie o eroare. Putem face acest lucru prin Consul local, dar în acest caz ambele se vor îngheța.
Clientul Consul local este un wrapper peste API-ul HTTP. Dar pur și simplu se blochează și nu răspunde la Ctrl+C, sau Ctrl+Z sau orice altceva, doar kill -9 în următoarea consolă. Am întâlnit asta când construiam un grup mare. Dar nu avem încă o soluție; ne pregătim să remediam această eroare în Consul.
Liderul consulului nu răspunde. Maestrul nostru din centrul de date nu răspunde, ne gândim: „Poate că algoritmul de reselectare va funcționa acum?”
Nu, nu va funcționa, iar monitorizarea nu va arăta nimic: Consul va spune că există un indice de angajament, a fost găsit un lider, totul este în regulă.
Cum ne descurcăm cu asta? service consul restart în cron la fiecare oră. Dacă ai 50 de servere, nu e mare lucru. Când sunt 16, veți înțelege cum funcționează.
Concluzie
Drept urmare, am primit următoarele avantaje:
- Acoperire 100% a tuturor mașinilor Linux.
- Viteză.
- Automatizare.
- Am eliberat inginerii hardware și de rețea din sclavie.
- Au apărut posibilități de integrare care sunt aproape nelimitate: chiar și cu Kubernetes, chiar și cu Ansible, chiar și cu Python.
Contra: Consul, cu care acum trebuie să trăim, și costul foarte mare al erorii. De exemplu, o dată la ora 6 (prime time în Rusia) editam ceva în listele de rețele. La momentul respectiv construiam izolație la BEFW. Am greșit undeva, se pare că am indicat masca greșită, dar totul a căzut în două secunde. Monitorizarea se aprinde, persoana de sprijin de serviciu vine în fugă: „Avem totul!” Șeful departamentului a devenit gri când a explicat afacerilor de ce s-a întâmplat asta.
Costul erorii este atât de mare încât am creat propria noastră procedură complexă de prevenire. Dacă implementați acest lucru pe un site de producție mare, nu trebuie să oferiți tuturor un jeton de master pentru Consul. Asta se va termina prost.
Cost. Am scris cod doar pentru 400 de ore. Echipa mea de 4 persoane petrece 10 ore pe lună pentru asistență pentru toată lumea. În comparație cu prețul oricărui firewall de nouă generație, este gratuit.
Planuri. Planul pe termen lung este de a găsi transport alternativ pentru a înlocui sau completa Consul. Poate că va fi Kafka sau ceva asemănător. Dar în următorii ani vom trăi pe Consul.
Planuri imediate: integrare cu Fail2ban, cu monitorizare, cu nftables, eventual cu alte distribuții, metrici, monitorizare avansată, optimizare. Suportul Kubernetes este și el undeva în planuri, pentru că acum avem mai multe clustere și dorința.
Mai multe din planuri:
- căutarea anomaliilor în trafic;
- gestionarea hărților de rețea;
- suport Kubernetes;
- asamblarea pachetelor pentru toate sistemele;
- Web-UI.
Lucrăm constant la extinderea configurației, la creșterea valorilor și la optimizare.
Alăturați-vă proiectului. Proiectul s-a dovedit a fi mișto, dar, din păcate, este încă un proiect cu o singură persoană. Vino la și încearcă să faci ceva: comite, testează, sugerează ceva, dă-ți evaluarea.
Intre timp ne pregatim pentru , care va avea loc pe 6 și 7 aprilie la Sankt Petersburg, și invităm dezvoltatorii de sisteme de mare încărcare . Vorbitorii cu experiență știu deja ce să facă, dar pentru cei care vorbesc noi le recomandăm cel puțin . Participarea la conferință în calitate de vorbitor are o serie de avantaje. Puteți citi pe care, de exemplu, la sfârșit .
Sursa: www.habr.com