In 2010 het die maatskappy daar was 50 bedieners en 'n eenvoudige netwerkmodel: backend, frontend en firewall. Die aantal bedieners het gegroei, die model het meer kompleks geword: opstel, geïsoleerde VLAN's met ACL's, dan VPN's met VRF's, VLAN's met ACL's op L2, VRF's met ACL's op L3. Die kop draai? Dit sal later meer pret wees.
Toe daar 16 000 bedieners was, het dit onmoontlik geword om sonder trane te werk met soveel heterogene segmente. Ons het dus met 'n ander oplossing vorendag gekom. Ons het die Netfilter-stapel geneem, Consul daarby gevoeg as 'n databron, en ons het 'n vinnig verspreide firewall gekry. Hulle het ACL's op routers vervang en dit as 'n eksterne en interne firewall gebruik. Om die instrument dinamies te bestuur, het ons die BEFW-stelsel ontwikkel, wat oral gebruik is: van die bestuur van gebruikerstoegang tot die produknetwerk tot die isolering van netwerksegmente van mekaar.
Hy sal jou vertel hoe dit alles werk en hoekom jy hierdie stelsel van nader moet bekyk. Ivan Agarkov () is die hoof van die infrastruktuursekuriteitsgroep van die Onderhoudsafdeling by die maatskappy se Minsk-ontwikkelingsentrum. Ivan is 'n SELinux-aanhanger, is mal oor Perl en skryf kode. As hoof van die inligtingsekuriteitsgroep werk hy gereeld met logs, rugsteun en R&D om Wargaming teen kuberkrakers te beskerm en die werking van alle speletjiebedieners in die maatskappy te verseker.
Historiese inligting
Voordat ek jou vertel hoe ons dit gedoen het, sal ek jou vertel hoe ons in die eerste plek hiertoe gekom het en hoekom dit nodig was. Om dit te doen, kom ons gaan 9 jaar terug: 2010, World of Tanks het pas verskyn. Wargaming het ongeveer 50 bedieners gehad.
Maatskappy bediener groei grafiek.
Ons het 'n netwerkmodel gehad. Vir daardie tyd was dit optimaal.
Netwerkmodel in 2010.
Daar is slegte ouens aan die voorkant wat ons wil breek, maar dit het 'n firewall. Daar is geen firewall op die agterkant nie, maar daar is 50 bedieners daar, ons ken hulle almal. Alles werk goed.
In 4 jaar het die bedienervloot 100 keer gegroei, tot 5000. Die eerste geïsoleerde netwerke het verskyn - staging: hulle kon nie na produksie gaan nie, en daar was dikwels dinge aan die gang wat gevaarlik kon wees.
Netwerkmodel in 2014.
Deur traagheid het ons dieselfde stukke hardeware gebruik, en al die werk is op geïsoleerde VLAN's uitgevoer: ACL's word na die VLAN's geskryf, wat 'n soort verbinding toelaat of ontken.
In 2016 het die aantal bedieners 8000 XNUMX bereik. Wargaming het ander ateljees geabsorbeer, en bykomende geaffilieerde netwerke het verskyn. Dit lyk of dit ons s'n is, maar nie heeltemal nie: VLAN werk dikwels nie vir vennote nie, jy moet VPN met VRF gebruik, isolasie word meer ingewikkeld. Die ACL-isolasiemengsel het gegroei.
Netwerkmodel in 2016.
Teen die begin van 2018 het die vloot masjiene gegroei tot 16 000. Daar was 6 segmente, en ons het nie die res getel nie, insluitend geslote waarin finansiële data gestoor is. Houernetwerke (Kubernetes), DevOps, wolknetwerke wat via VPN verbind is, byvoorbeeld vanaf 'n IVS, het verskyn. Daar was baie reëls – dit was pynlik.
Netwerkmodel en isolasiemetodes in 2018.
Vir isolasie het ons gebruik: VLAN met ACL op L2, VRF met ACL op L3, VPN en nog baie meer. Te veel.
probleme
Almal leef met ACL en VLAN. Wat is fout? Hierdie vraag sal deur Harold beantwoord word, wat die pyn wegsteek.
Daar was baie probleme, maar daar was vyf groot probleme.
- Meetkundige prysverhoging vir nuwe reëls. Elke nuwe reël het langer geneem om by te voeg as die vorige een, want dit was nodig om eers te kyk of daar reeds so 'n reël was.
- Geen firewall binne segmente nie. Die segmente was op een of ander manier van mekaar geskei, en daar was reeds nie genoeg hulpbronne binne nie.
- Die reëls is lank toegepas. Operateurs kan een plaaslike reël binne 'n uur met die hand skryf. Die globale een het etlike dae geneem.
- Probleme met ouditreëls. Meer presies, dit was nie moontlik nie. Die eerste reëls is in 2010 geskryf, en die meeste van hul skrywers het nie meer vir die maatskappy gewerk nie.
- Lae vlak van infrastruktuurbeheer. Dit is die grootste probleem - ons het nie goed geweet wat hier aangaan nie.
Dit is hoe 'n netwerkingenieur in 2018 gelyk het toe hy gehoor het: "Need some more ACL."
Oplossings
Aan die begin van 2018 is besluit om iets daaromtrent te doen.
Die prys van integrasies groei voortdurend. Die beginpunt was dat groot datasentrums opgehou het om geïsoleerde VLAN's en ACL's te ondersteun omdat die toestelle se geheue opraak.
Oplossing: ons het die menslike faktor verwyder en die voorsiening van toegang tot die maksimum geoutomatiseer.
Die nuwe reëls neem lank om toe te pas. Oplossing: versnel die toepassing van reëls, maak dit verspreid en parallel. Dit vereis 'n verspreide stelsel sodat die reëls self afgelewer word, sonder rsync of SFTP aan 'n duisend stelsels.
Geen firewall binne segmente nie. 'n Firewall binne segmente het na ons begin kom toe verskillende dienste binne dieselfde netwerk verskyn het. Oplossing: gebruik 'n brandmuur op die gasheervlak - gasheergebaseerde firewalls. Byna oral waar ons Linux het, en oral waar ons iptables het, is dit nie 'n probleem nie.
Probleme met ouditreëls. Oplossing: Hou al die reëls op een plek vir hersiening en bestuur, sodat ons alles kan oudit.
Lae vlak van beheer oor infrastruktuur. Oplossing: maak 'n inventaris van alle dienste en toegang tussen hulle.
Dit is meer 'n administratiewe proses as 'n tegniese een. Soms het ons 200-300 nuwe vrystellings per week, veral tydens promosies en vakansiedae. Boonop is dit slegs vir een span van ons DevOps. Met soveel vrystellings is dit onmoontlik om te sien watter poorte, IP's en integrasies nodig is. Daarom het ons spesiaal opgeleide diensbestuurders nodig gehad wat die spanne gevra het: "Wat is daar in elk geval en hoekom het julle dit aan die orde gestel?"
Na alles wat ons van stapel gestuur het, het 'n netwerkingenieur in 2019 so begin lyk.
konsul
Ons het besluit dat ons alles wat ons gevind het met die hulp van diensbestuurders in Consul sal sit en van daar af sal ons iptables reëls skryf.
Hoe het ons besluit om dit te doen?
- Ons sal alle dienste, netwerke en gebruikers versamel.
- Kom ons skep iptables-reëls op grond daarvan.
- Ons outomatiseer beheer.
- ....
- WINS.
Consul is nie 'n afgeleë API nie, dit kan op elke nodus loop en na iptables skryf. Al wat oorbly is om met outomatiese kontroles vorendag te kom wat onnodige goed sal skoonmaak, en die meeste van die probleme sal opgelos word! Ons sal die res uitwerk soos ons gaan.
Hoekom konsul?
Het homself goed bewys. In 2014-15 het ons dit as 'n backend vir Vault gebruik, waarin ons wagwoorde stoor.
Verloor nie data nie. Tydens die gebruikstyd het Consul nie data tydens 'n enkele ongeluk verloor nie. Dit is 'n groot pluspunt vir 'n firewall-bestuurstelsel.
P2P-verbindings versnel die verspreiding van verandering. Met P2P kom alle veranderinge vinnig, jy hoef nie ure te wag nie.
Gerieflike REST API. Ons het ook Apache ZooKeeper oorweeg, maar dit het nie 'n REST API nie, so jy sal krukke moet installeer.
Werk as beide 'n sleutelkluis (KV) en 'n gids (diensontdekking). U kan dienste, katalogusse en datasentrums gelyktydig stoor. Dit is gerieflik nie net vir ons nie, maar ook vir naburige spanne, want wanneer ons 'n globale diens bou, dink ons groot.
Geskryf in Go, wat deel is van die Wargaming-stapel. Ons is mal oor hierdie taal, ons het baie Go-ontwikkelaars.
Kragtige ACL-stelsel. In Consul kan jy ACL's gebruik om te beheer wie wat skryf. Ons waarborg dat die firewall-reëls nie met enigiets anders sal oorvleuel nie en ons sal nie probleme hiermee hê nie.
Maar Konsul het ook sy nadele.
- Skaal nie binne 'n datasentrum nie, tensy u 'n besigheidsweergawe het. Dit is slegs skaalbaar deur federasie.
- Baie afhanklik van die kwaliteit van die netwerk en bedienerlading. Consul sal nie behoorlik as 'n bediener op 'n besige bediener werk as daar enige vertragings in die netwerk is nie, byvoorbeeld ongelyke spoed. Dit is as gevolg van P2P-verbindings en opdatering van verspreidingsmodelle.
- Moeilik om beskikbaarheid te monitor. In konsulstatus kan hy sê alles is reg, maar hy is lankal dood.
Ons het die meeste van hierdie probleme opgelos terwyl ons Consul gebruik het, en daarom het ons dit gekies. Die maatskappy het planne vir 'n alternatiewe agterkant, maar ons het geleer om probleme te hanteer en woon tans by Consul.
Hoe konsul werk
Ons sal drie tot vyf bedieners in 'n voorwaardelike datasentrum installeer. Een of twee bedieners sal nie werk nie: hulle sal nie 'n kworum kan organiseer en besluit wie is reg en wie is verkeerd wanneer die data nie ooreenstem nie. Meer as vyf maak geen sin nie, produktiwiteit sal daal.
Kliënte koppel aan die bedieners in enige volgorde: dieselfde agente, net met die vlag server = false.
Hierna ontvang kliënte 'n lys van P2P-verbindings en bou verbindings onder mekaar.
Op wêreldvlak verbind ons verskeie datasentrums. Hulle verbind ook P2P en kommunikeer.
Wanneer ons data van 'n ander datasentrum wil haal, gaan die versoek van bediener na bediener. Hierdie skema word genoem Serf protokol. Die Serf-protokol, soos Consul, word deur HashiCorp ontwikkel.
Enkele belangrike feite oor Konsul
Consul het dokumentasie wat beskryf hoe dit werk. Ek sal slegs uitgesoekte feite gee wat die moeite werd is om te weet.
Konsul-bedieners kies 'n meester uit die kiesers. Consul kies 'n meester uit die lys bedieners vir elke datasentrum, en alle versoeke gaan slegs na dit, ongeag die aantal bedieners. Meesterbevriesing lei nie tot herverkiesing nie. As die meester nie gekies word nie, word versoeke deur niemand gediens nie.
Wou jy horisontale skaal hê? Jammer, nee.
'n Versoek aan 'n ander datasentrum gaan van meester tot meester, ongeag by watter bediener dit gekom het. Die geselekteerde meester ontvang 100% van die vrag, behalwe vir die vrag op voorwaartse versoeke. Alle bedieners in die datasentrum het 'n bygewerkte kopie van die data, maar net een reageer.
Die enigste manier om te skaal is om verouderde modus op die kliënt te aktiveer.
In verouderde modus kan jy reageer sonder 'n kworum. Dit is 'n modus waarin ons datakonsekwentheid prysgee, maar 'n bietjie vinniger lees as gewoonlik, en enige bediener reageer. Natuurlik, opname slegs deur die meester.
Consul kopieer nie data tussen datasentrums nie. Wanneer 'n federasie saamgestel word, sal elke bediener slegs sy eie data hê. Vir ander wend hy hom altyd tot iemand anders.
Atomiteit van bedrywighede word nie buite 'n transaksie gewaarborg nie. Onthou dat jy nie die enigste een is wat dinge kan verander nie. As jy dit anders wil hê, voer 'n transaksie met 'n slot uit.
Blokkeerhandelinge waarborg nie sluiting nie. Die versoek gaan van meester na meester, en nie direk nie, so daar is geen waarborg dat die blokkering sal werk wanneer jy byvoorbeeld in 'n ander datasentrum blokkeer nie.
ACL waarborg ook nie toegang nie (in baie gevalle). Die ACL werk dalk nie omdat dit in een federasie-datasentrum gestoor word – in die ACL-datasentrum (Primêre DC). As die DC jou nie antwoord nie, sal die ACL nie werk nie.
Een bevrore meester sal die hele federasie laat vries. Daar is byvoorbeeld 10 datasentrums in 'n federasie, en een het 'n slegte netwerk, en een meester misluk. Almal wat met hom kommunikeer, sal in 'n sirkel vassit: daar is 'n versoek, daar is geen antwoord daarop nie, die draad vries. Daar is geen manier om te weet wanneer dit sal gebeur nie, net oor 'n uur of twee sal die hele federasie val. Daar is niks wat jy daaraan kan doen nie.
Status, kworum en verkiesings word deur 'n aparte draad hanteer. Herverkiesing sal nie plaasvind nie, die status sal niks wys nie. Jy dink dat jy 'n lewende Konsul het, jy vra, en niks gebeur nie - daar is geen antwoord nie. Terselfdertyd wys die status dat alles reg is.
Ons het hierdie probleem teëgekom en moes spesifieke dele van datasentrums herbou om dit te vermy.
Die besigheidsweergawe van Consul Enterprise het nie sommige van die nadele hierbo nie. Dit het baie nuttige funksies: kiesers kies, verspreiding, skaal. Daar is net een "maar" - die lisensiestelsel vir 'n verspreide stelsel is baie duur.
Lewe hacking: rm -rf /var/lib/consul - 'n kuur vir alle siektes van die middel. As iets nie vir jou werk nie, vee net jou data uit en laai die data van 'n kopie af. Heel waarskynlik sal Consul werk.
BEFW
Kom ons praat nou oor wat ons by Consul gevoeg het.
is 'n akroniem vir BAckEndFireWalmal. Ek moes die produk op een of ander manier noem toe ek die repository geskep het om die eerste toets commits daarin te plaas. Hierdie naam bly.
Reël sjablone
Die reëls is in iptables-sintaksis geskryf.
- -N BEFW
- -P INSET DROP
- -'N INSET -m toestand—toestand VERWANTE,GESTAAN -j AANVAAR
- -A INSET -i lo -j AANVAAR
- -A INSET -j BEFW
Alles gaan in die BEFW-ketting, behalwe ESTABLISHED, RELATED en plaaslike gasheer. Die sjabloon kan enigiets wees, dit is net 'n voorbeeld.
Hoe is BEFW nuttig?
Dienste
Ons het 'n diens, dit het altyd 'n poort, 'n nodus waarop dit loop. Vanaf ons nodus kan ons die agent plaaslik vra en uitvind dat ons 'n soort diens het. Jy kan ook etikette plaas.
Enige diens wat loop en by Consul geregistreer word, verander in 'n iptables-reël. Ons het SSH - oop poort 22. Die Bash-skrif is eenvoudig: krul en iptables, niks anders is nodig nie.
Kliënte
Hoe om toegang nie vir almal oop te maak nie, maar selektief? Voeg IP-lyste by KV-berging volgens diensnaam.
Ons wil byvoorbeeld hê dat almal op die tiende netwerk toegang tot die SSH_TCP_22-diens moet hê. Voeg een klein TTL-veld by? en nou het ons tydelike permitte, byvoorbeeld, vir 'n dag.
Toegange
Ons verbind dienste en kliënte: ons het 'n diens, KV-berging is gereed vir elkeen. Nou gee ons toegang nie aan almal nie, maar selektief.
Groepe
As ons elke keer duisende IP's vir toegang skryf, sal ons moeg word. Kom ons bedink groeperings – ’n aparte subset in KV. Kom ons noem dit Alias (of groepe) en stoor groepe daar volgens dieselfde beginsel.
Kom ons verbind: nou kan ons SSH oopmaak nie spesifiek vir P2P nie, maar vir 'n hele groep of verskeie groepe. Op dieselfde manier is daar TTL - jy kan by 'n groep voeg en tydelik uit die groep verwyder.
integrasie
Ons probleem is die menslike faktor en outomatisering. Tot dusver het ons dit so opgelos.
Ons werk met Puppet, en dra alles wat met die stelsel verband hou (toepassingskode) na hulle oor. Puppetdb (gewone PostgreSQL) stoor 'n lys van dienste wat daar loop, hulle kan volgens hulpbrontipe gevind word. Daar kan jy uitvind wie waar aansoek doen. Ons het ook 'n trekversoek- en saamsmeltversoekstelsel hiervoor.
Ons het befw-sync geskryf, 'n eenvoudige oplossing wat help om data oor te dra. Eerstens word sinchronisasiekoekies verkry deur puppetdb. 'n HTTP API is daar opgestel: ons versoek watter dienste ons het, wat gedoen moet word. Dan rig hulle 'n versoek aan Konsul.
Is daar integrasie? Ja: hulle het die reëls geskryf en toegelaat dat Pull Requests aanvaar word. Het jy 'n sekere poort nodig of voeg 'n gasheer by een of ander groep? Trek Versoek, hersien - nie meer "Soek 200 ander ACL's en probeer iets daaromtrent doen."
Optimization
Ping van localhost met 'n leë reëlketting neem 0,075 ms.
Kom ons voeg 10 000 iptables-adresse by hierdie ketting. As gevolg hiervan sal die ping 5 keer toeneem: iptables is heeltemal lineêr, die verwerking van elke adres neem 'n geruime tyd.
Vir 'n firewall waar ons duisende ACL's migreer, het ons baie reëls, en dit stel latency in. Dit is sleg vir spelprotokolle.
Maar as ons sit 10 000 adresse in ipset Die ping sal selfs afneem.
Die punt is dat "O" (algoritme kompleksiteit) vir ipset altyd gelyk is aan 1, maak nie saak hoeveel reëls daar is nie. Dit is waar, daar is 'n beperking - daar kan nie meer as 65535 reëls wees nie. Vir nou leef ons hiermee: jy kan hulle kombineer, uitbrei, twee ipsets in een maak.
Storage
'n Logiese voortsetting van die iterasieproses is die stoor van inligting oor kliënte vir die diens in ipset.
Nou het ons dieselfde SSH, en ons skryf nie 100 IP's gelyktydig nie, maar stel die naam van die ipset waarmee ons moet kommunikeer, en die volgende reël DROP. Dit kan omgeskakel word in een reël "Wie is nie hier nie, DROP", maar dit is duideliker.
Nou het ons reëls en stelle. Die hooftaak is om 'n stel te maak voordat die reël geskryf word, want anders sal iptables nie die reël skryf nie.
Algemene skema
In die vorm van 'n diagram lyk alles wat ek gesê het so.
Ons verbind ons tot Puppet, alles word na die gasheer gestuur, dienste hier, ipset daar, en enige iemand wat nie daar geregistreer is nie, word nie toegelaat nie.
Toelaat ontken
Om die wêreld vinnig te red of iemand vinnig te deaktiveer, het ons aan die begin van alle kettings twee ipsets gemaak: rules_allow и rules_deny. Hoe dit werk?
Byvoorbeeld, iemand skep 'n las op ons web met bots. Voorheen moes jy sy IP uit die logs vind, dit na netwerkingenieurs neem, sodat hulle die bron van die verkeer kon vind en hom kon verban. Dit lyk nou anders.
Ons stuur dit na Consul, wag 2,5 sekondes, en dit is klaar. Aangesien Consul vinnig deur P2P versprei, werk dit oral, in enige deel van die wêreld.
Eenkeer het ek op een of ander manier heeltemal WOT gestop as gevolg van 'n fout met die firewall. rules_allow - dit is ons versekering teen sulke gevalle. As ons iewers 'n fout gemaak het met die firewall, is iets iewers geblokkeer, ons kan altyd 'n voorwaardelike stuur 0.0/0om alles vinnig op te tel. Later sal ons alles met die hand regmaak.
Ander stelle
Jy kan enige ander stelle in die spasie byvoeg $IPSETS$.
Vir wat? Soms het iemand ipset nodig, byvoorbeeld om die sluiting van 'n deel van die groepering na te boots. Enigeen kan enige stelle bring, noem dit, en dit sal by Konsul afgehaal word. Terselfdertyd kan stelle óf aan die iptables-reëls deelneem óf as 'n span optree NOOP: Konsekwentheid sal deur die daemoon gehandhaaf word.
Lede
Voorheen was dit so: die gebruiker het aan die netwerk gekoppel en parameters deur die domein ontvang. Voor die koms van nuwe generasie firewalls, het Cisco nie geweet hoe om te verstaan waar die gebruiker is en waar die IP is nie. Daarom is toegang slegs deur die gasheernaam van die masjien verleen.
Wat het ons gedoen? Ons het vasgeval toe ons die adres ontvang het. Gewoonlik is dit dot1x, Wi-Fi of VPN – alles gaan deur RADIUS. Vir elke gebruiker skep ons 'n groep volgens gebruikersnaam en plaas 'n IP daarin met 'n TTL wat gelyk is aan sy dhcp.lease - sodra dit verval, sal die reël verdwyn.
Nou kan ons toegang tot dienste oopmaak, soos ander groepe, volgens gebruikersnaam. Ons het die pyn van gasheername verwyder wanneer hulle verander, en ons het die las van netwerkingenieurs afgeneem omdat hulle nie meer Cisco nodig het nie. Nou registreer ingenieurs self toegang op hul bedieners.
Isolasie
Terselfdertyd het ons begin om die isolasie uitmekaar te haal. Diensbestuurders het 'n inventaris geneem, en ons het al ons netwerke ontleed. Kom ons verdeel hulle in dieselfde groepe, en op die nodige bedieners is die groepe bygevoeg, byvoorbeeld om te ontken. Nou beland dieselfde verhoog-isolasie in die reëls_ontkenning van die produksie, maar nie in die produksie self nie.
Die skema werk vinnig en eenvoudig: ons verwyder alle ACL's van die bedieners, laai die hardeware af en verminder die aantal geïsoleerde VLAN's.
Integriteitsbeheer
Voorheen het ons 'n spesiale sneller gehad wat gerapporteer het wanneer iemand 'n firewall-reël handmatig verander het. Ek het 'n groot linter geskryf om firewall-reëls na te gaan, dit was moeilik. Integriteit word nou deur BEFW beheer. Hy sorg ywerig dat die reëls wat hy maak nie verander nie. As iemand die firewall-reëls verander, sal dit alles terug verander. "Ek het vinnig 'n instaanbediener opgestel sodat ek van die huis af kon werk"—daar is nie meer sulke opsies nie.
BEFW beheer die ipset vanaf die dienste en lys in befw.conf, die reëls van dienste in die BEFW-ketting. Maar dit monitor nie ander kettings en reëls en ander ipsets nie.
Botsingsbeskerming
BEFW stoor altyd die laaste bekende goeie toestand direk in die state.bin binêre struktuur. As iets verkeerd loop, rol dit altyd terug na hierdie toestand.bin.
Dit is versekering teen onstabiele Consul-operasie, wanneer dit nie data gestuur het nie of iemand 'n fout gemaak het en reëls gebruik het wat nie toegepas kan word nie. Om te verseker dat ons nie sonder 'n firewall gelaat word nie, sal BEFW terugrol na die nuutste toestand as 'n fout op enige stadium voorkom.
In kritieke situasies is dit 'n waarborg dat ons 'n werkende firewall sal hê. Ons maak alle grys netwerke oop in die hoop dat die admin dit sal kom regmaak. Eendag sal ek dit in die konfigurasies plaas, maar nou het ons net drie grys netwerke: 10/8, 172/12 en 192.168/16. Binne ons Konsul is dit 'n belangrike kenmerk wat ons help om verder te ontwikkel.
Demo: tydens die verslag demonstreer Ivan die demo-modus van BEFW. Dit is makliker om na die demonstrasie te kyk . Demo bronkode beskikbaar .
Slaggate
Ek sal jou vertel van die goggas wat ons teëgekom het.
ipset voeg stel 0.0.0.0/0. Wat gebeur as jy 0.0.0.0/0 by ipset voeg? Sal alle IP's bygevoeg word? Sal internettoegang beskikbaar wees?
Nee, ons sal 'n fout kry wat ons twee uur se stilstand gekos het. Boonop het die fout nie gewerk sedert 2016 nie, dit is in RedHat Bugzilla geleë onder nommer #1297092, en ons het dit per ongeluk gevind - uit 'n ontwikkelaar se verslag.
Dit is nou 'n streng reël by BEFW dat 0.0.0.0/0 verander in twee adresse: 0.0.0.0/1 и 128.0.0.0/1.
ipset herstel stel < lêer. Wat doen ipset as jy dit sê restore? Dink jy dit werk dieselfde as iptables? Sal dit data herstel?
Niks soos dit nie - dit smelt saam, en die ou adresse gaan nêrens heen nie, jy blokkeer nie toegang nie.
Ons het 'n fout gevind toe ons isolasie getoets het. Nou is daar 'n taamlik komplekse stelsel - in plaas van restore gehou word create temp, dan restore flush temp и restore temp. Aan die einde van ruil: vir atomiteit, want as jy dit eers doen flush en op hierdie oomblik kom 'n pakkie, dit sal weggegooi word en iets sal verkeerd loop. So daar is 'n bietjie swart magie daar.
konsul kv kry -datacenter=ander. Soos ek gesê het, ons dink ons vra vir sommige data, maar ons sal óf data of 'n fout kry. Ons kan dit via Consul plaaslik doen, maar in hierdie geval sal albei vries.
Die plaaslike Consul-kliënt is 'n omhulsel oor die HTTP API. Maar dit hang net en reageer nie net op Ctrl+C, of Ctrl+Z, of enigiets nie kill -9 in die volgende konsole. Ons het dit teëgekom toe ons besig was om 'n groot groepie te bou. Maar ons het nog nie 'n oplossing nie; ons berei voor om hierdie fout in Consul reg te stel.
Konsulleier reageer nie. Ons meester in die datasentrum reageer nie, ons dink: "Miskien sal die herseleksie-algoritme nou werk?"
Nee, dit sal nie werk nie, en monitering sal niks wys nie: Konsul sal sê dat daar 'n verbintenis-indeks is, 'n leier is gevind, alles is reg.
Hoe hanteer ons dit? service consul restart in cron elke uur. As u 50 bedieners het, is dit nie 'n groot probleem nie. Wanneer daar 16 000 van hulle is, sal jy verstaan hoe dit werk.
Gevolgtrekking
As gevolg hiervan het ons die volgende voordele ontvang:
- 100% dekking van alle Linux-masjiene.
- Spoed.
- Outomatisering.
- Ons het hardeware en netwerkingenieurs van slawerny bevry.
- Integrasiemoontlikhede het verskyn wat byna onbeperk is: selfs met Kubernetes, selfs met Ansible, selfs met Python.
Nadele: Konsul, waarmee ons nou moet saamleef, en die baie hoë koste van foute. As 'n voorbeeld, een keer om 6:XNUMX (prima tyd in Rusland) was ek besig om iets in die lyste van netwerke te redigeer. Ons het destyds net isolasie by BEFW gebou. Ek het iewers 'n fout gemaak, dit lyk of ek die verkeerde masker aangedui het, maar alles het binne twee sekondes geval. Die monitering brand, die ondersteuningspersoon aan diens kom aangehardloop: "Ons het alles!" Die hoof van die departement het grys geword toe hy aan die onderneming verduidelik hoekom dit gebeur het.
Die koste van foute is so hoog dat ons met ons eie komplekse voorkomingsprosedure vorendag gekom het. As jy dit op 'n groot produksieterrein implementeer, hoef jy nie 'n meesterteken oor Consul aan almal te gee nie. Dit sal sleg eindig.
Koste. Ek het kode vir 400 uur alleen geskryf. My span van 4 mense spandeer 10 uur per maand aan ondersteuning vir almal. In vergelyking met die prys van enige nuwe generasie firewall, is dit gratis.
Planne. Die langtermynplan is om alternatiewe vervoer te vind om Konsul te vervang of aan te vul. Miskien sal dit Kafka of iets soortgelyks wees. Maar in die komende jare sal ons op Konsul leef.
Onmiddellike planne: integrasie met Fail2ban, met monitering, met nftables, moontlik met ander verspreidings, statistieke, gevorderde monitering, optimalisering. Kubernetes ondersteuning is ook iewers in die planne, want nou het ons verskeie clusters en die begeerte.
Meer uit die planne:
- soek na afwykings in die verkeer;
- netwerkkaartbestuur;
- Kubernetes ondersteuning;
- samestelling van pakkette vir alle stelsels;
- Web-UI.
Ons werk voortdurend daaraan om die konfigurasie uit te brei, statistieke te verhoog en te optimaliseer.
Sluit aan by die projek. Die projek was cool, maar dit is ongelukkig steeds 'n eenpersoonprojek. Kom na en probeer om iets te doen: pleeg, toets, stel iets voor, gee jou assessering.
Intussen berei ons voor vir , wat op 6 en 7 April in St. Petersburg plaasvind, en ons nooi ontwikkelaars van hoëladingstelsels uit. . Ervare sprekers weet reeds wat om te doen, maar vir diegene wat nuut praat, beveel ons ten minste aan . Om as spreker aan die konferensie deel te neem het 'n aantal voordele. Jy kan byvoorbeeld lees watter aan die einde .
Bron: will.com