Consul + iptables = :3

År 2010 hade företaget Wargaming 50 servrar och en enkel nätverksmodell: backend, frontend och brandvägg. Antalet servrar ökade, modellen blev mer komplex: stagingar, isolerade VLAN med ACL, sedan VPN med VRF, VLAN med ACL på L2, VRF med ACL på L3. Snurrar det i huvudet? Det blir roligare längre fram.

När antalet servrar nådde 16 000 blev det omöjligt att arbeta utan problem med så många olika segment. Så vi kom på en annan lösning. Vi använde Netfilter-stacken och lade till Consul som datakälla, vilket resulterade i en snabb distribuerad brandvägg. Vi ersatte ACL på routrarna och använde den som extern och intern brandvägg. För dynamisk hantering av verktyget utvecklade vi BEFW-systemet, som tillämpades överallt: från hantering av användartillgång i det produktiva nätverket till isolering av nätverkssegment från varandra.

Hur detta fungerar och varför du bör titta närmare på detta system kommer att berätta Ivan Agarov (annmuor) — chef för infrastruktursäkerhetsgruppen inom underhållsdivisionen vid Wargaming i Minsk. Ivan är en fan av SELinux, älskar Perl och skriver kod. Som chef för informationssäkerhetsgruppen arbetar han regelbundet med loggar, säkerhetskopior och R&D för att skydda Wargaming från hackare och säkerställa driften av alla företagets spelservrar.

Historisk översikt

Innan jag berättar hur vi gjorde detta, ska jag förklara hur vi kom hit och varför det behövdes. För detta, låt oss resa nio år tillbaka: år 2010, när World of Tanks precis hade lanserats. Wargaming hade ungefär 50 servrar.

Graf över företagets servertillväxt.

Vi hade en nätverksmodell. För den tiden var den optimal.

Nätverksmodellen 2010.

I frontenden finns de dåliga killarna som vill krossa oss, men det finns en brandvägg. I backend finns det ingen brandvägg, men där finns 50 servrar, och vi känner till dem alla. Allt fungerar bra.

Under fyra år vuxit serverparken hundrafaldigt, till 5000. De första isolerade nätverken — stagingar — dök upp: de kan inte gå i produktion, och där fanns ofta sådant som kunde vara farligt.

Nätverksmodellen 2014.

Av ren vana använde vi fortfarande samma hårdvara, och allt arbete utfördes på isolerade VLAN: ACL skrivs till VLAN som tillåter eller blockerar vissa anslutningar.

År 2016 nådde antalet servrar 8000. Wargaming förvärvade andra studior, och ytterligare partnernätverk tillkom. De verkar vara våra, men är inte helt så: för partner fungerade VLAN ofta inte, man behövde använda VPN med VRF, och isoleringarna blev svårare. Blandningen av ACL-isoleringar växte.

Nätverksmodellen år 2016.

I början av 2018 hade maskinparken vuxit till 16 000. Det fanns 6 segment, och de andra räknade vi inte, inklusive de som var stängda, där finansiella data förvarades. Det dök upp containernätverk (Kubernetes), DevOps, molnnätverk som anslöts via VPN, till exempel från IWS. Det fanns väldigt många regler – det var smärtsamt.

Nätverksmodellen och isoleringssätten år 2018.

För isolering använde vi: VLAN med ACL på L2, VRF med ACL på L3, VPN och mycket annat. För många.

Problem

Alla lever med ACL och VLAN. Vad är egentligen problemet? Den frågan kommer Harold att svara på, som döljer sin smärta.

Det fanns många problem, men få av dem var massiva.

• Geometrisk prishöjning för nya regler. Varje ny regel tog längre tid att lägga till än den föregående, eftersom man först var tvungen att kolla om det redan fanns en sådan regel.
• Ingen brandvägg inom segmenten. Segmenten var på något sätt åtskilda, men innanför fanns det inte tillräckligt med resurser.
• Reglerna tillämpades långsamt. Med manuellt skrivna lokala regler kunde operatörerna skriva en på en timme. Globala tog flera dagar.
• Svårigheter med reglernas granskning. Eller snarare, det var omöjligt. De första reglerna skrevs redan 2010, och de flesta av deras författare arbetade inte längre i företaget.
• Låg kontrollnivå över infrastrukturen. Det är det största problemet - vi visste dåligt vad som egentligen hände.

Så här såg en nätverksingenjör ut år 2018 när han hörde: "Vi behöver lite mer ACL".

Lösningar

I början av 2018 beslutades det att göra något åt detta.

Kostnaden för integrationer växer konstant. Utgångspunkten var att stora datacenter slutade stödja isolerade VLAN och ACL, eftersom minnet på enheterna tog slut.

Lösningen: att ta bort den mänskliga faktorn och automatisera åtkomsten i största möjliga utsträckning.

Nya regler tillämpas långsamt. Lösningen: snabba upp tillämpningen av regler, göra den distribuerad och parallell. För detta behövs ett distribuerat system så att regler levereras automatiskt, utan rsync eller SFTP till tusen system.

Avsaknad av brandvägg inom segmenten. Brandväggar inom segmenten började påverka oss när olika tjänster uppträdde inom samma nätverk. Lösningen: använd brandvägg på värdnivå — host-baserade brandväggar. Praktiskt taget överallt använder vi Linux, och överallt har vi iptables, det är inget problem.

Svårigheter med granskning av regler. Lösningen: lagra alla regler på ett och samma ställe för översikt och hantering, så att vi kan granska allt.

Låg kontrollnivå över infrastrukturen. Lösningen: genomför en inventering av alla tjänster och åtkomster mellan dem.

Detta är mer en administrativ process än en teknisk. Ibland har vi 200-300 nya releaser per vecka, särskilt under kampanjer och helgdagar. Detta gäller bara för ett team av våra DevOps. Med så många releaser är det omöjligt att se och förstå vilka portar, IP-adresser och integrationer som behövs. Därför behövde vi särskilt utbildade servicechefer som intervjuade teamen: "Vad finns överhuvudtaget och varför har ni startat detta?"

Efter allt vi har lanserat ser nätverksingenjören redan ut så här år 2019.

Consul

Vi beslutade att allt vi hittade med hjälp av servicecheferna skulle placeras i Consul och därifrån skulle vi skriva iptables-regler.

Hur beslutade vi att göra detta?

• Vi samlar alla tjänster, nätverk och användare.
• Vi skapar iptables-regler baserade på dem.
• Vi automatiserar kontrollen.
• ….
• VINST.

Consul är ingen fjärr-API, den kan fungera på varje nod och skriva till iptables. Återstår att komma på automatiska kontrollverktyg som rensar bort det överflödiga, och en stor del av problemen kommer att lösas! Det övriga förbättrar vi under processen.

Varför Consul?

Har visat sig vara tillförlitlig. Vi använde den som backend för Vault mellan 2014 och 2015, där vi lagrar lösenord.

Förlorar inte data.. Under hela tiden vi använde Consul har den inte förlorat data vid en enda incident. Detta är en stor fördel för systemet för brandväggshantering.

P2P-kopplingar påskyndar spridningen av förändringar.. Med P2P kommer alla förändringar snabbt, man behöver inte vänta i timmar.

Bekväm REST API. Vi övervägde även Apache ZooKeeper, men den har ingen REST API, man får använda knep.

Fungerar både som nyckelförvaring (KV) och som katalog (Service Discovery).. Man kan lagra tjänster, kataloger och datacenter på en gång. Detta är bekvämt inte bara för oss utan även för angränsande team, eftersom vi tänker globalt när vi bygger en stor tjänst.

Skriven i Go, vilket ingår i Wargaming-teknologin. Vi älskar detta språk, vi har många Go-utvecklare.

Ett kraftfullt ACL-system. Med hjälp av ACL i Consul kan vi styra vem som får skriva och vad. Vi garanterar att brandväggsreglerna inte kommer att krocka med något annat och att vi inte kommer att ha problem med detta.

Men Consul har också nackdelar.

• Det skalar inte inom datacenter om du inte har affärsversionen. Det skalar endast genom federation.
• Mycket beroende av nätverkskvalitet och serverbelastning. Consul fungerar inte korrekt som server på en överbelastad server om det finns några laggar i nätverket, till exempel ojämn hastighet. Det beror på P2P-anslutningar och modeller för uppdateringsfördelning.
• Svårigheter med att övervaka tillgänglighet. I Consuls status kan det stå att allt är bra, men den har redan dött för länge sedan.

De flesta av dessa problem löste vi under driften av Consul, och därför valde vi det. Företaget har planer på en alternativ backend, men vi har lärt oss att hantera problem och lever för tillfället med Consul.

Hur Consul fungerar

I det hypotetiska datacentret installerar vi servrar - från tre till fem. En eller två servrar fungerar inte: de kan inte organisera quorum och avgöra vem som har rätt när data inte stämmer. Fler än fem är meningslöst, prestandan kommer att minska.

Kunder kopplar upp sig till servrarna i valfri ordning: samma agenter, men med flaggan server = false.

Efter detta får kunderna en lista med P2P-anslutningar och bygger relationer sinsemellan.

På global nivå kopplar vi samman flera datacenter. De kopplas också samman P2P och kommunicerar.

När vi vill hämta data från ett annat datacenter går förfrågan från server till server. Denna struktur kallas Serf-protokollet. Serf-protokollet, liksom Consul, är utvecklat av HashiCorp.

Några viktiga fakta om Consul

Consul har dokumentation som beskriver dess funktion. Jag ger endast utvalda fakta som är värda att veta.

Consul-servrar väljer en master bland de röstberättigade. Consul väljer en master från listan över servrar för varje datacenter, och alla förfrågningar går endast till denne, oavsett antalet servrar. Om mastern hänger följs inga omröstningar. Om ingen master är vald – hanteras inga förfrågningar.

Ville du ha horisontell skalning? Tyvärr, nej.

Förfrågan till ett annat datacenter går från master till master, oavsett vilken server den kom till. Den valda mastern får 100% av belastningen, förutom lasten för att vidarebefordra förfrågningar. En aktuell kopia av data finns på alla servrar i datacentret, men bara en svarar.

Det enda sättet att skala är att aktivera stale-läget på klienten.

I stale-läget kan man svara utan kvorum. Detta är ett läge där vi avstår från datakonsistens, men läser något snabbare än normalt, och vilken server som helst kan svara. Naturligtvis, skrivning görs endast via master.

Consul kopierar inte data mellan datacenter. Vid federationsuppbyggnad kommer varje server endast att ha sina egna data. För andra hänvisar den alltid till någon annan.

Atomaritet av operationer garanteras inte utanför en transaktion. Kom ihåg att du inte bara kan ändra något. Om du vill göra det på ett annat sätt, genomför en transaktion med lås.

Blockerande operationer garanterar inte låsning. Förfrågan går från master till master, inte direkt, så det finns inga garantier för att låsningen fungerar när du gör låsning, till exempel, i ett annat datacenter.

ACL garanterar inte heller åtkomst (i många fall). ACL kan misslyckas, eftersom den lagras i ett datacenter i federation — i ACL datacenter (Primärt DC). Om DC inte svarar, kommer ACL inte att fungera.

En hängande master kommer att leda till att hela federationen hänger. Till exempel, i federationen finns 10 datacenter, och i ett finns ett dåligt nätverk, vilket leder till att en master går ner. Alla som kommunicerar med den kommer att hänga i en loop: det kommer en förfrågan, men inget svar, tråden hänger. Det går inte att veta när detta kommer att hända, bara efter en timme eller två kommer hela federationen att gå ner. Du kommer inte kunna göra något åt det.

Status, kvorum och val hanteras av en separat tråd. Omskolning kommer inte att ske, status visar inget. Du tror att du har en levande Consul, gör en förfrågan och inget händer — inget svar. Samtidigt visar status att allt är bra.

Vi har stött på det här problemet, vi har behövt omstrukturera specifika delar av datacenter för att undvika det.

I affärsversionen av Consul Enterprise finns vissa av bristerna ovan inte.. Det finns många användbara funktioner: röstningsval, fördelning, skalning. Det finns bara en nackdel – licenssystemet för det distribuerade systemet är mycket dyrt.

Livhack: rm -rf /var/lib/consul – panacea för alla problem med agenten. Om något inte fungerar, tar du bara bort dina data och laddar ned data från en kopia. Förmodligen kommer Consul att fungera igen.

BEFW

Nu ska vi prata om vad vi har lagt till i Consul.

BEFW – är en akronym för BackEndFireWall. Vi var tvungna att ge produkten ett namn när jag skapade repositoryt för att placera de första testcommits. Det namnet är kvar.

Regelmallar

Reglerna skrivs i iptables-syntax.

• -N BEFW
• -P INPUT DROP
• -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
• -A INPUT -i lo -j ACCEPT
• -A INPUT -j BEFW

All vår trafik går till BEFW-kedjan, förutom ESTABLISHED., RELATED och localhost. Mallen kan vara vad som helst, det här är bara ett exempel.

Vad är BEFW bra för?

Tjänster

Vi har en tjänst, den har alltid en port, en nod där den körs. Från vår nod kan vi lokalt fråga agenten och ta reda på att vi har en viss tjänst. Det går också att sätta taggar.

Varje tjänst som körs och registreras i Consul blir en iptables-regel. Vi har SSH – vi öppnar port 22. Bash-scriptet är enkelt: curl och iptables, inget mer som behövs.

Kunder

Hur öppnar man åtkomst inte för alla, utan selektivt? Genom att lägga IP-listor i KV-lagringen baserat på tjänstens namn.

Till exempel vill vi att alla från det tionde nätverket ska kunna komma åt tjänsten SSH_TCP_22. Vi lägger till ett litet fält TTL? och nu har vi tidsbegränsade tillstånd, till exempel i ett dygn.

Åtkomster

Vi kopplar samman tjänster och kunder: vi har en tjänst där vi alltid har ett KV-lager redo. Nu ger vi åtkomst inte till alla, utan selektivt.

Grupper

Om vi varje gång ska skriva tusentals IP för åtkomster så kommer vi bli trötta. Vi hittar på grupper – en enskild subset i KV. Vi döper den till Alias (eller grupper) och lagrar grupper där på samma princip.

Kopplar samman: nu kan vi öppna SSH inte specifikt för P2P, utan för en hel grupp eller flera grupper. Precis som med TTL – vi kan temporärt lägga till eller ta bort från gruppen.

Integration

Vår utmaning – den mänskliga faktorn och automation. Så här har vi löst det fram tills nu.

Vi arbetar med Puppet och överför allt relaterat till systemet (applikationskod) dit. I puppetdb (vanlig PostgreSQL) lagras en lista över tjänster som körs där, och de kan hittas efter resurstyp. Där kan man också se vem som kommunicerar med vad. Dessutom har vi ett system för pull requests och merge requests för detta.

Vi har skrivit befw-sync — en enkel lösning som hjälper till att överföra data. Först kontaktar sync cookies puppetdb. Där är en HTTP-API inställd: vi begär vilka tjänster vi har och vad som måste göras. Sedan görs en förfrågan till Consul.

Finns det en integration? Ja: vi har skrivit regler och tillåtit att ta emot Pull Requests. Behöver någon port eller lägga till en värd i någon grupp? Pull Request, granskning — inga fler »Hitta 200 andra ACL och försök göra något med dem«.

Optimering

Ping localhost med en tom regelkedja tar 0,075 ms.

Vi lägger till 10 000 adresser till iptables. Som ett resultat ökar pingtiden femfaldigt: iptables är helt linjär, bearbetningen av varje adress tar tid.

För brandväggen dit vi migrerar tusentals ACL har vi många regler, och det medför fördröjning. För spelprotokoll är detta dåligt.

Men om vi placerar 10 000 adresser i ipset minskar pingtiden till och med.

Poängen är att "O" (algoritmkomplexitet) för ipset alltid är 1, oavsett hur många regler det finns. Visserligen finns det en begränsning — antalet regler får inte överstiga 65535. Tills vidare lever vi med det: vi kan kombinera dem, utöka, göra två ipset i en.

Lagring

En logisk fortsättning på iterationsprocessen är att lagra information om kunder för tjänsten i ipset.

Nu har vi samma SSH, och vi skriver inte omedelbart 100 IP, utan anger namnet på ipset som vi behöver kommunicera med, och följande regel DROP. Det går att omformulera till en regel "Den som inte är här, är DROP", men det är tydligare så här.

Nu har vi regler och set. Huvuduppgiften är att skapa setet innan vi skriver regeln, för annars registrerar inte iptables regeln.

Översiktsdiagram

Som en schematisk bild ser allt jag har berättat ut så här.

Vi commit:ar till Puppet, allt skickas till värden, tjänster här, ipset där, och den som inte är registrerad där får inte komma in.

Tillåta & avvisa

För att snabbt rädda världen eller snabbt stänga av någon, skapade vi i början av alla kedjor två ipset: rules_allow och rules_deny. Hur fungerar det?

Till exempel, någon skapar belastning på vår webbplats med hjälp av bottar. Tidigare var vi tvungna att hitta IP-adressen via loggarna, ge den till nätverksingenjörer så att de kunde hitta källan till trafiken och blockera den. Nu ser det annorlunda ut.

Vi skickar till Consul, väntar 2,5 sekunder, och är klara. Eftersom Consul snabbt distribuerar via P2P fungerar det överallt i världen.

En gång lyckades jag helt stoppa WOT genom att göra ett misstag med brandväggen. rules_allow — det är vår försäkring mot sådana fall. Om vi gör något fel med brandväggen, där något blockeras, kan vi alltid skicka en villkorlig 0.0/0, för att snabbt återställa allt. Sen kan vi fixa allt manuellt.

Andra set

Vi kan lägga till vilka andra set som helst i utrymmet $IPSETS$.

Varför? Ibland behöver någon ipset, till exempel för att emulera avstängningen av en del av klustret. Alla kan ta med sig vilka set som helst, namnge dem och de kommer att hämtas från Consul. Dessa set kan också delta i iptables-regler, eller fungera som en slags NOOP: konsistensen kommer att upprätthållas av en demon.

Användare

Tidigare var det så här: användaren kopplade upp sig mot nätverket och fick parametrarna via domänen. Innan nästa generations brandväggar förstod Cisco inte skillnaden mellan användaren och IP-adressen. Därför gavs åtkomst endast via maskinens värdnamn.

Vad gjorde vi? Vi insåg oss i ögonblicket av adressmottagningen. Ofta går detta via dot1x, Wi-Fi eller VPN — allt går genom RADIUS. Vi skapar en grupp för varje användare med användarnamnet och placerar IP-adressen i den med en TTL som är lika med hans dhcp.lease — så snart den löper ut, försvinner regeln.

Nu kan vi ge åtkomst till tjänster, precis som i andra grupper, baserat på användarnamn. Vi har blivit av med besväret med värdnamn som ändras, och avlastat nätverksingenjörerna, eftersom de inte längre behöver Cisco. Nu skriver ingenjörerna själva åtkomster på sina servrar.

Isolering

Parallellt började vi undanröja isoleringen. Tjänstecheferna gjorde en inventering och vi analyserade alla våra nätverk. Vi kommer att dela upp dem i liknande grupper, och på de nödvändiga servrarna lade vi till grupper i till exempel deny. Nu hamnar samma isolering för staging i rules_deny för produktionen, men inte i själva produktionen.

Schemat fungerar snabbt och enkelt: vi tar bort alla ACL från servrarna, avlastar hårdvaran, och minskar antalet isolerade VLAN.

Integritetskontroll

Tidigare hade vi en speciell trigger som meddelade när någon manuellt ändrade brandvägtsreglerna. Jag skrev en stor linter för att kontrollera brandvägtsregler, det var utmanande. Nu övervakas integriteten av BEFW. Den ser noga till att de regler den skapar inte ändras. Om någon ändrar brandvägtsreglerna återställer den allt. "Jag satte snabbt upp en proxy för att arbeta hemifrån" — sådana alternativ finns inte längre.

BEFW kontrollerar ipset från tjänster och listan i befw.conf, tjänsternas regler i BEFW-kedjan. Men den övervakar inte andra kedjor och regler samt andra ipset.

Skydd mot krascher

BEFW sparar alltid det senaste lyckade tillståndet direkt i den binära strukturen state.bin. Om något går fel, återgår den alltid till detta state.bin.

Detta är en försäkring mot instabil drift av Consul, när den inte skickar data eller någon gör ett misstag och använder regler som inte kan tillämpas. För att vi inte ska bli utan brandvägg kommer BEFW att återgå till det senaste tillståndet om det uppstår ett fel i något steg.

I kritiska situationer är detta en garanti för att vi förblir med en fungerande brandvägg. Vi öppnar alla grå nätverk i hopp om att administratören kommer och fixar det. En dag ska jag ta med det i konfigarna, men just nu har vi bara tre grå nätverk: 10/8, 172/12 och 192.168/16. Inom vår Consul är detta en viktig funktion som hjälper oss att utvecklas vidare.

Demo: under presentationen visar Ivan BEFW:s demoläge. Det är lättare att följa demon på video. Källkoden för demon finns tillgänglig på GitHub.

Fällor

Jag kommer att berätta om buggarna vi stötte på.

ipset add set 0.0.0.0/0. Vad händer om man lägger till 0.0.0.0/0 i ipset? Kommer alla IP-adresser att läggas till? Kommer internetåtkomsten att öppnas?

Nej, vi får en bugg som kostade oss två timmars driftstopp. Och buggen har inte fungerat sedan 2016, den ligger i RedHat Bugzilla under nummer #1297092, och vi hittade den av en slump — från utvecklarens rapport.

Nu gäller det strikta regeln i BEFW att 0.0.0.0/0 omvandlas till två adresser: 0.0.0.0/1 och 128.0.0.0/1.

ipset restore set < file. Vad gör ipset när du säger till den att återställa? Вы думаете, он работает также, как iptables? Восстановит данные?

Ingenting sådant — den gör en sammanslagning, och de gamla adresserna försvinner inte, du stänger inte åtkomsten.

Vi hittade buggen när vi testade isoleringen. Nu finns det ett ganska komplext system — istället för återställa genomförs create temp, sedan restore flush temp och restore temp. I slutet swap: för atomaritet, för om man först genomför flush Och i det ögonblicket kommer någon paketering att inträffa, då kommer den att avvisas och något kommer att gå fel. Därför finns det lite svart magi.

consul kv get -datacenter=other. Som jag redan har nämnt, vi tror att vi begär vissa data, men vi kommer att få antingen data eller ett fel. Vi kan göra detta via Consul lokalt, men även då kommer både detta och det andra att hänga sig.

Den lokala Consul-klienten är ett wrapper över HTTP API. Men den hänger bara och svarar inte på Ctrl+C, Ctrl+Z eller något annat, bara på , mjukt avsluta processen och stoppa servern ( i den intilliggande konsolen. Vi stötte på detta när vi byggde en stor kluster. Men vi har fortfarande ingen lösning, vi förbereder oss för att åtgärda detta fel i Consul.

Consul-leder svarar inte. Vår mäster har inte svarat i datacentret, vi tänker: "Kanske aktiveras omvalsalgoritmen nu?"

Nej, det kommer inte att hända, och övervakningen visar ingenting: Consul kommer att säga att det finns ett commitment index, ledaren har hittats, allt är bra.

Hur hanterar vi detta? service consul restart i cron varje timme. Om du har 50 servrar - det är inte så farligt. När de blir 16 000, kommer du att förstå hur det fungerar.

Slutsats

Till slut fick vi följande fördelar:

• 100% täckning av alla Linux-maskiner.
• Hastighet.
• Automatisering.
• Vi befriade hårdvaran och nätverksingenjörerna från slaveri.
• Möjligheterna för integration har blivit nästan obegränsade: antingen med Kubernetes, Ansible eller Python.

Nackdelar: Consul, som vi nu måste leva med, och en mycket hög kostnad för fel. Som exempel, en gång vid 18-tiden (prime time i Ryssland) ändrade jag något i nätverkslistorna. Vi höll på att bygga isolering på BEFW. Jag gjorde någon form av fel, verkade som jag angav en felaktig mask, men allt kraschade på två sekunder. Övervakningen tänds, supportassistenten kommer springande: "Vi ligger alla ner!". Chefens hår blev grått när han förklarade för företaget varför detta hände.

Kostnaden för fel är så hög att vi har kommit på en egen komplicerad förebyggande åtgärd. Om du ska implementera detta i en stor produktion, ge inte mästertoken över Consul till alla. Det kommer att sluta dåligt.

Kostnad. Jag skrev kod i 400 timmar på egen hand. För underhåll lägger mitt team på 4 personer 10 timmar i månaden på alla. Jämfört med kostnaden för någon ny generation brandvägg, är detta gratis.

Planer. Den långsiktiga planen är att söka efter alternativ transport istället för eller som komplement till Consul. Kanske blir det Kafka eller något liknande. Men under de närmaste åren kommer vi att leva med Consul.

Nästa steg: integration med Fail2ban, övervakning, nftables, eventuellt med andra distributioner, metriker, utökad övervakning, optimering. Stöd för Kubernetes är också på gång, eftersom vi för närvarande har flera kluster och intresse.

Andra planer:

• anomalidetektering i trafiken;
• hantering av nätverkskartan;
• stöd för Kubernetes;
• paketkompilering för alla system;
• Webb-UI.

Vi arbetar kontinuerligt med att utöka konfigurationen, öka metrikerna och optimera.

Gå med i projektet. Projektet har blivit fantastiskt, men tyvärr är det för närvarande ett enmansprojekt. Kom till GitHub och försök göra något: kommitta, testa, föreslå något, ge din feedback.

Under tiden förbereder vi oss för Saint HighLoad++, som äger rum den 6 och 7 april i Sankt Petersburg, och vi bjuder in utvecklare av högbelastade system att ansöka om att hålla ett föredrag. Erfaren talare vet redan vad de ska göra, och vi rekommenderar att nybörjare i presentationer åtminstone prova. Deltagande i konferensen som talare har flera fördelar. Vilka, kan man läsa om i slutet av denna artikel.

Källa: habr.com