Consul + iptables = :3

2010. gadā uzņēmums Wargaming bija 50 serveri un vienkārÅ”s tÄ«kla modelis: backend, frontend un ugunsmÅ«ris. Serveru skaits pieauga, modelis kļuva sarežģītāks: inscenÄ“Å”ana, izolēti VLAN ar ACL, tad VPN ar VRF, VLAN ar ACL uz L2, VRF ar ACL uz L3. Galva griežas? Vēlāk bÅ«s jautrāk.

Kad bija 16 000 serveru, kļuva neiespējami strādāt bez plÄ«sumiem ar tik daudziem neviendabÄ«giem segmentiem. Tāpēc mēs nonācām pie cita risinājuma. Mēs paņēmām Netfilter steku, pievienojām tam Consul kā datu avotu un ieguvām ātri izplatÄ«tu ugunsmÅ«ri. Viņi aizstāja ACL marÅ”rutētājos un izmantoja tos kā ārējo un iekŔējo ugunsmÅ«ri. Lai dinamiski pārvaldÄ«tu rÄ«ku, mēs izstrādājām BEFW sistēmu, kas tika izmantota visur: no lietotāju piekļuves pārvaldÄ«Å”anas produktu tÄ«klam lÄ«dz tÄ«kla segmentu izolÄ“Å”anai viens no otra.

Consul + iptables = :3

ViņŔ jums pastāstÄ«s, kā tas viss darbojas un kāpēc jums vajadzētu Å”o sistēmu aplÅ«kot tuvāk. Ivans Agarkovs (annmuor) - uzņēmuma Minskas attÄ«stÄ«bas centra Tehniskās apkopes daļas infrastruktÅ«ras droŔības grupas vadÄ«tājs. Ivans ir SELinux fans, viņam patÄ«k Perl un viņŔ raksta kodu. BÅ«dams informācijas droŔības grupas vadÄ«tājs, viņŔ regulāri strādā ar žurnāliem, rezerves kopijām un R&D, lai aizsargātu Wargaming no hakeriem un nodroÅ”inātu visu uzņēmuma spēļu serveru darbÄ«bu.

Vēsturiskā informācija

Pirms pastāstÄ«Å”u, kā mēs to izdarÄ«jām, es jums pastāstÄ«Å”u, kā mēs vispār nonācām pie tā un kāpēc tas bija vajadzÄ«gs. Lai to izdarÄ«tu, atgriezÄ«simies 9 gadus atpakaļ: 2010. gads, tikko parādÄ«jās World of Tanks. Wargaming bija aptuveni 50 serveri.

Consul + iptables = :3
Uzņēmuma servera izaugsmes diagramma.

Mums bija tīkla modelis. Uz to laiku tas bija optimāls.

Consul + iptables = :3
Tīkla modelis 2010. gadā.

PriekÅ”galā ir sliktie puiÅ”i, kuri vēlas mÅ«s salauzt, bet tai ir ugunsmÅ«ris. Aizmugursistēmai nav ugunsmÅ«ra, bet tur ir 50 serveri, mēs tos visus zinām. Viss darbojas labi.

4 gadu laikā serveru parks pieauga 100 reižu lÄ«dz 5000. ParādÄ«jās pirmie izolētie tÄ«kli - inscenējums: tie nevarēja nonākt ražoÅ”anā, un tur bieži darbojās lietas, kas varētu bÅ«t bÄ«stamas.

Consul + iptables = :3
Tīkla modelis 2014. gadā.

Pēc inerces mēs izmantojām vienas un tās paÅ”as aparatÅ«ras daļas, un viss darbs tika veikts izolētos VLAN: ACL tiek ierakstÄ«ti VLAN, kas atļauj vai liedz kādu savienojumu.

2016. gadā serveru skaits sasniedza 8000. Wargaming absorbēja citas studijas, un parādījās papildu saistītie tīkli. Šķiet, ka tie ir mūsējie, bet ne gluži: VLAN bieži nedarbojas partneriem, jums ir jāizmanto VPN ar VRF, izolācija kļūst sarežģītāka. ACL izolācijas maisījums pieauga.

Consul + iptables = :3
Tīkla modelis 2016. gadā.

LÄ«dz 2018. gada sākumam maŔīnu parks bija pieaudzis lÄ«dz 16 000. Bija 6 segmenti, pārējos neskaitÄ«jām, ieskaitot slēgtos, kuros glabājās finanÅ”u dati. Ir parādÄ«juÅ”ies konteineru tÄ«kli (Kubernetes), DevOps, mākoņtÄ«kli, kas savienoti, izmantojot VPN, piemēram, no IVS. Noteikumu bija daudz ā€“ tas bija sāpÄ«gi.

Consul + iptables = :3
Tīkla modelis un izolācijas metodes 2018. gadā.

Izolācijai mēs izmantojām: VLAN ar ACL uz L2, VRF ar ACL uz L3, VPN un daudz ko citu. Pārāk daudz.

Problēmas

Ikviens dzÄ«vo ar ACL un VLAN. Kas noticis? Uz Å”o jautājumu atbildēs Harolds, slēpjot sāpes.

Consul + iptables = :3

Bija daudz problēmu, bet bija piecas lielas.

  • Ä¢eometriskais cenu pieaugums jauniem noteikumiem. Katra jauna noteikuma pievienoÅ”ana prasÄ«ja ilgāku laiku nekā iepriekŔējā, jo vispirms bija jāpaskatās, vai Ŕāds noteikums jau pastāv.
  • Segmentos nav ugunsmÅ«ra. Segmenti bija kaut kā atdalÄ«ti viens no otra, un iekŔā jau nebija pietiekami daudz resursu.
  • Noteikumi tika piemēroti ilgu laiku. Operatori stundas laikā ar roku varētu uzrakstÄ«t vienu vietējo noteikumu. Globālais aizņēma vairākas dienas.
  • GrÅ«tÄ«bas ar audita noteikumiem. PrecÄ«zāk, tas nebija iespējams. Pirmie noteikumi tika uzrakstÄ«ti tālajā 2010. gadā, un lielākā daļa to autoru uzņēmumā vairs nestrādāja.
  • Zems infrastruktÅ«ras kontroles lÄ«menis. Tā ir galvenā problēma ā€“ mēs nezinājām ļoti labi, kas notiek mÅ«su valstÄ«.

Šādi izskatÄ«jās tÄ«kla inženieris 2018. gadā, kad viņŔ dzirdēja: ā€œNepiecieÅ”ams vairāk ACLā€.

Consul + iptables = :3

Risinājumi

2018. gada sākumā tika nolemts kaut ko darīt lietas labā.

Integrāciju cena nepārtraukti aug. Sākuma punkts bija tāds, ka lielie datu centri pārtrauca atbalstīt izolētus VLAN un ACL, jo ierīcēm trūka atmiņas.

Risinājums: noņēmām cilvēcisko faktoru un maksimāli automatizējām piekļuves nodroÅ”ināŔanu.

Jauno noteikumu piemēroÅ”ana prasa ilgu laiku. Risinājums: paātrināt noteikumu piemēroÅ”anu, padarÄ«t to izplatÄ«tu un paralēlu. Tam nepiecieÅ”ama izplatÄ«ta sistēma, lai noteikumi tiktu piegādāti paÅ”i bez rsync vai SFTP tÅ«kstoÅ” sistēmām.

Nav ugunsmūra segmentos. Ugunsmūris segmentos sāka parādīties, kad vienā tīklā parādījās dažādi pakalpojumi. Risinājums: izmantojiet ugunsmūri resursdatora līmenī - uz resursdatora balstīti ugunsmūri. Gandrīz visur, kur mums ir Linux, un visur, kur mums ir iptables, tā nav problēma.

GrÅ«tÄ«bas ar audita noteikumiem. Risinājums. Saglabājiet visus noteikumus vienuviet pārskatÄ«Å”anai un pārvaldÄ«bai, lai mēs varētu visu pārbaudÄ«t.

Zems infrastruktūras kontroles līmenis. Risinājums: uzskaitiet visus pakalpojumus un piekļuves starp tiem.

Tas ir vairāk administratÄ«vs, nevis tehnisks process. Dažreiz mums ir 200-300 jaunumi nedēļā, Ä«paÅ”i akciju un svētku laikā. Turklāt tas ir paredzēts tikai vienai mÅ«su DevOps komandai. Ar tik daudziem izlaidumiem nav iespējams redzēt, kādi porti, IP un integrācijas ir nepiecieÅ”amas. Tāpēc mums bija nepiecieÅ”ami Ä«paÅ”i apmācÄ«ti servisa vadÄ«tāji, kuri komandām jautāja: "Kas tur vispār ir un kāpēc jÅ«s to aktualizējāt?"

Pēc visa, ko uzsākām, tÄ«kla inženieris 2019. gadā sāka izskatÄ«ties Ŕādi.

Consul + iptables = :3

Konsuls

Nolēmām, ka visu, ko atradām ar servisa vadītāju palīdzību, ievietosim Consul un no turienes rakstīsim iptables noteikumus.

Kā mēs nolēmām to darīt?

  • Mēs apkoposim visus pakalpojumus, tÄ«klus un lietotājus.
  • Pamatojoties uz tiem, izveidosim iptables noteikumus.
  • Mēs automatizējam kontroli.
  • ....
  • PEĻŅA.

Consul nav attāls API, tas var darboties katrā mezglā un rakstīt uz iptables. Atliek vien izdomāt automātiskās vadības ierīces, kas iztīrīs nevajadzīgās lietas, un lielākā daļa problēmu būs atrisinātas! Pārējo mēs risināsim.

Kāpēc konsuls?

Ir sevi labi pierādÄ«jis. 2014.ā€“15. gadā mēs to izmantojām kā Vault aizmugursistēmu, kurā glabājam paroles.

Nezaudē datus. LietoÅ”anas laikā Consul datus nezaudēja neviena negadÄ«juma laikā. Tas ir milzÄ«gs pluss ugunsmÅ«ra pārvaldÄ«bas sistēmai.

P2P savienojumi paātrina izmaiņu izplatību. Izmantojot P2P, visas izmaiņas notiek ātri, nav jāgaida stundām ilgi.

Ērta REST API. Mēs apsvērām arī Apache ZooKeeper, taču tam nav REST API, tāpēc jums būs jāinstalē kruķi.

Darbojas gan kā Key Vault (KV), gan kā direktorijs (pakalpojumu atklāŔana). Varat vienlaikus uzglabāt pakalpojumus, katalogus un datu centrus. Tas ir ērti ne tikai mums, bet arÄ« kaimiņu komandām, jo, veidojot globālu servisu, mēs domājam plaÅ”i.

Rakstīts Go, kas ir daļa no Wargaming kaudzītes. Mums patīk Ŕī valoda, mums ir daudz Go izstrādātāju.

JaudÄ«ga ACL sistēma. Programmā Consul varat izmantot ACL, lai kontrolētu, kurÅ” ko raksta. Mēs garantējam, ka ugunsmÅ«ra noteikumi nepārklāsies ne ar ko citu, un mums ar to nebÅ«s problēmu.

Bet konsulam ir arī savi trūkumi.

  • Tas netiek mērogots datu centrā, ja vien jums nav biznesa versijas. To var mērogot tikai federācija.
  • Ä»oti atkarÄ«gs no tÄ«kla kvalitātes un servera slodzes. Consul nedarbosies pareizi kā serveris uz aizņemta servera, ja tÄ«klā bÅ«s aizkavÄ“Å”anās, piemēram, nevienmērÄ«gs ātrums. Tas ir saistÄ«ts ar P2P savienojumiem un atjauninājumu izplatÄ«Å”anas modeļiem.
  • GrÅ«tÄ«bas uzraudzÄ«t pieejamÄ«bu. Konsula statusā viņŔ var teikt, ka viss ir kārtÄ«bā, taču viņŔ jau sen nomira.

Lielāko daļu problēmu mēs atrisinājām, izmantojot Consul, tāpēc arÄ« izvēlējāmies to. Uzņēmumam ir plāni par alternatÄ«vu aizmuguri, taču mēs esam iemācÄ«juÅ”ies tikt galā ar problēmām un Å”obrÄ«d dzÄ«vojam kopā ar Consul.

Kā darbojas konsuls

Nosacītā datu centrā uzstādīsim trīs līdz piecus serverus. Viens vai divi serveri nedarbosies: tie nespēs organizēt kvorumu un izlemt, kuram ir taisnība un kuram nav taisnība, ja dati nesakrīt. Vairāk par pieciem nav jēgas, produktivitāte kritīsies.

Consul + iptables = :3

Klienti savienojas ar serveriem jebkurā secībā: tie paŔi aģenti, tikai ar karogu server = false.

Consul + iptables = :3

Pēc tam klienti saņem P2P savienojumu sarakstu un izveido savienojumus savā starpā.

Consul + iptables = :3

Globālā līmenī mēs savienojam vairākus datu centrus. Viņi arī savieno P2P un sazinās.

Consul + iptables = :3

Ja mēs vēlamies izgūt datus no cita datu centra, pieprasījums tiek nosūtīts no servera uz serveri. Šo shēmu sauc Serf protokols. Serf protokolu, tāpat kā Consul, izstrādā HashiCorp.

Daži svarīgi fakti par konsulu

Konsulam ir dokumentācija, kurā aprakstÄ«ts, kā tas darbojas. Es sniegÅ”u tikai atlasÄ«tus faktus, kurus ir vērts zināt.

Konsulu serveri izvēlas meistaru no balsotāju vidus. Katram datu centram konsuls no serveru saraksta izvēlas galveno, un visi pieprasÄ«jumi tiek nosÅ«tÄ«ti tikai uz to neatkarÄ«gi no serveru skaita. Meistara iesaldÄ“Å”ana nenoved pie pārvēlÄ“Å”anas. Ja kapteinis nav izvēlēts, pieprasÄ«jumus neviens neapkalpo.

Vai vēlējāties horizontālu mērogoÅ”anu? Atvainojiet, nē.

PieprasÄ«jums citam datu centram tiek nosÅ«tÄ«ts no galvenā uz galveno neatkarÄ«gi no tā, uz kuru serveri tas tika nosÅ«tÄ«ts. Izvēlētais meistars saņem 100% slodzes, izņemot pārsÅ«tÄ«Å”anas pieprasÄ«jumu slodzi. Visiem datu centra serveriem ir atjaunināta datu kopija, taču atbild tikai viens.

VienÄ«gais mērogoÅ”anas veids ir klientam iespējot novecojuÅ”o režīmu.

NovecojuŔā režīmā varat atbildēt bez kvoruma. Å is ir režīms, kurā mēs atsakāmies no datu konsekvences, bet lasām nedaudz ātrāk nekā parasti, un jebkurÅ” serveris reaģē. Protams, ierakstÄ«Å”ana tikai caur meistaru.

Consul nekopē datus starp datu centriem. Kad federācija ir izveidota, katram serverim bÅ«s tikai savi dati. Citiem viņŔ vienmēr vērÅ”as pie kāda cita.

Operāciju kodolÄ«gums netiek garantēts ārpus darÄ«juma. Atcerieties, ka jÅ«s neesat vienÄ«gais, kurÅ” var mainÄ«t lietas. Ja vēlaties savādāk, veiciet darÄ«jumu ar slēdzeni.

BloÄ·Ä“Å”anas darbÄ«bas negarantē bloÄ·Ä“Å”anu. PieprasÄ«jums pāriet no saimnieka uz galveno, nevis tieÅ”i, tāpēc nav garantijas, ka bloÄ·Ä“Å”ana darbosies, bloķējot, piemēram, citā datu centrā.

ACL arī negarantē piekļuvi (daudzos gadījumos). ACL var nedarboties, jo tas tiek glabāts vienā federācijas datu centrā - ACL datu centrā (primārā DC). Ja DC jums neatbild, ACL nedarbosies.

Viens nosaluÅ”ais meistars liks sasalst visai federācijai. Piemēram, federācijā ir 10 datu centri, un vienam ir slikts tÄ«kls, un vienam galvenajam neizdodas. Visi, kas ar viņu sazināsies, sastings aplÄ«: ir pieprasÄ«jums, uz to nav atbildes, pavediens sastingst. Nevar zināt, kad tas notiks, tikai pēc stundas vai divām visa federācija kritÄ«s. JÅ«s neko nevarat darÄ«t.

Statuss, kvorums un vēlÄ“Å”anas tiek izskatÄ«tas atseviŔķā pavedienā. PārvēlÄ“Å”ana nenotiks, statuss neko nerādÄ«s. JÅ«s domājat, ka jums ir dzÄ«vs konsuls, jÅ«s jautājat, un nekas nenotiek - atbildes nav. Tajā paŔā laikā statuss liecina, ka viss ir kārtÄ«bā.

Mēs esam saskāruÅ”ies ar Å”o problēmu, un, lai no tās izvairÄ«tos, bija jāpārbÅ«vē noteiktas datu centru daļas.

Consul Enterprise biznesa versijai nav daži no iepriekÅ” minētajiem trÅ«kumiem. Tam ir daudzas noderÄ«gas funkcijas: balsotāju atlase, izplatÄ«Å”ana, mērogoÅ”ana. Ir tikai viens ā€œbetā€ - izplatÄ«tās sistēmas licencÄ“Å”anas sistēma ir ļoti dārga.

DatorurÄ·Ä“Å”ana: rm -rf /var/lib/consul - lÄ«dzeklis pret visām aÄ£enta slimÄ«bām. Ja kaut kas jums nedarbojas, vienkārÅ”i izdzēsiet savus datus un lejupielādējiet datus no kopijas. Visticamāk, konsuls strādās.

BEFW

Tagad parunāsim par to, ko esam pievienojuŔi konsulam.

BEFW ir akronīms vārdam BackEndFireWvisi. Veidojot repozitoriju, man bija kaut kā jānosauc produkts, lai tajā veiktu pirmās pārbaudes saistības. Šis nosaukums paliek.

Noteikumu veidnes

Noteikumi ir rakstīti iptables sintaksē.

  • -N BEFW
  • -P IEVADES KRĀJUMS
  • -IEVADE -m stāvoklis ā€” stāvoklis SAISTÄŖTS, IZVEIDOTS -j ACCEPT
  • -A IEVADE -i lo -j ACCEPT
  • -A IEVADE -j BEFW

Viss nonāk BEFW ķēdē, izņemot ESTABLISHED, RELATED un vietējais saimnieks. Veidne var bÅ«t jebkura, Å”is ir tikai piemērs.

Kā BEFW ir noderīgs?

Pakalpojumi

Mums ir pakalpojums, tam vienmēr ir ports, mezgls, uz kura tas darbojas. No mūsu mezgla mēs varam uz vietas pajautāt aģentam un uzzināt, ka mums ir kāds pakalpojums. Var likt arī birkas.

Consul + iptables = :3

JebkurÅ” pakalpojums, kas darbojas un reÄ£istrēts vietnē Consul, pārvērÅ”as par iptables noteikumu. Mums ir SSH - atvērts ports 22. Bash skripts ir vienkārÅ”s: curl un iptables, nekas cits nav vajadzÄ«gs.

Klienti

Kā atvērt pieeju ne visiem, bet selektīvi? Pievienojiet IP sarakstus KV krātuvei pēc pakalpojuma nosaukuma.

Consul + iptables = :3

Piemēram, mēs vēlamies, lai visi desmitā tīkla lietotāji varētu piekļūt pakalpojumam SSH_TCP_22. Vai pievienot vienu mazu TTL lauku? un tagad mums ir pagaidu atļaujas, piemēram, uz dienu.

Pieejas

Mēs savienojam pakalpojumus un klientus: mums ir serviss, KV krātuve ir gatava katram. Tagad mēs dodam piekļuvi ne visiem, bet selektīvi.

Consul + iptables = :3

Grupa

Ja katru reizi rakstÄ«sim tÅ«kstoÅ”iem IP piekļuvei, mēs nogursim. Izdomāsim grupējumus ā€“ atseviŔķu apakÅ”kopu KV. Sauksim to par Alias ā€‹ā€‹(vai grupām) un saglabāsim grupas tur saskaņā ar to paÅ”u principu.

Consul + iptables = :3

Savienojamies: tagad mēs varam atvērt SSH nevis speciāli P2P, bet gan visai grupai vai vairākām grupām. Tādā paŔā veidā ir TTL - jÅ«s varat pievienot grupai un Ä«slaicÄ«gi noņemt no grupas.

Consul + iptables = :3

Integrācija

MÅ«su problēma ir cilvēciskais faktors un automatizācija. LÄ«dz Å”im mēs to esam atrisinājuÅ”i Ŕādā veidā.

Consul + iptables = :3

Mēs strādājam ar Puppet un nododam viņiem visu, kas attiecas uz sistēmu (lietojumprogrammas kodu). Puppetdb (parastais PostgreSQL) saglabā tur strādājoÅ”o pakalpojumu sarakstu, tos var atrast pēc resursa veida. Tur var uzzināt, kurÅ” kur piesakās. Å im nolÅ«kam mums ir arÄ« izvilkÅ”anas pieprasÄ«jumu un sapludināŔanas pieprasÄ«jumu sistēma.

Mēs uzrakstÄ«jām befw-sync ā€” vienkārÅ”u risinājumu, kas palÄ«dz pārsÅ«tÄ«t datus. Pirmkārt, sinhronizācijas sÄ«kfailiem piekļūst puppetdb. Tur ir konfigurēts HTTP API: mēs pieprasām, kādi pakalpojumi mums ir, kas jādara. Tad viņi iesniedz pieprasÄ«jumu konsulam.

Vai ir integrācija? Jā: viņi uzrakstÄ«ja noteikumus un ļāva pieņemt Pull Requests. Vai jums ir nepiecieÅ”ams noteikts ports vai jāpievieno resursdators kādai grupai? Izvelciet pieprasÄ«jumu, pārskatiet ā€” vairs nav nepiecieÅ”ams ā€œAtrodiet 200 citus ACL un mēģiniet kaut ko darÄ«t lietas labā.ā€

Optimizācija

Pinging localhost ar tukÅ”u noteikumu ķēdi aizņem 0,075 ms.

Consul + iptables = :3

Pievienosim Å”ai ķēdei 10 000 iptables adreses. Rezultātā ping palielināsies 5 reizes: iptables ir pilnÄ«gi lineārs, katras adreses apstrāde aizņem kādu laiku.

Consul + iptables = :3

UgunsmÅ«rim, kurā mēs migrējam tÅ«kstoÅ”iem ACL, mums ir daudz noteikumu, un tas ievieÅ” latentumu. Tas ir slikti spēļu protokoliem.

Bet ja liekam 10 000 adreŔu ipset Ping pat samazināsies.

Consul + iptables = :3

Lieta ir tāda, ka ipset ā€œOā€ (algoritma sarežģītÄ«ba) vienmēr ir vienāds ar 1, neatkarÄ«gi no tā, cik noteikumu ir. Tiesa, ir ierobežojums ā€“ kārtulu nevar bÅ«t vairāk par 65535. Pagaidām dzÄ«vojam ar to: vari tos apvienot, paplaÅ”ināt, izveidot divus ipsetus vienā.

GlabāŔana

Loģisks iterācijas procesa turpinājums ir pakalpojuma ipset informācijas glabāŔana par klientiem.

Consul + iptables = :3

Tagad mums ir tas pats SSH, un mēs nerakstām 100 IP vienlaikus, bet iestatām ipset nosaukumu, ar kuru mums jāsazinās, un Ŕādu noteikumu DROP. To var pārvērst vienā noteikumā ā€œKas Å”eit nav, DROPā€, bet tas ir skaidrāks.

Tagad mums ir noteikumi un kopas. Galvenais uzdevums ir izveidot kopu pirms likuma rakstÄ«Å”anas, jo pretējā gadÄ«jumā iptables kārtulu nerakstÄ«s.

Vispārējā shēma

Diagrammas veidā viss, ko es teicu, izskatās Ŕādi.

Consul + iptables = :3

Mēs apņemamies Puppet, viss tiek nosÅ«tÄ«ts saimniekam, pakalpojumi Å”eit, ipset tur, un neviens, kas tur nav reÄ£istrēts, nav atļauts.

Ļauj noliegt

Lai ātri glābtu pasauli vai ātri kādu atspējotu, visu ķēžu sākumā mēs izveidojām divus ipsets: rules_allow Šø rules_deny. Kā tas strādā?

Piemēram, kāds izveido slodzi mÅ«su tÄ«meklÄ«, izmantojot robotprogrammatÅ«ras. IepriekÅ” jums bija jāatrod viņa IP no žurnāliem, jānogādā tÄ«kla inženieriem, lai viņi varētu atrast trafika avotu un viņu aizliegt. Tagad izskatās savādāk.

Consul + iptables = :3

Mēs to nosūtām konsulam, pagaidiet 2,5 sekundes, un tas ir darīts. Tā kā Consul ātri izplata, izmantojot P2P, tas darbojas visur, jebkurā pasaules daļā.

Reiz es kaut kā pilnÄ«bā pārtraucu WOT ugunsmÅ«ra kļūdas dēļ. rules_allow - Ŕī ir mÅ«su apdroÅ”ināŔana pret Ŕādiem gadÄ«jumiem. Ja kaut kur esam kļūdÄ«juÅ”ies ar ugunsmÅ«ri, kaut kur kaut kas ir bloķēts, mēs vienmēr varam nosÅ«tÄ«t nosacÄ«jumu 0.0/0lai ātri visu savāktu. Vēlāk visu salabosim ar rokām.

Citi komplekti

Kosmosā varat pievienot jebkuru citu komplektu $IPSETS$.

Consul + iptables = :3

Par ko? Dažreiz kādam ir nepiecieÅ”ams ipset, piemēram, lai atdarinātu kādas klastera daļas izslēgÅ”anu. Ikviens var atnest jebkurus komplektus, nosaukt tos, un tie tiks izņemti no konsula. Tajā paŔā laikā komplekti var piedalÄ«ties iptables noteikumos vai darboties kā komanda NOOP: konsekvenci uzturēs dēmons.

Biedri

IepriekÅ” tas bija Ŕādi: lietotājs izveidoja savienojumu ar tÄ«klu un saņēma parametrus caur domēnu. Pirms jaunās paaudzes ugunsmÅ«ru parādÄ«Å”anās Cisco nezināja, kā saprast, kur atrodas lietotājs un kur atrodas IP. Tāpēc piekļuve tika pieŔķirta tikai, izmantojot maŔīnas saimniekdatora nosaukumu.

Ko mēs darÄ«jām? Mēs iestrēgām brÄ«dÄ«, kad saņēmām adresi. Parasti tas ir dot1x, Wi-Fi vai VPN ā€” viss notiek caur RADIUS. Katram lietotājam mēs izveidojam grupu pēc lietotājvārda un ievietojam tajā IP ar TTL, kas ir vienāds ar tā dhcp.lease - tiklÄ«dz beidzas termiņŔ, noteikums pazudÄ«s.

Consul + iptables = :3

Tagad mēs varam atvērt piekļuvi pakalpojumiem, tāpat kā citām grupām, pēc lietotājvārda. Mēs esam atbrÄ«vojuÅ”ies no resursdatora nosaukumiem, kad tie mainās, un esam noņēmuÅ”i slogu no tÄ«kla inženieriem, jo ā€‹ā€‹viņiem vairs nav nepiecieÅ”ams Cisco. Tagad paÅ”i inženieri reÄ£istrē piekļuvi savos serveros.

Izolācija

Tajā paŔā laikā mēs sākām demontēt izolāciju. Pakalpojumu vadÄ«tāji veica inventarizāciju, un mēs analizējām visus mÅ«su tÄ«klus. SadalÄ«sim tās vienās un tajās paŔās grupās, un nepiecieÅ”amajos serveros grupas tika pievienotas, piemēram, lai noliegtu. Tagad tā pati inscenÄ“Å”anas izolācija nonāk iestudējuma noteikumos_noliegumā, bet ne paŔā iestudējumā.

Consul + iptables = :3

Shēma darbojas ātri un vienkārÅ”i: mēs noņemam visus ACL no serveriem, izkraujam aparatÅ«ru un samazinām izolēto VLAN skaitu.

Integritātes kontrole

IepriekÅ” mums bija Ä«paÅ”s aktivizētājs, kas ziņoja, kad kāds manuāli mainÄ«ja ugunsmÅ«ra noteikumu. Es rakstÄ«ju milzÄ«gu lÄ«niju ugunsmÅ«ra noteikumu pārbaudei, tas bija grÅ«ti. Integritāti tagad kontrolē BEFW. ViņŔ dedzÄ«gi rÅ«pējas, lai viņa pieņemtie noteikumi nemainÄ«tos. Ja kāds mainÄ«s ugunsmÅ«ra noteikumus, tas viss mainÄ«s atpakaļ. ā€œEs ātri iestatÄ«ju starpniekserveri, lai varētu strādāt no mājāmā€ ā€” Ŕādu iespēju vairs nav.

BEFW kontrolē ipset no pakalpojumiem un sarakstu befw.conf, pakalpojumu noteikumus BEFW ķēdē. Bet tas neuzrauga citas ķēdes un noteikumus un citus ipsets.

Avārijas aizsardzība

BEFW vienmēr saglabā pēdējo zināmo labo stāvokli tieÅ”i state.bin binārajā struktÅ«rā. Ja kaut kas noiet greizi, tas vienmēr atgriežas Å”ajā stāvoklÄ«.bin.

Consul + iptables = :3

Å Ä« ir apdroÅ”ināŔana pret nestabilu konsula darbÄ«bu, kad tas nenosÅ«tÄ«ja datus vai kāds kļūdÄ«jās un izmantoja noteikumus, kurus nevar piemērot. Lai mēs nepaliktu bez ugunsmÅ«ra, BEFW atgriezÄ«sies jaunākajā stāvoklÄ«, ja kādā posmā radÄ«sies kļūda.

Kritiskās situācijās tā ir garantija, ka mums paliks strādājoÅ”s ugunsmÅ«ris. Atveram visus pelēkos tÄ«klus, cerot, ka atnāks admins un salabos. Kādreiz es to ievietoÅ”u konfigurācijās, bet tagad mums ir tikai trÄ«s pelēki tÄ«kli: 10/8, 172/12 un 192.168/16. MÅ«su konsulā Ŕī ir svarÄ«ga iezÄ«me, kas palÄ«dz mums attÄ«stÄ«ties tālāk.

Demonstrācija: ziņojuma laikā Ivans demonstrē BEFW demonstrācijas režīmu. Demonstrāciju ir vieglāk skatīties Video. Pieejams demonstrācijas pirmkods vietnē GitHub.

Slazdiem

Es jums pastāstÄ«Å”u par kļūdām, ar kurām mēs sastapāmies.

ipset add set 0.0.0.0/0. Kas notiek, ja ipset pievienojat 0.0.0.0/0? Vai tiks pievienoti visi IP? Vai būs pieejams internets?

Nē, mēs iegÅ«sim kļūdu, kas mums izmaksās divas stundas dÄ«kstāves. Turklāt kļūda nedarbojas kopÅ” 2016. gada, tā atrodas RedHat Bugzilla ar numuru #1297092, un mēs to atradām nejauÅ”i - no izstrādātāja ziņojuma.

Tagad tas ir stingri noteikts BEFW 0.0.0.0/0 pārvērÅ”as divās adresēs: 0.0.0.0/1 Šø 128.0.0.0/1.

ipset atjaunoŔanas kopa < fails. Ko ipset dara, kad tu to pasaki restore? Vai jūs domājat, ka tas darbojas tāpat kā iptables? Vai tas atgūs datus?

Nekas tamlÄ«dzÄ«gs ā€” tas tiek sapludināts, un vecās adreses nekur nepazÅ«d, jÅ«s nebloķējat piekļuvi.

Pārbaudot izolāciju, mēs atradām kļūdu. Tagad ir diezgan sarežģīta sistēma - tā vietā restore held create temptad restore flush temp Šø restore temp. Mijmaiņas beigās: par atomitāti, jo, ja jÅ«s to darāt vispirms flush un Å”ajā brÄ«dÄ« pienāk kāda paciņa, tā tiks izmesta un kaut kas noies greizi. Tātad tur ir mazliet melnās maÄ£ijas.

konsuls kv get -datacenter=other. Kā jau teicu, mēs domājam, ka mēs pieprasām dažus datus, bet mēs vai nu saņemsim datus, vai arÄ« saņemsim kļūdu. Mēs to varam izdarÄ«t ar konsula starpniecÄ«bu lokāli, taču Å”ajā gadÄ«jumā abi sastings.

Vietējais Consul klients ir HTTP API iesaiņotājs. Bet tas vienkārÅ”i uzkaras un nereaģē tikai uz Ctrl+C, Ctrl+Z vai jebko citu kill -9 nākamajā konsolē. Mēs ar to saskārāmies, veidojot lielu kopu. Taču mums vēl nav risinājuma; mēs gatavojamies Ŕīs kļūdas laboÅ”anai konsulā.

Konsula vadītājs nereaģē. Mūsu meistars datu centrā nereaģē, mēs domājam: "Varbūt atkārtotas atlases algoritms tagad darbosies?"

Nē, tas nedarbosies, un uzraudzība neko nerādīs: konsuls teiks, ka ir saistību indekss, ir atrasts vadītājs, viss ir kārtībā.

Kā mēs ar to tiekam galā? service consul restart kronā katru stundu. Ja jums ir 50 serveri, tas nav nekas liels. Kad to būs 16 000, jūs sapratīsit, kā tas darbojas.

Secinājums

Tā rezultātā mēs saņēmām Ŕādas priekÅ”rocÄ«bas:

  • 100% pārklājums visām Linux maŔīnām.
  • Ātrums
  • Automatizācija.
  • Mēs atbrÄ«vojām aparatÅ«ras un tÄ«kla inženierus no verdzÄ«bas.
  • Ir parādÄ«juŔās gandrÄ«z neierobežotas integrācijas iespējas: pat ar Kubernetes, pat ar Ansible, pat ar Python.

MÄ«nusi: Konsuls, ar kuru mums tagad ir jāsadzÄ«vo, un ļoti augstās kļūdas izmaksas. Piemēram, reiz pulksten 6 (Krievijas galvenais laiks) es kaut ko rediģēju tÄ«klu sarakstos. Mēs tajā laikā tikai bÅ«vējām siltināŔanu uzņēmumā BEFW. Kaut kur kļūdÄ«jos, Ŕķiet norādÄ«ju nepareizo masku, bet viss nokrita divās sekundēs. Iedegas monitorings, atskrien dežurējoŔā atbalsta persona: "Mums viss ir!" Nodaļas vadÄ«tājs kļuva pelēks, kad biznesam paskaidroja, kāpēc tas noticis.

Kļūdu izmaksas ir tik augstas, ka esam izstrādājuŔi paŔi savu sarežģīto profilakses procedūru. Ja to ievieŔat lielā ražoŔanas vietā, jums nav visiem jāpieŔķir galvenā pilnvara pār konsulu. Tas beigsies slikti.

Izmaksas Es rakstīju kodu 400 stundas vienatnē. Mana 4 cilvēku komanda katru mēnesi pavada 10 stundas, lai atbalstītu visus. Salīdzinot ar jebkura jaunās paaudzes ugunsmūra cenu, tas ir bez maksas.

Plāni. Ilgtermiņa plāns ir atrast alternatīvu transportu, lai aizstātu vai papildinātu konsulu. Varbūt tā būs Kafka vai kas līdzīgs. Bet nākamajos gados dzīvosim uz Consul.

Tūlītējie plāni: integrācija ar Fail2ban, ar uzraudzību, ar nftables, iespējams, ar citiem izplatījumiem, metrika, uzlabota uzraudzība, optimizācija. Arī Kubernetes atbalsts ir kaut kur plānos, jo tagad mums ir vairāki klasteri un vēlme.

Vairāk no plāniem:

  • meklēt anomālijas satiksmē;
  • tÄ«kla karÅ”u vadÄ«ba;
  • Kubernetes atbalsts;
  • PakeÅ”u komplektÄ“Å”ana visām sistēmām;
  • Web-UI.

Mēs pastāvÄ«gi strādājam pie konfigurācijas paplaÅ”ināŔanas, metrikas palielināŔanas un optimizācijas.

Pievienojies projektam. Projekts izrādÄ«jās forÅ”s, bet diemžēl tas joprojām ir vienas personas projekts. Nāc uz GitHub un mēģināt kaut ko darÄ«t: apņemties, pārbaudÄ«t, kaut ko ieteikt, sniegt savu vērtējumu.

Tikmēr mēs gatavojamies Saint HighLoad++, kas notiks 6. un 7. aprÄ«lÄ« Sanktpēterburgā, un aicinām uz lielas slodzes sistēmu izstrādātājus pieteikties uz atskaiti. PieredzējuÅ”i runātāji jau zina, kā rÄ«koties, bet tiem, kas sāk runāt, mēs iesakām vismaz izmēģināt. DalÄ«bai konferencē kā runātājam ir vairākas priekÅ”rocÄ«bas. Kurus var izlasÄ«t, piemēram, beigās no Ŕī raksta.

Avots: www.habr.com

Pievieno komentāru