Vuonna 2010 yritys siellä oli 50 palvelinta ja yksinkertainen verkkomalli: backend, frontend ja palomuuri. Palvelimien määrä kasvoi, malli muuttui monimutkaisemmaksi: staging, eristetyt VLAN:t ACL:illä, sitten VPN:t VRF:illä, VLAN ACL:illä L2:lla, VRF ACL:illä L3:lla. Pyöriikö pää? Siitä tulee myöhemmin hauskempaa.
Kun palvelimia oli 16 000, oli mahdotonta työskennellä ilman repeämiä niin monien heterogeenisten segmenttien kanssa. Joten keksimme toisen ratkaisun. Otimme Netfilter-pinon, lisäsimme Consulin siihen tietolähteeksi ja saimme nopeasti hajautetun palomuurin. He korvasivat ACL:t reitittimissä ja käyttivät niitä ulkoisena ja sisäisenä palomuurina. Työkalun dynaamiseen hallintaan kehitimme BEFW-järjestelmän, jota käytettiin kaikkialla: tuoteverkkoon pääsyn hallinnasta verkkosegmenttien eristämiseen toisistaan.
Hän kertoo sinulle, kuinka se kaikki toimii ja miksi sinun pitäisi tarkastella tätä järjestelmää tarkemmin. Ivan Agarkov () on yhtiön Minskin kehityskeskuksen Kunnossapito-divisioonan infrastruktuurin turvallisuusryhmän johtaja. Ivan on SELinux-fani, rakastaa Perlia ja kirjoittaa koodia. Tietoturvaryhmän johtajana hän työskentelee säännöllisesti lokien, varmuuskopioiden ja tuotekehityksen parissa suojatakseen Wargamingia hakkereilta ja varmistaakseen kaikkien yrityksen pelipalvelimien toiminnan.
Historialliset tiedot
Ennen kuin kerron, kuinka teimme sen, kerron sinulle, kuinka päädyimme tähän ja miksi sitä tarvittiin. Tätä varten palataan 9 vuotta taaksepäin: 2010, World of Tanks ilmestyi juuri. Wargamingilla oli noin 50 palvelinta.
Yrityksen palvelimen kasvukaavio.
Meillä oli verkkomalli. Siihen aikaan se oli optimaalinen.
Verkkomalli 2010.
Edessä on pahiksia, jotka haluavat murtaa meidät, mutta sillä on palomuuri. Taustalla ei ole palomuuria, mutta siellä on 50 palvelinta, tunnemme ne kaikki. Kaikki toimii hyvin.
Neljässä vuodessa palvelinkanta kasvoi 4-kertaiseksi, 100:een. Ensimmäiset eristetyt verkot ilmestyivät - lavastus: ne eivät päässeet tuotantoon, ja siellä oli usein käynnissä asioita, jotka saattoivat olla vaarallisia.
Verkkomalli 2014.
Hitaasti käytimme samoja laitteita ja kaikki työ tehtiin eristetyillä VLAN:illa: VLANeihin kirjoitetaan ACL:t, jotka sallivat tai estävät jonkinlaisen yhteyden.
Vuonna 2016 palvelimien määrä saavutti 8000 XNUMX. Wargaming absorboi muita studioita ja uusia tytäryhtiöverkkoja ilmestyi. Ne näyttävät olevan meidän, mutta eivät aivan: VLAN ei usein toimi kumppaneille, sinun on käytettävä VPN: tä VRF: n kanssa, eristämisestä tulee monimutkaisempaa. ACL-eristeseos kasvoi.
Verkkomalli 2016.
Vuoden 2018 alkuun mennessä konekanta oli kasvanut 16 000. Segmenttejä oli 6, emmekä laskeneet muita mukaan lukien suljetut, joihin talousdataa tallennettiin. Konttiverkot (Kubernetes), DevOps, VPN:n kautta esimerkiksi IVS:stä yhdistetyt pilviverkot ovat ilmaantuneet. Sääntöjä oli monia - se oli tuskallista.
Verkkomalli ja eristysmenetelmät vuonna 2018.
Eristykseen käytimme: VLAN ACL:llä L2:lla, VRF ACL:llä L3:ssa, VPN ja paljon muuta. Liian paljon.
Ongelmat
Kaikki asuvat ACL:n ja VLANin kanssa. Mikä hätänä? Harold vastaa tähän kysymykseen kätkeen kivun.
Ongelmia oli monia, mutta suuria oli viisi.
- Geometrinen hinnankorotus uusille säännöille. Jokaisen uuden säännön lisääminen kesti pidempään kuin edellisen, koska oli ensin tarkastettava, oliko tällainen sääntö jo olemassa.
- Ei palomuuria segmenttien sisällä. Segmentit erottuivat jotenkin toisistaan, eikä sisällä ollut jo tarpeeksi resursseja.
- Sääntöjä sovellettiin pitkään. Operaattorit pystyivät kirjoittamaan yhden paikallisen säännön käsin tunnissa. Maailmanlaajuinen kesti useita päiviä.
- Vaikeuksia tilintarkastussääntöjen kanssa. Tarkemmin sanottuna se ei ollut mahdollista. Ensimmäiset säännöt kirjoitettiin jo vuonna 2010, ja suurin osa niiden kirjoittajista ei enää työskennellyt yrityksessä.
- Matala infrastruktuurin hallinta. Tämä on suurin ongelma - emme tienneet kovin hyvin, mitä maassamme tapahtuu.
Tältä verkkoinsinööri näytti vuonna 2018 kuultuaan: "Tarvitsee lisää ACL:ää."
Ratkaisut
Vuoden 2018 alussa asialle päätettiin tehdä jotain.
Integraatioiden hinta nousee jatkuvasti. Lähtökohtana oli, että suuret datakeskukset lakkasivat tukemasta eristettyjä VLAN:eja ja ACL:itä, koska laitteiden muisti loppui.
Ratkaisu: poistimme inhimillisen tekijän ja automatisoimme pääsyn tarjoamisen maksimiin.
Uusien sääntöjen soveltaminen kestää kauan. Ratkaisu: nopeuttaa sääntöjen soveltamista, tee se hajautetuksi ja rinnakkaiseksi. Tämä vaatii hajautetun järjestelmän, jotta säännöt toimitetaan itse, ilman rsyncia tai SFTP:tä tuhannelle järjestelmälle.
Ei palomuuria segmenttien sisällä. Segmenttien sisäinen palomuuri alkoi tulla meille, kun samaan verkkoon ilmestyi erilaisia palveluita. Ratkaisu: käytä isäntätason palomuuria - isäntäpohjaiset palomuurit. Melkein kaikkialla meillä on Linux ja kaikkialla meillä on iptables, tämä ei ole ongelma.
Vaikeuksia tilintarkastussääntöjen kanssa. Ratkaisu: Pidä kaikki säännöt yhdessä paikassa tarkistusta ja hallintaa varten, jotta voimme tarkastaa kaiken.
Alhainen infrastruktuurin hallinta. Ratkaisu: tee luettelo kaikista palveluista ja niiden välisistä yhteyksistä.
Tämä on enemmän hallinnollinen kuin tekninen prosessi. Joskus meillä on 200-300 uutta julkaisua viikossa, varsinkin kampanjoiden ja lomien aikana. Lisäksi tämä on vain yhdelle DevOps-tiimillemme. Kun on niin monia julkaisuja, on mahdotonta nähdä, mitä portteja, IP-osoitteita ja integraatioita tarvitaan. Siksi tarvitsimme erityisesti koulutettuja palvelupäälliköitä, jotka kysyivät tiimeiltä: "Mitä siellä muuten on ja miksi otitte sen esiin?"
Kaiken lanseeraamamme jälkeen verkkoinsinööri vuonna 2019 alkoi näyttää tältä.
Konsuli
Päätimme, että laitamme kaikki palvelupäälliköiden avulla löytämämme Consuliin ja kirjoitamme sieltä iptables-säännöt.
Miten päätimme tehdä tämän?
- Keräämme kaikki palvelut, verkot ja käyttäjät.
- Luodaan niiden perusteella iptables-säännöt.
- Automatisoimme ohjauksen.
- ....
- VOITTO.
Consul ei ole etäsovellusliittymä, se voi toimia jokaisessa solmussa ja kirjoittaa iptablesiin. Jäljelle jää vain automaattiset ohjaimet, jotka puhdistavat tarpeettomat asiat, ja suurin osa ongelmista ratkeaa! Harkitsemme loput matkan varrella.
Miksi konsuli?
On osoittautunut hyvin. Vuosina 2014-15 käytimme sitä Holvin taustaohjelmistona, johon tallennamme salasanoja.
Ei menetä tietoja. Käyttöaikana Consul ei menettänyt tietoja yhdenkään onnettomuuden aikana. Tämä on valtava plussa palomuurin hallintajärjestelmälle.
P2P-yhteydet nopeuttavat muutoksen leviämistä. P2P:llä kaikki muutokset tulevat nopeasti, ei tarvitse odottaa tuntikausia.
Kätevä REST API. Harkitsimme myös Apache ZooKeeperiä, mutta sillä ei ole REST API:ta, joten sinun on asennettava kainalosauvat.
Toimii sekä Key Vaultina (KV) että hakemistona (Service Discovery). Voit tallentaa palveluita, luetteloita ja datakeskuksia kerralla. Tämä on kätevä paitsi meille, myös naapuritiimeille, koska globaalia palvelua rakennettaessa ajattelemme isosti.
Kirjoitettu Gossa, joka on osa Wargaming-pinoa. Rakastamme tätä kieltä, meillä on monia Go-kehittäjiä.
Tehokas ACL-järjestelmä. Consulissa voit käyttää ACL-luetteloita hallitaksesi, kuka kirjoittaa mitä. Takaamme, että palomuurisäännöt eivät mene päällekkäin minkään muun kanssa, eikä meillä ole tämän kanssa ongelmia.
Mutta konsulilla on myös haittapuolensa.
- Ei skaalaudu konesalissa, ellei sinulla ole yritysversiota. Se on skaalattavissa vain liiton toimesta.
- Riippuu hyvin verkon laadusta ja palvelimen kuormituksesta. Consul ei toimi kunnolla palvelimena kiireisellä palvelimella, jos verkossa on viiveitä, esimerkiksi epätasainen nopeus. Tämä johtuu P2P-yhteyksistä ja päivitysten jakelumalleista.
- Vaikeuksia seurata saatavuutta. Konsuliasemassa hän voi sanoa, että kaikki on hyvin, mutta hän kuoli kauan sitten.
Ratkaisimme suurimman osan näistä ongelmista Consulin käytön aikana, minkä vuoksi valitsimme sen. Yrityksellä on suunnitelmia vaihtoehtoisesta taustajärjestelmästä, mutta olemme oppineet käsittelemään ongelmia ja asumme tällä hetkellä Consulin kanssa.
Miten Consul toimii
Asennamme ehdolliseen datakeskukseen kolmesta viiteen palvelinta. Yksi tai kaksi palvelinta ei toimi: ne eivät pysty järjestämään päätösvaltaisuutta ja päättämään, kuka on oikeassa ja kuka väärässä, kun tiedot eivät täsmää. Yli viidellä ei ole mitään järkeä, tuottavuus laskee.
Asiakkaat muodostavat yhteyden palvelimiin missä tahansa järjestyksessä: samat agentit, vain lipulla server = false.
Tämän jälkeen asiakkaat saavat luettelon P2P-yhteyksistä ja muodostavat yhteyksiä keskenään.
Globaalilla tasolla yhdistämme useita datakeskuksia. Ne myös yhdistävät P2P:n ja kommunikoivat.
Kun haluamme hakea tietoja toisesta palvelinkeskuksesta, pyyntö siirtyy palvelimelta palvelimelle. Tätä kaavaa kutsutaan Serf-protokolla. Serf-protokollan, kuten Consul, on kehittänyt HashiCorp.
Tärkeitä faktoja konsulista
Konsulilla on asiakirjat, jotka kuvaavat sen toimintaa. Annan vain valikoituja faktoja, jotka kannattaa tietää.
Konsulipalvelimet valitsevat äänestäjien joukosta mestarin. Konsuli valitsee jokaiselle konesalille isännän palvelinluettelosta, ja kaikki pyynnöt menevät vain sille palvelimien lukumäärästä riippumatta. Mestarien jäätyminen ei johda uudelleenvalintaan. Jos isäntä ei ole valittuna, kukaan ei palvele pyyntöjä.
Halusitko vaakasuuntaisen skaalauksen? Anteeksi, ei.
Pyyntö toiseen palvelinkeskukseen siirtyy isännältä isännälle riippumatta siitä, mille palvelimelle se tuli. Valittu isäntä vastaanottaa 100 % kuormasta, lukuun ottamatta edelleenlähetyspyyntöjen kuormaa. Kaikilla palvelinkeskuksen palvelimilla on ajan tasalla oleva kopio tiedoista, mutta vain yksi vastaa.
Ainoa tapa skaalata on ottaa käyttöön vanhentunut tila asiakkaassa.
Vanhentuneessa tilassa voit vastata ilman päätösvaltaisuutta. Tämä on tila, jossa luovutamme tietojen johdonmukaisuudesta, mutta luemme hieman tavallista nopeammin, ja mikä tahansa palvelin vastaa. Luonnollisesti tallennus vain masterin kautta.
Consul ei kopioi tietoja datakeskusten välillä. Kun liitto on koottu, kullakin palvelimella on vain omat tietonsa. Toisten puolesta hän kääntyy aina jonkun muun puoleen.
Toiminnan ydinvoimakkuutta ei taata kaupan ulkopuolella. Muista, että et ole ainoa, joka voi muuttaa asioita. Jos haluat toisin, tee kauppa lukolla.
Lukitustoiminnot eivät takaa lukitusta. Pyyntö siirtyy isännältä isännälle, ei suoraan, joten ei ole takeita siitä, että esto toimii, kun estät esimerkiksi toisessa datakeskuksessa.
ACL ei myöskään takaa pääsyä (monissa tapauksissa). ACL ei ehkä toimi, koska se on tallennettu yhteen liiton tietokeskukseen - ACL-tietokeskukseen (ensisijainen DC). Jos DC ei vastaa sinulle, ACL ei toimi.
Yksi jäätynyt mestari saa koko liiton jäätymään. Esimerkiksi liitossa on 10 datakeskusta, joista yhdellä on huono verkko ja yksi isäntä epäonnistuu. Jokainen, joka kommunikoi hänen kanssaan, juuttuu ympyrään: on pyyntö, siihen ei vastata, lanka jäätyy. Ei voi tietää milloin tämä tapahtuu, vain tunnin tai kahden kuluttua koko liitto kaatuu. Sille ei voi mitään.
Status, päätösvaltaisuus ja vaalit käsitellään erillisessä säikeessä. Uudelleenvalintaa ei tapahdu, tila ei näytä mitään. Luuletko, että sinulla on elävä konsuli, kysyt, eikä mitään tapahdu - vastausta ei ole. Samalla tila näyttää, että kaikki on hyvin.
Olemme kohdanneet tämän ongelman ja jouduimme rakentamaan uudelleen tiettyjä palvelinkeskusten osia sen välttämiseksi.
Consul Enterprisen yritysversiolla ei ole joitain yllä mainituista haitoista. Siinä on monia hyödyllisiä toimintoja: äänestäjien valinta, jakelu, skaalaus. On vain yksi "mutta" - hajautetun järjestelmän lisenssijärjestelmä on erittäin kallis.
Elämä hakkerointi: rm -rf /var/lib/consul - parannuskeino kaikkiin aiheuttajan sairauksiin. Jos jokin ei toimi sinulle, poista tietosi ja lataa tiedot kopiosta. Todennäköisesti konsuli työskentelee.
BEFW
Puhutaan nyt siitä, mitä olemme lisänneet konsulille.
on lyhenne sanalle BackEndFvihaWkaikki. Minun piti nimetä tuote jotenkin, kun loin arkistoa, jotta ensimmäiset testisitoumukset voisi tehdä siihen. Tämä nimi säilyy.
Sääntömallit
Säännöt on kirjoitettu iptables-syntaksilla.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m tila—tila RELATED, ESTABLISHED -j HYVÄKSY
- -A INPUT -i lo -j HYVÄKSY
- -A INPUT -j BEFW
Kaikki menee BEFW-ketjuun paitsi ESTABLISHED, RELATED ja paikallinen isäntä. Malli voi olla mikä tahansa, tämä on vain esimerkki.
Miten BEFW on hyödyllinen?
Palvelut
Meillä on palvelu, sillä on aina portti, solmu, jossa se toimii. Solmupisteestämme voimme paikallisesti kysyä agentilta ja saada selville, että meillä on jonkinlainen palvelu. Voit myös laittaa tunnisteita.
Mikä tahansa palvelu, joka on käynnissä ja rekisteröity Consulille, muuttuu iptables-säännöksi. Meillä on SSH - avoin portti 22. Bash-skripti on yksinkertainen: curl ja iptables, muuta ei tarvita.
Asiakkaat
Kuinka avata pääsy ei kaikille, mutta valikoivasti? Lisää IP-luetteloita KV-tallennustilaan palvelun nimen mukaan.
Haluamme esimerkiksi, että kaikki kymmenennen verkon käyttäjät voivat käyttää SSH_TCP_22-palvelua. Lisätäänkö yksi pieni TTL-kenttä? ja nyt meillä on väliaikaiset luvat esimerkiksi päiväksi.
Pääset
Yhdistämme palvelut ja asiakkaat: meillä on palvelu, KV-tallennus on valmiina jokaiselle. Nyt emme anna pääsyä kaikille, vaan valikoivasti.
Ryhmä
Jos kirjoitamme joka kerta tuhansia IP-osoitteita pääsyä varten, väsymme. Keksitään ryhmittelyt - erillinen osajoukko KV:ssa. Kutsutaan sitä Aliasiksi (tai ryhmiksi) ja tallennetaan ryhmiä sinne saman periaatteen mukaisesti.
Yhdistetään: nyt voimme avata SSH:n ei erityisesti P2P:lle, vaan koko ryhmälle tai useille ryhmille. Samalla tavalla on olemassa TTL - voit lisätä ryhmään ja poistaa ryhmästä väliaikaisesti.
integraatio
Ongelmamme on inhimillinen tekijä ja automaatio. Toistaiseksi olemme ratkaisseet sen näin.
Työskentelemme Puppetin kanssa ja siirrämme heille kaiken järjestelmään liittyvän (sovelluskoodin). Puppetdb (tavallinen PostgreSQL) tallentaa luettelon siellä käynnissä olevista palveluista, ne löytyvät resurssityypin mukaan. Sieltä saat selville kuka hakee minne. Meillä on myös vetopyyntö- ja yhdistämispyyntöjärjestelmä tätä varten.
Kirjoitimme befw-syncin, yksinkertaisen ratkaisun, joka auttaa siirtämään tietoja. Ensinnäkin puppetdb käyttää synkronointievästeitä. Siellä on määritetty HTTP API: kysymme, mitä palveluita meillä on, mitä pitää tehdä. Sitten he tekevät pyynnön konsulille.
Onko integraatiota? Kyllä: he kirjoittivat säännöt ja sallivat vetopyyntöjen hyväksymisen. Tarvitsetko tietyn portin tai lisäätkö isännän johonkin ryhmään? Vedä pyyntö, tarkista - ei enää "Etsi 200 muuta ACL:tä ja yritä tehdä asialle jotain."
optimointi
Paikallispalvelimen pingaaminen tyhjällä sääntöketjulla kestää 0,075 ms.
Lisätään tähän ketjuun 10 000 iptables-osoitetta. Tämän seurauksena ping kasvaa 5-kertaiseksi: iptables on täysin lineaarinen, jokaisen osoitteen käsittely kestää jonkin aikaa.
Palomuurissa, jossa siirrämme tuhansia ACL-luetteloita, meillä on paljon sääntöjä, ja tämä lisää viivettä. Tämä on huono peliprotokollien kannalta.
Mutta jos laitamme 10 000 osoitetta ipsetissä Ping jopa pienenee.
Asia on, että "O" (algoritmin monimutkaisuus) ipsetille on aina yhtä suuri kuin 1, riippumatta siitä, kuinka monta sääntöä on. Totta, siinä on rajoitus - sääntöjä ei voi olla enempää kuin 65535. Tällä hetkellä elämme tämän kanssa: voit yhdistää niitä, laajentaa niitä, tehdä kaksi ipsetiä yhdeksi.
Varastointi
Iterointiprosessin looginen jatko on palvelun asiakastietojen tallentaminen ipsetissä.
Nyt meillä on sama SSH, emmekä kirjoita 100 IP:tä kerralla, vaan asetamme ipsetin nimen, jonka kanssa meidän on kommunikoitava, ja seuraava sääntö DROP. Se voidaan muuntaa yhdeksi sääntöksi "Kuka ei ole täällä, DROP", mutta se on selkeämpi.
Nyt meillä on säännöt ja sarjat. Päätehtävä on tehdä joukko ennen säännön kirjoittamista, koska muuten iptables ei kirjoita sääntöä.
Yleinen järjestelmä
Kaavion muodossa kaikki sanomani näyttää tältä.
Sitoudumme Puppetiin, kaikki lähetetään isännälle, palvelut tänne, ipset sinne, ja ketään, joka ei ole rekisteröitynyt sinne, ei sallita.
Salli & kiellä
Pelastaaksemme nopeasti maailman tai poistaaksemme jonkun nopeasti käytöstä, teimme kaikkien ketjujen alussa kaksi ipsetiä: rules_allow и rules_deny. Kuinka se toimii?
Esimerkiksi joku luo kuormitusta verkkoomme bottien avulla. Aiemmin sinun piti löytää hänen IP-osoite lokeista, viedä se verkkoinsinööreille, jotta he löytäisivät liikenteen lähteen ja kieltävät hänet. Se näyttää nyt erilaiselta.
Lähetämme sen konsulille, odotamme 2,5 sekuntia ja se on valmis. Koska Consul jakaa nopeasti P2P:n kautta, se toimii kaikkialla, missä tahansa päin maailmaa.
Kerran jotenkin lopetin WOT:n kokonaan palomuurivirheen vuoksi. rules_allow - Tämä on vakuutuksemme tällaisia tapauksia vastaan. Jos teimme virheen jossain palomuurissa, jokin on estetty jossain, voimme aina lähettää ehdollisen 0.0/0poimia kaiken nopeasti. Myöhemmin korjaamme kaiken käsin.
Muut setit
Voit lisätä mitä tahansa muita sarjoja avaruuteen $IPSETS$.
Minkä vuoksi? Joskus joku tarvitsee ipsetin esimerkiksi emuloidakseen klusterin jonkin osan sammuttamista. Kuka tahansa voi tuoda mitkä tahansa setit, nimetä ne ja ne noudetaan konsulilta. Samalla joukot voivat joko osallistua iptablesin sääntöihin tai toimia tiiminä NOOP: Johdonmukaisuutta ylläpitää demoni.
Jäsenet
Aikaisemmin se oli näin: käyttäjä liittyi verkkoon ja sai parametrit verkkotunnuksen kautta. Ennen uuden sukupolven palomuurien syntymistä Cisco ei tiennyt kuinka ymmärtää, missä käyttäjä oli ja missä IP-osoite. Siksi käyttöoikeus myönnettiin vain koneen isäntänimen kautta.
Mitä teimme? Jäimme jumiin sillä hetkellä, kun saimme osoitteen. Yleensä tämä on dot1x, Wi-Fi tai VPN - kaikki menee RADIUS:n kautta. Luomme jokaiselle käyttäjälle ryhmän käyttäjätunnuksen mukaan ja sijoitamme siihen IP-osoitteen, jonka TTL on yhtä suuri kuin sen dhcp.lease - sääntö katoaa heti, kun se vanhenee.
Nyt voimme avata pääsyn palveluihin, kuten muihinkin ryhmiin, käyttäjätunnuksella. Olemme poistaneet isäntänimien vaivan, kun ne muuttuvat, ja olemme ottaneet verkkoinsinöörien taakan, koska he eivät enää tarvitse Ciscoa. Nyt insinöörit itse rekisteröivät pääsyn palvelimilleen.
Eristys
Samaan aikaan aloimme purkaa eristystä. Palvelupäälliköt tekivät inventaarion ja analysoimme kaikki verkostomme. Jaetaan ne samoihin ryhmiin ja tarvittaville palvelimille ryhmät lisättiin esimerkiksi estämään. Nyt sama lavastuseristys päätyy tuotannon sääntöjä_kieltoon, mutta ei itse tuotantoon.
Kaava toimii nopeasti ja yksinkertaisesti: poistamme kaikki ACL:t palvelimilta, puramme laitteiston ja vähennämme eristettyjen VLAN-verkkojen määrää.
Eheyden valvonta
Aiemmin meillä oli erityinen laukaisu, joka raportoi, kun joku muutti palomuurisääntöä manuaalisesti. Kirjoitin valtavaa linteriä palomuurin sääntöjen tarkistamiseksi, se oli vaikeaa. BEFW hallitsee nyt eheyttä. Hän varmistaa innokkaasti, että hänen tekemänsä säännöt eivät muutu. Jos joku muuttaa palomuurisääntöjä, se muuttaa kaiken takaisin. "Asensin nopeasti välityspalvelimen, jotta voisin työskennellä kotoa käsin" – tällaisia vaihtoehtoja ei ole enää.
BEFW hallitsee ipsetiä palveluista ja listaa befw.conf-hakemistossa, BEFW-ketjun palvelusäännöt. Mutta se ei valvo muita ketjuja ja sääntöjä ja muita ipsettejä.
Törmäyssuojaus
BEFW tallentaa aina viimeisen tunnetun hyvän tilan suoraan state.bin-binaarirakenteeseen. Jos jokin menee pieleen, se palaa aina tähän tilaan.bin.
Tämä on vakuutus epävakaata konsulin toimintaa vastaan, kun se ei lähettänyt tietoja tai joku teki virheen ja käytti sääntöjä, joita ei voida soveltaa. Varmistaaksemme, ettemme jää ilman palomuuria, BEFW palaa viimeisimpään tilaan, jos jossain vaiheessa tapahtuu virhe.
Kriittisissä tilanteissa tämä on takuu siitä, että meillä jää toimiva palomuuri. Avaamme kaikki harmaat verkot siinä toivossa, että järjestelmänvalvoja tulee korjaamaan asian. Laitan tämän joskus asetuksiin, mutta nyt meillä on vain kolme harmaata verkkoa: 10/8, 172/12 ja 192.168/16. Konsulissamme tämä on tärkeä ominaisuus, joka auttaa meitä kehittymään edelleen.
Demo: raportin aikana Ivan esittelee BEFW:n demotilaa. Esittelyä on helpompi katsoa . Demon lähdekoodi saatavilla .
Sudenkuopat
Kerron sinulle havaitsemistamme bugeista.
ipset add set 0.0.0.0/0. Mitä tapahtuu, jos lisäät 0.0.0.0/0 ipsetiin? Lisätäänkö kaikki IP:t? Onko Internet-yhteys saatavilla?
Ei, saamme virheen, joka maksoi meille kaksi tuntia seisonta-aikaa. Lisäksi bugi ei ole toiminut vuoden 2016 jälkeen, se sijaitsee RedHat Bugzillassa numerolla #1297092, ja löysimme sen vahingossa - kehittäjän raportista.
Se on nyt BEFW:llä tiukka sääntö 0.0.0.0/0 muuttuu kahdeksi osoitteeksi: 0.0.0.0/1 и 128.0.0.0/1.
ipset-palautusjoukko <tiedosto. Mitä ipset tekee, kun käsket sen restore? Luuletko sen toimivan samalla tavalla kuin iptables? Palauttaako se tiedot?
Ei mitään sellaista - se yhdistää, ja vanhat osoitteet eivät mene minnekään, et estä pääsyä.
Löysimme virheen testattaessa eristystä. Nyt on olemassa melko monimutkainen järjestelmä - sen sijaan restore pidetään create temp, sitten restore flush temp и restore temp. Vaihdon lopussa: atomiteetille, koska jos teet sen ensin flush ja tällä hetkellä jokin paketti saapuu, se hylätään ja jotain menee pieleen. Joten siinä on vähän mustaa magiaa.
konsuli kv get -tietokeskus=muu. Kuten sanoin, luulemme pyytävämme tietoja, mutta saamme joko tietoja tai virheen. Voimme tehdä tämän paikallisesti Consulin kautta, mutta tässä tapauksessa molemmat jäätyvät.
Paikallinen Consul-asiakas on HTTP API:n kääre. Mutta se vain jumittuu eikä vastaa vain Ctrl+C:lle tai Ctrl+Z:lle tai mihinkään kill -9 seuraavassa konsolissa. Tapasimme tämän, kun rakensimme suurta klusteria. Mutta meillä ei ole vielä ratkaisua; valmistaudumme korjaamaan tämän virheen Consulissa.
Konsulijohtaja ei vastaa. Palvelinkeskuksen päällikkömme ei vastaa, ajattelemme: "Ehkä uudelleenvalintaalgoritmi toimii nyt?"
Ei, se ei toimi, eikä seuranta näytä mitään: konsuli sanoo, että on sitoutumisindeksi, johtaja on löydetty, kaikki on hyvin.
Miten suhtaudumme tähän? service consul restart cronissa tunnin välein. Jos sinulla on 50 palvelinta, ei hätää. Kun niitä on 16 000, ymmärrät kuinka se toimii.
Johtopäätös
Tämän seurauksena saimme seuraavat edut:
- 100 %:n kattavuus kaikista Linux-koneista.
- Nopeus.
- Automaatio.
- Vapautimme laitteisto- ja verkkoinsinöörit orjuudesta.
- Integraatiomahdollisuuksia on ilmestynyt, jotka ovat lähes rajattomat: jopa Kubernetesilla, jopa Ansiblella, jopa Pythonilla.
Miinukset: Konsuli, jonka kanssa meidän on nyt elettävä, ja virheiden erittäin korkea hinta. Esimerkiksi kerran kello 6 (Venäjällä parhaaseen katseluaikaan) editoin jotain verkkoluetteloissa. Rakensimme juuri eristystä BEFW:llä tuolloin. Tein virheen jossain, näyttää siltä, että osoitin väärän maskin, mutta kaikki putosi kahdessa sekunnissa. Valvonta syttyy, päivystävä tukihenkilö juoksee: ”Meillä on kaikki!” Osastonjohtaja harmaantui, kun hän selitti yritykselle, miksi näin tapahtui.
Virheiden hinta on niin korkea, että olemme keksineet oman monimutkaisen ehkäisymenetelmämme. Jos toteutat tämän suurella tuotantopaikalla, sinun ei tarvitse antaa kaikille Consulin päätunnusta. Tämä päättyy huonosti.
Kustannuksia. Kirjoitin koodia 400 tuntia yksin. Neljän hengen tiimini käyttää 4 tuntia kuukaudessa kaikkien tukemiseen. Verrattuna minkä tahansa uuden sukupolven palomuurien hintaan, se on ilmainen.
Suunnitelmat. Pitkän aikavälin suunnitelmana on löytää vaihtoehtoisia kulkuvälineitä Consulin tilalle tai täydennykseksi. Ehkä se on Kafka tai jotain vastaavaa. Mutta tulevina vuosina asumme Consulissa.
Välittömät suunnitelmat: integrointi Fail2baniin, valvontaan, nftablesiin, mahdollisesti muihin jakeluihin, metriikka, edistynyt seuranta, optimointi. Kubernetes-tuki on myös jossain suunnitelmissa, koska nyt meillä on useita klustereita ja halu.
Lisää suunnitelmista:
- etsiä poikkeavuuksia liikenteessä;
- verkon kartan hallinta;
- Kubernetes-tuki;
- pakettien kokoaminen kaikille järjestelmille;
- Web-UI.
Pyrimme jatkuvasti laajentamaan kokoonpanoa, lisäämään mittareita ja optimoimaan.
Liity projektiin. Projektista tuli siisti, mutta valitettavasti se on silti yhden hengen projekti. Tule ja yritä tehdä jotain: sitoudu, testaa, ehdota jotain, anna arviosi.
Sillä välin valmistaudumme , joka järjestetään 6. ja 7. huhtikuuta Pietarissa, ja kutsumme suuren kuormituksen järjestelmien kehittäjät . Kokeneet puhujat tietävät jo mitä tehdä, mutta uusille puhujille suosittelemme ainakin . Konferenssiin puhujana osallistumisella on monia etuja. Voit lukea esimerkiksi lopusta mitkä .
Lähde: will.com