I 2010 virksomheden der var 50 servere og en simpel netværksmodel: backend, frontend og firewall. Antallet af servere voksede, modellen blev mere kompleks: iscenesættelse, isolerede VLAN'er med ACL'er, derefter VPN'er med VRF'er, VLAN'er med ACL'er på L2, VRF'er med ACL'er på L3. Snurrer hovedet? Det bliver sjovere senere.
Da der var 16 servere, blev det umuligt at arbejde uden tårer med så mange heterogene segmenter. Så vi fandt på en anden løsning. Vi tog Netfilter-stakken, tilføjede Consul til den som datakilde, og vi fik en hurtig distribueret firewall. De erstattede ACL'er på routere og brugte dem som en ekstern og intern firewall. For dynamisk at styre værktøjet udviklede vi BEFW-systemet, som blev brugt overalt: fra styring af brugeradgang til produktnetværket til isolering af netværkssegmenter fra hinanden.
Han vil fortælle dig, hvordan det hele fungerer, og hvorfor du bør se nærmere på dette system. Ivan Agarkov () er leder af infrastruktursikkerhedsgruppen i Maintenance-divisionen i virksomhedens Minsk-udviklingscenter. Ivan er SELinux-fan, elsker Perl og skriver kode. Som leder af informationssikkerhedsgruppen arbejder han løbende med logs, backups og R&D for at beskytte Wargaming mod hackere og sikre driften af alle spilservere i virksomheden.
Historie
Før jeg fortæller dig, hvordan vi gjorde det, vil jeg fortælle dig, hvordan vi kom til dette i første omgang, og hvorfor det var nødvendigt. For at gøre dette, lad os gå 9 år tilbage: 2010, World of Tanks dukkede lige op. Wargaming havde cirka 50 servere.
Vækstdiagram for virksomhedsservere.
Vi havde en netværksmodel. For den gang var det optimalt.
Netværksmodel i 2010.
Der er skurke i frontenden, der vil knække os, men den har en firewall. Der er ingen firewall på backend, men der er 50 servere der, vi kender dem alle. Alt fungerer godt.
På 4 år voksede serverflåden 100 gange til 5000. De første isolerede netværk dukkede op - iscenesættelse: de kunne ikke gå i produktion, og der kørte ofte ting der, som kunne være farlige.
Netværksmodel i 2014.
Ved inerti brugte vi de samme stykker hardware, og alt arbejdet blev udført på isolerede VLAN'er: ACL'er er skrevet til VLAN'erne, som tillader eller nægter en form for forbindelse.
I 2016 nåede antallet af servere 8000. Wargaming absorberede andre studier, og yderligere affiliate-netværk dukkede op. De ser ud til at være vores, men ikke helt: VLAN fungerer ofte ikke for partnere, du skal bruge VPN med VRF, isolation bliver mere kompliceret. ACL-isoleringsblandingen voksede.
Netværksmodel i 2016.
I begyndelsen af 2018 var maskinparken vokset til 16. Der var 000 segmenter, og vi talte ikke resten med, inklusive lukkede, hvori der var lagret økonomiske data. Containernetværk (Kubernetes), DevOps, cloud-netværk forbundet via VPN, for eksempel fra et IVS, er dukket op. Der var mange regler – det var smertefuldt.
Netværksmodel og isolationsmetoder i 2018.
Til isolation brugte vi: VLAN med ACL på L2, VRF med ACL på L3, VPN og meget mere. For meget.
Problemer
Alle lever med ACL og VLAN. Hvad er der galt? Dette spørgsmål vil blive besvaret af Harold, der skjuler smerten.
Der var mange problemer, men der var fem massive.
- Geometrisk prisstigning for nye regler. Hver ny regel tog længere tid at tilføje end den forrige, fordi det var nødvendigt først at se, om der allerede var en sådan regel.
- Ingen firewall inde i segmenter. Segmenterne var på en eller anden måde adskilt fra hinanden, og der var allerede ikke nok ressourcer indeni.
- Reglerne blev anvendt i lang tid. Operatører kunne skrive en lokal regel i hånden på en time. Den globale tog flere dage.
- Vanskeligheder med revisionsregler. Mere præcist var det ikke muligt. De første regler blev skrevet tilbage i 2010, og de fleste af deres forfattere arbejdede ikke længere for virksomheden.
- Lavt niveau af infrastrukturkontrol. Dette er hovedproblemet - vi vidste ikke så godt, hvad der foregik i vores land.
Sådan så en netværksingeniør ud i 2018, da han hørte: "Har brug for noget mere ACL."
Решения
I starten af 2018 blev det besluttet at gøre noget ved det.
Prisen på integrationer vokser konstant. Udgangspunktet var, at store datacentre holdt op med at understøtte isolerede VLAN'er og ACL'er, fordi enhederne løb tør for hukommelse.
Løsning: vi fjernede den menneskelige faktor og automatiserede adgangen til det maksimale.
De nye regler tager lang tid at gælde. Løsning: Fremskynd anvendelsen af regler, gør den distribueret og parallel. Dette kræver et distribueret system, så reglerne leveres selv, uden rsync eller SFTP til tusind systemer.
Ingen firewall inde i segmenter. En firewall inden for segmenter begyndte at komme til os, da forskellige tjenester dukkede op inden for det samme netværk. Løsning: Brug en firewall på værtsniveau - værtsbaserede firewalls. Næsten overalt, hvor vi har Linux, og overalt, hvor vi har iptables, er dette ikke et problem.
Vanskeligheder med revisionsregler. Løsning: Opbevar alle reglerne ét sted til gennemgang og administration, så vi kan revidere alt.
Lavt niveau af kontrol over infrastruktur. Løsning: Tag en opgørelse over alle tjenester og adgange mellem dem.
Dette er mere en administrativ proces end en teknisk. Nogle gange har vi 200-300 nye udgivelser om ugen, især under kampagner og helligdage. Desuden er dette kun for ét hold af vores DevOps. Med så mange udgivelser er det umuligt at se, hvilke porte, IP'er og integrationer der er nødvendige. Derfor havde vi brug for specialuddannede serviceledere, der spurgte teamene: "Hvad er der overhovedet, og hvorfor tog I det op?"
Efter alt, hvad vi lancerede, begyndte en netværksingeniør i 2019 at se sådan ud.
Konsul
Vi besluttede, at vi ville lægge alt, hvad vi fandt, med hjælp fra servicechefer ind i Consul, og derfra ville vi skrive iptables-regler.
Hvordan besluttede vi at gøre dette?
- Vi vil indsamle alle tjenester, netværk og brugere.
- Lad os oprette iptables-regler baseret på dem.
- Vi automatiserer kontrol.
- ....
- PROFIT.
Consul er ikke en ekstern API, den kan køre på hver node og skrive til iptables. Tilbage er kun at komme med automatiske kontroller, der vil rense unødvendige ting ud, og de fleste problemer vil blive løst! Vi finder ud af resten, mens vi går.
Hvorfor konsul?
Har bevist sig godt. I 2014-15 brugte vi det som backend til Vault, hvor vi gemmer adgangskoder.
Taber ikke data. I løbet af brugstiden mistede Consul ikke data under en enkelt ulykke. Dette er et stort plus for et firewall-styringssystem.
P2P-forbindelser fremskynder spredningen af forandringer. Med P2P kommer alle ændringer hurtigt, ingen grund til at vente i timevis.
Praktisk REST API. Vi overvejede også Apache ZooKeeper, men den har ikke en REST API, så du bliver nødt til at installere krykker.
Fungerer både som en Key Vault (KV) og en Directory (Service Discovery). Du kan gemme tjenester, kataloger og datacentre på én gang. Dette er praktisk ikke kun for os, men også for nabohold, for når vi bygger en global service, tænker vi stort.
Skrevet i Go, som er en del af Wargaming-stakken. Vi elsker dette sprog, vi har mange Go-udviklere.
Kraftfuldt ACL-system. I Consul kan du bruge ACL'er til at styre, hvem der skriver hvad. Vi garanterer, at firewall-reglerne ikke vil overlappe med noget andet, og vi vil ikke have problemer med dette.
Men Consul har også sine ulemper.
- Skalerer ikke i et datacenter, medmindre du har en virksomhedsversion. Det kan kun skaleres af forbund.
- Meget afhængig af kvaliteten af netværket og serverbelastning. Consul vil ikke fungere korrekt som server på en travl server, hvis der er forsinkelser i netværket, for eksempel ujævn hastighed. Dette skyldes P2P-forbindelser og opdateringsdistributionsmodeller.
- Svært ved at overvåge tilgængelighed. I konsulstatus kan han sige, at alt er fint, men han døde for længe siden.
Vi løste de fleste af disse problemer, mens vi brugte Consul, og derfor valgte vi det. Virksomheden har planer om en alternativ backend, men vi har lært at håndtere problemer og bor i øjeblikket hos Consul.
Hvordan Consul fungerer
Vi installerer tre til fem servere i et betinget datacenter. En eller to servere vil ikke fungere: de vil ikke være i stand til at organisere et kvorum og beslutte, hvem der har ret, og hvem der er forkert, når dataene ikke stemmer overens. Mere end fem giver ingen mening, produktiviteten vil falde.
Klienter opretter forbindelse til serverne i vilkårlig rækkefølge: de samme agenter, kun med flaget server = false.
Herefter modtager kunderne en liste over P2P-forbindelser og bygger forbindelser indbyrdes.
På globalt plan forbinder vi flere datacentre. De forbinder også P2P og kommunikerer.
Når vi ønsker at hente data fra et andet datacenter, går anmodningen fra server til server. Denne ordning kaldes Serf protokol. Serf-protokollen er ligesom Consul udviklet af HashiCorp.
Nogle vigtige fakta om konsul
Consul har dokumentation, der beskriver, hvordan det fungerer. Jeg vil kun give udvalgte fakta, der er værd at vide.
Konsul-servere vælger en master blandt vælgerne. Consul vælger en master fra listen over servere for hvert datacenter, og alle anmodninger går kun til den, uanset antallet af servere. Mesterfrysning fører ikke til genvalg. Hvis masteren ikke er valgt, betjenes anmodninger ikke af nogen.
Ønskede du vandret skalering? Undskyld, nej.
En forespørgsel til et andet datacenter går fra master til master, uanset hvilken server den kom til. Den valgte master modtager 100 % af belastningen, bortset fra belastningen ved videresendelsesanmodninger. Alle servere i datacentret har en opdateret kopi af dataene, men kun én svarer.
Den eneste måde at skalere på er at aktivere gammel tilstand på klienten.
I gammel tilstand kan du svare uden beslutningsdygtighed. Dette er en tilstand, hvor vi opgiver datakonsistens, men læser lidt hurtigere end normalt, og enhver server reagerer. Naturligvis kun optagelse gennem masteren.
Consul kopierer ikke data mellem datacentre. Når en føderation er samlet, vil hver server kun have sine egne data. For andre henvender han sig altid til en anden.
Atomiciteten af operationer er ikke garanteret uden for en transaktion. Husk, at du ikke er den eneste, der kan ændre tingene. Hvis du vil have det anderledes, så lav en transaktion med en lås.
Blokeringsoperationer garanterer ikke låsning. Forespørgslen går fra master til master, og ikke direkte, så der er ingen garanti for, at blokeringen virker, når du for eksempel blokerer i et andet datacenter.
ACL garanterer heller ikke adgang (i mange tilfælde). ACL'en fungerer muligvis ikke, fordi den er gemt i ét føderationsdatacenter - i ACL-datacentret (Primær DC). Hvis DC ikke svarer dig, vil ACL ikke fungere.
En frossen mester vil få hele forbundet til at fryse. For eksempel er der 10 datacentre i en føderation, og et har et dårligt netværk, og en master fejler. Alle, der kommunikerer med ham, vil fryse i en cirkel: der er en anmodning, der er intet svar på det, tråden fryser. Der er ingen måde at vide, hvornår dette vil ske, bare om en time eller to vil hele forbundet falde. Der er ikke noget, du kan gøre ved det.
Status, beslutningsdygtighed og valg håndteres af en særskilt tråd. Genvalg vil ikke ske, status vil ikke vise noget. Du tror, at du har en levende konsul, spørger du, og der sker ikke noget - der er intet svar. Status viser samtidig, at alt er i orden.
Vi er stødt på dette problem og var nødt til at genopbygge bestemte dele af datacentre for at undgå det.
Businessversionen af Consul Enterprise har ikke nogle af ulemperne ovenfor. Det har mange nyttige funktioner: udvælgelse af vælgere, distribution, skalering. Der er kun et "men" - licenssystemet for et distribueret system er meget dyrt.
Livet hacking: rm -rf /var/lib/consul - en kur mod alle sygdomme i midlet. Hvis noget ikke virker for dig, skal du bare slette dine data og downloade dataene fra en kopi. Konsul vil højst sandsynligt arbejde.
BEFW
Lad os nu tale om, hvad vi har tilføjet til Consul.
er et akronym for BackEndFjeg vil gåWalle. Jeg var nødt til at navngive produktet på en eller anden måde, da jeg oprettede depotet for at sætte de første test-commits ind i det. Dette navn forbliver.
Regel skabeloner
Reglerne er skrevet i iptables-syntaks.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m tilstand—tilstand RELATED,ETABLISTERET -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Alt går ind i BEFW-kæden, undtagen ESTABLISHED, RELATED og lokalvært. Skabelonen kan være hvad som helst, dette er blot et eksempel.
Hvordan er BEFW nyttig?
Services
Vi har en tjeneste, den har altid en port, en node, den kører på. Fra vores node kan vi lokalt spørge agenten og finde ud af, at vi har en form for service. Du kan også sætte tags.
Enhver tjeneste, der kører og er registreret hos Consul, bliver til en iptables-regel. Vi har SSH - åben port 22. Bash-scriptet er enkelt: curl og iptables, andet er ikke nødvendigt.
Kunder
Hvordan åbner man adgang ikke for alle, men selektivt? Tilføj IP-lister til KV-lager efter tjenestenavn.
For eksempel ønsker vi, at alle på det tiende netværk skal kunne få adgang til SSH_TCP_22-tjenesten. Tilføj et lille TTL-felt? og nu har vi midlertidige tilladelser for eksempel for en dag.
Adgange
Vi forbinder tjenester og kunder: Vi har en service, KV-lager er klar til hver. Nu giver vi adgang ikke til alle, men selektivt.
Grupper
Hvis vi skriver tusindvis af IP'er til adgang hver gang, bliver vi trætte. Lad os komme med grupperinger - en separat delmængde i KV. Lad os kalde det Alias (eller grupper) og gemme grupper der efter samme princip.
Lad os forbinde: nu kan vi åbne SSH ikke specifikt for P2P, men for en hel gruppe eller flere grupper. På samme måde er der TTL - du kan tilføje til en gruppe og fjerne fra gruppen midlertidigt.
integration
Vores problem er den menneskelige faktor og automatisering. Indtil videre har vi løst det på denne måde.
Vi samarbejder med Puppet, og overfører alt, hvad der vedrører systemet (applikationskode) til dem. Puppetdb (almindelig PostgreSQL) gemmer en liste over tjenester, der kører der, de kan findes efter ressourcetype. Der kan du finde ud af, hvem der søger hvor. Vi har også et pull request og merge request system til dette.
Vi skrev befw-sync, en simpel løsning, der hjælper med at overføre data. For det første tilgås synkroniseringscookies af puppetdb. En HTTP API er konfigureret der: vi anmoder om, hvilke tjenester vi har, hvad der skal gøres. Så fremsætter de en anmodning til konsul.
Er der integration? Ja: de skrev reglerne og tillod at pull-anmodninger blev accepteret. Har du brug for en bestemt port eller tilføje en vært til en gruppe? Træk anmodning, anmeld - ikke mere "Find 200 andre ACL'er, og prøv at gøre noget ved det."
Optimering
At pinge localhost med en tom regelkæde tager 0,075 ms.
Lad os tilføje 10 iptables-adresser til denne kæde. Som et resultat vil ping stige 000 gange: iptables er fuldstændig lineært, behandlingen af hver adresse tager noget tid.
For en firewall, hvor vi migrerer tusindvis af ACL'er, har vi en masse regler, og dette introducerer latency. Dette er dårligt for spilprotokoller.
Men hvis vi sætter 10 adresser i ipset Pingen vil endda falde.
Pointen er, at "O" (algoritmekompleksitet) for ipset altid er lig med 1, uanset hvor mange regler der er. Sandt nok er der en begrænsning - der kan ikke være mere end 65535 regler. For nu lever vi med dette: du kan kombinere dem, udvide dem, lave to ipsets i én.
Opbevaring
En logisk fortsættelse af iterationsprocessen er lagring af information om klienter til tjenesten i ipset.
Nu har vi den samme SSH, og vi skriver ikke 100 IP'er på én gang, men angiver navnet på det ipset, som vi skal kommunikere med, og følgende regel DROP. Det kan konverteres til én regel "Hvem er ikke her, DROP", men det er mere klart.
Nu har vi regler og sæt. Hovedopgaven er at lave et sæt før du skriver reglen, for ellers vil iptables ikke skrive reglen.
Generel ordning
I form af et diagram ser alt, hvad jeg sagde, sådan ud.
Vi forpligter os til Puppet, alt sendes til værten, tjenester her, ipset der, og alle, der ikke er registreret der, er ikke tilladt.
Tillad og afvis
For hurtigt at redde verden eller hurtigt deaktivere nogen, lavede vi i begyndelsen af alle kæder to ipsets: rules_allow и rules_deny. Hvordan det virker?
For eksempel opretter nogen en belastning på vores web med bots. Tidligere skulle du finde hans IP fra logfilerne, tage den til netværksingeniører, så de kunne finde kilden til trafikken og forbyde ham. Det ser anderledes ud nu.
Vi sender det til Consul, vent 2,5 sekunder, og det er gjort. Da Consul distribuerer hurtigt gennem P2P, fungerer det overalt, i alle dele af verden.
Engang stoppede jeg på en eller anden måde helt WOT på grund af en fejl med firewallen. rules_allow - det er vores forsikring mod sådanne sager. Hvis vi lavede en fejl et sted med firewallen, er noget blokeret et sted, vi kan altid sende en betinget 0.0/0for hurtigt at samle alt op. Senere ordner vi alt i hånden.
Andre sæt
Du kan tilføje andre sæt i rummet $IPSETS$.
For hvad? Nogle gange har nogen brug for ipset, for eksempel for at efterligne lukningen af en del af klyngen. Alle kan medbringe ethvert sæt, navngive dem, og de vil blive afhentet hos konsul. Samtidig kan sæt enten deltage i iptables reglerne eller fungere som et hold NOOP: Konsistens vil blive vedligeholdt af dæmonen.
Medlemmer
Tidligere var det sådan: brugeren tilsluttede sig netværket og modtog parametre gennem domænet. Før fremkomsten af den nye generation af firewalls vidste Cisco ikke, hvordan man skulle forstå, hvor brugeren var, og hvor IP'en var. Derfor blev der kun givet adgang via maskinens værtsnavn.
Hvad gjorde vi? Vi gik i stå i det øjeblik, vi modtog adressen. Normalt er dette dot1x, Wi-Fi eller VPN - alt går gennem RADIUS. For hver bruger opretter vi en gruppe efter brugernavn og placerer en IP i den med en TTL, der er lig med dens dhcp.lease - så snart den udløber, forsvinder reglen.
Nu kan vi åbne adgang til tjenester, ligesom andre grupper, efter brugernavn. Vi har taget smerten ud af værtsnavne, når de ændrer sig, og vi har taget byrden fra netværksingeniører, fordi de ikke længere har brug for Cisco. Nu registrerer ingeniører selv adgang på deres servere.
Isolering
Samtidig begyndte vi at afmontere isoleringen. Servicechefer tog en opgørelse, og vi analyserede alle vores netværk. Lad os dele dem op i de samme grupper, og på de nødvendige servere blev grupperne f.eks. tilføjet for at nægte. Nu ender den samme iscenesættelsesisolation i produktionens regler_benægtelse, men ikke i selve produktionen.
Ordningen fungerer hurtigt og enkelt: Vi fjerner alle ACL'er fra serverne, losser hardwaren og reducerer antallet af isolerede VLAN'er.
Integritetskontrol
Tidligere havde vi en særlig trigger, der rapporterede, når nogen ændrede en firewall-regel manuelt. Jeg skrev en kæmpe linter for at tjekke firewall-reglerne, det var svært. Integritet er nu kontrolleret af BEFW. Han sørger ivrigt for, at de regler, han laver, ikke ændres. Hvis nogen ændrer firewall-reglerne, vil det ændre alt tilbage. "Jeg satte hurtigt en proxy op, så jeg kunne arbejde hjemmefra" - der er ikke flere sådanne muligheder.
BEFW styrer ipset'et fra tjenesterne og listen i befw.conf, reglerne for tjenester i BEFW-kæden. Men den overvåger ikke andre kæder og regler og andre ipsets.
Beskyttelse mod sammenstød
BEFW gemmer altid den sidst kendte gode tilstand direkte i den binære struktur state.bin. Hvis noget går galt, ruller det altid tilbage til denne tilstand.bin.
Dette er forsikring mod ustabil Consul-drift, når den ikke sendte data, eller nogen lavede en fejl og brugte regler, der ikke kan anvendes. For at sikre, at vi ikke står uden en firewall, vil BEFW rulle tilbage til den seneste tilstand, hvis der opstår en fejl på noget tidspunkt.
I kritiske situationer er dette en garanti for, at vi står tilbage med en fungerende firewall. Vi åbner alle grå netværk i håb om, at administratoren kommer og ordner det. En dag vil jeg sætte dette i konfigurationerne, men nu har vi bare tre grå netværk: 10/8, 172/12 og 192.168/16. Inden for vores konsul er dette en vigtig funktion, som hjælper os med at udvikle os yderligere.
Demo: under rapporten demonstrerer Ivan BEFW's demotilstand. Det er nemmere at se demonstrationen . Demokildekode tilgængelig .
Faldgruber
Jeg vil fortælle dig om de fejl, vi stødte på.
ipset add sæt 0.0.0.0/0. Hvad sker der, hvis du tilføjer 0.0.0.0/0 til ipset? Vil alle IP'er blive tilføjet? Vil internetadgang være tilgængelig?
Nej, vi får en fejl, der kostede os to timers nedetid. Desuden har fejlen ikke virket siden 2016, den er placeret i RedHat Bugzilla under nummer #1297092, og vi fandt den ved et uheld - fra en udviklerrapport.
Det er nu en streng regel hos BEFW, at 0.0.0.0/0 bliver til to adresser: 0.0.0.0/1 и 128.0.0.0/1.
ipset gendan sæt < fil. Hvad gør ipset, når du fortæller det restore? Tror du det virker på samme måde som iptables? Vil det gendanne data?
Intet som det - det smelter sammen, og de gamle adresser går ingen steder, du blokerer ikke adgang.
Vi fandt en fejl, da vi testede isolation. Nu er der et ret komplekst system – i stedet for restore gennemført create temp, så restore flush temp и restore temp. I slutningen af swap: for atomicitet, fordi hvis du gør det først flush og i dette øjeblik ankommer en pakke, den vil blive kasseret, og noget vil gå galt. Så der er lidt sort magi der.
konsul kv få -datacenter=andet. Som sagt tror vi, vi beder om nogle data, men vi får enten data eller en fejl. Vi kan gøre dette via Consul lokalt, men i dette tilfælde vil begge fryse.
Den lokale Consul-klient er en indpakning over HTTP API. Men den hænger bare og reagerer ikke kun på Ctrl+C eller Ctrl+Z eller noget kill -9 i den næste konsol. Det stødte vi på, da vi byggede en stor klynge. Men vi har ikke en løsning endnu; vi forbereder os på at rette denne fejl i Consul.
Konsulens leder svarer ikke. Vores mester i datacentret svarer ikke, vi tænker: "Måske vil genvalgsalgoritmen fungere nu?"
Nej, det vil ikke virke, og overvågning vil ikke vise noget: Konsul vil sige, at der er et engagementsindeks, en leder er fundet, alt er i orden.
Hvordan håndterer vi dette? service consul restart i cron hver time. Hvis du har 50 servere, er der ingen big deal. Når der er 16 af dem, vil du forstå, hvordan det fungerer.
Konklusion
Som et resultat fik vi følgende fordele:
- 100% dækning af alle Linux-maskiner.
- Hastighed.
- Automatisering.
- Vi befriede hardware- og netværksingeniører fra slaveri.
- Der er dukket op integrationsmuligheder, der er næsten ubegrænsede: selv med Kubernetes, selv med Ansible, endda med Python.
Cons: Konsul, som vi nu skal leve med, og de meget høje omkostninger ved fejl. Som et eksempel, en gang kl. 6 (primetime i Rusland) var jeg ved at redigere noget i listerne over netværk. Vi byggede bare isolering på BEFW på det tidspunkt. Jeg lavede en fejl et sted, det ser ud til, at jeg har angivet den forkerte maske, men alt faldt på to sekunder. Overvågningen lyser, den vagthavende støtteperson kommer løbende: "Vi har alt!" Afdelingslederen blev grå, da han forklarede forretningen, hvorfor det skete.
Omkostningerne ved fejl er så høje, at vi har fundet frem til vores egen komplekse forebyggelsesprocedure. Hvis du implementerer dette på et stort produktionssted, behøver du ikke give en master-token over Consul til alle. Det vil ende galt.
Omkostningerne. Jeg skrev kode til 400 timer alene. Mit team på 4 personer bruger 10 timer om måneden på support til alle. Sammenlignet med prisen på enhver ny generation af firewall, er det gratis.
Planer. Den langsigtede plan er at finde alternativ transport til at erstatte eller supplere Consul. Måske bliver det Kafka eller noget lignende. Men i de kommende år kommer vi til at leve af Consul.
Umiddelbare planer: integration med Fail2ban, med overvågning, med nftables, eventuelt med andre distributioner, metrics, avanceret overvågning, optimering. Kubernetes support er også et sted i planerne, for nu har vi flere klynger og lysten.
Mere fra planerne:
- søge efter uregelmæssigheder i trafikken;
- forvaltning af netværkskort;
- Kubernetes support;
- samle pakker til alle systemer;
- Web-UI.
Vi arbejder konstant på at udvide konfigurationen, øge målinger og optimering.
Deltag i projektet. Projektet viste sig at være fedt, men desværre er det stadig et enkeltmandsprojekt. Kom til og prøv at gøre noget: forpligte, teste, foreslå noget, give din vurdering.
Imens forbereder vi os , som finder sted den 6. og 7. april i Sankt Petersborg, og vi inviterer udviklere af højbelastningssystemer . Erfarne foredragsholdere ved allerede, hvad de skal gøre, men for dem, der er nye til at tale, anbefaler vi i det mindste . At deltage i konferencen som foredragsholder har en række fordele. Du kan for eksempel læse hvilke til sidst .
Kilde: www.habr.com