Consul + iptables = :3

2010. gadā uzņēmumam Wargaming bija 50 serveru un vienkārša tīkla struktūra: backend, frontend un ugunsmūris. Serveru skaits pieauga, modelis kļuva sarežģītāks: stēgēšana, izolēti VLAN ar ACL, pēc tam VPN ar VRF, VLAN ar ACL L2 līmenī, VRF ar ACL L3 līmenī. Galva grozījās? Tālāk būs interesantāk.

Kad serveru skaits sasniedza 16 000, strādāt bez asarām ar tādu daudzumu dažādu segmentu kļuva neiespējami. Tāpēc tika izdomāts cits risinājums. Tika ņemts Netfilter steks, tam pievienots Consul kā datu avots, rezultātā radās ātrs sadalīts ugunsmūris. Tika aizstāti ACL maršrutētājos un izmantots kā ārējais un iekšējais ugunsmūris. Dinamiskai rīka pārvaldībai tika izstrādāta BEFW sistēma, ko pielietoja visur: no piekļuves pārvaldības lietotājiem produkta tīklā līdz tīkla segmentu izolācijai cits no cita.

Kā tas viss darbojas un kāpēc jums vajadzētu pievērst uzmanību šai sistēmai, pastāstīs Ivans Agarovs (annmuor) — infrastruktūras drošības grupas vadītājs Maintenance nodaļā Minskā uzņēmumā. Ivans ir SELinux fans, mīl Perl un raksta kodu. Kā drošības grupas vadītājs, regulāri strādā ar žurnāliem, rezerves kopijām un R&D, lai aizsargātu Wargaming no hakeriem un nodrošinātu visu spēļu serveru darbību uzņēmumā.

Vēsturiskā informācija

Pirms stāstīt, kā mēs to darījām, pastāstīšu, kā mēs vispār nonācām līdz tam un kāpēc tas bija nepieciešams. Tam mēs pārcelsimies 9 gadus atpakaļ: 2010. gads, tieši iznāca World of Tanks. Wargaming uzņēmumam bija apmēram 50 serveru.

Uzņēmuma serveru pieauguma grafiks.

Mums bija tīkla struktūra. To laikam tā bija optimāla.

Tīkla struktūra 2010. gadā.

Frontendā dzīvo slikti puiši, kas vēlas mūs saīsināt, bet tajā ir ugunsmūris. Backendā nav ugunsmūra, bet ir 50 serveru, kurus mēs visus pazīstam. Viss darbojas labi.

Pāris gadu laikā serveru parks pieauga 100 reizes, līdz 5000. Parādījās pirmie izolētie tīkli — stēgēšana: tie nevar iekļūt ražošanā, bet tur bieži bija iespējamā bīstamā satura.

Tīkla struktūra 2014. gadā.

Pēc inerces tika izmantotas tās pašas iekārtas, un viss darbs notika izolētajās VLAN: uz VLAN tiek rakstīti ACL, kas atļauj vai aizliedz kādu savienojumu.

2016. gadā serveru skaits sasniedza 8000. Wargaming iegādājās citas studijas, radās papildu partneru tīkli. Tie it kā ir mūsu, bet ne gluži: partneriem VLAN bieži nedarbojas, ir jāpārslēdzas uz VPN ar VRF, izolācijas kļūst sarežģītas. Izolāciju ACL maisījums pieauga.

Tīkla modelis 2016. gadā.

Līdz 2018. gada sākumam mašīnu parka skaits pieauga līdz 16 000. Sadalījumi bija 6, bet mēs neuzskaitījām pārējos, tostarp slēgtos, kuros tika glabāti finanšu dati. Radās konteineru tīkli (Kubernetes), DevOps, mākoņu tīkli, kas tika pieslēgti caur VPN, piemēram, no I.V.S. Noteikumu bija pārāk daudz — tas sāpēja.

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 vēl daudz ko citu. Pārāk daudz.

Problēmas

Visi dzīvo ar ACL un VLAN. Kas vispār nav kārtībā? Uz šo jautājumu atbildēs Gerolds, slēpjot sāpes.

Problēmas bija daudz, bet masveida — piecas.

• Ģeometriska cena jauniem noteikumiem.. Katrs jauns noteikums tika pievienots ilgāk nekā iepriekšējais, jo vispirms bija jāpārbauda, vai jau nav tāda paša noteikuma.
• Nav ugunsmūra iekšējos segmentus.. Segmenti viens no otra ir kādā veidā atdalīti, iekšā jau resursu nepietiek.
• Noteikumi tika piemēroti ilgi. Ar rokām vienu vietēju noteikumu operators varēja uzrakstīt stundas laikā. Globālais prasīja vairākas dienas.
• Grūtības ar noteikumu auditu.. Precīzāk, tas nebija iespējams. Pirmie noteikumi tika uzrakstīti vēl 2010. gadā, un lielākā daļa to autoru jau vairs nestrādāja uzņēmumā.
• Zems infrastruktūras kontroles līmenis.. Tā ir galvenā problēma — mēs slikti zinājām, kas tieši notiek.

Šādi izskatījās tīkla inženieris 2018. gadā, kad dzirdēja: „Nepieciešams vēl nedaudz ACL”.

Risinājumi

2018. gada sākumā tika nolemts ko darīt ar šo.

Integrāciju cena nepārtraukti pieaug. Izšķirošais punkts bija tas, ka lielie datu centri pārtrauca atbalstīt izolētus VLAN un ACL, jo ierīcēs beidzās atmiņa.

Risinājums: izslēdzām cilvēka faktoru un pēc iespējas automatizējām piekļuves nodrošināšanu.

Jauni noteikumi tiek piemēroti ilgi. Risinājums: paātrināt noteikumu piemērošanu, padarīt to sadalītu un paralēlu. Tam nepieciešama sadalīta sistēma, lai noteikumi tiktu piegādāti paši, bez rsync vai SFTP uz tūkstoš sistēmām.

Ugunsmūra trūkums iekšējos segmentos. Ugunsmūris segmentu iekšienē sāka mūsu virzienā nākt, kad vienā tīklā parādījās dažādi pakalpojumi. Risinājums: izmantot ugunsmūri hosta līmenī — host-based firewalls. Praktiski visur mums ir Linux, un visur ir iptables, tas nav problēma.

Grūtības ar noteikumu auditu. Risinājums: uzglabāt visus noteikumus vienotā vietā pārskatīšanai un vadībai, tādējādi mēs varēsim veikt visu auditu.

Zems infrastruktūras kontroles līmenis. Risinājums: veikt visu pakalpojumu un piekļuves inventarizāciju starp tiem.

Tas vairāk ir administratīvs process nekā tehnisks. Dažkārt mums ir 200-300 jauni laidumi nedēļā, īpaši akciju un svētku laikā. Šis ir tikai mūsu DevOps komandas skaitam. Ar tik daudz jauniem laidumiem ir neiespējami redzēt, kuri porti, IP, integrācijas ir nepieciešami. Tāpēc mums vajadzēja specializētus pakalpojumu vadītājus, kuri uzdeva komandām jautājumus: „Kas vispār pastāv un kāpēc jūs to uzsākāt?”

Pēc visiem uzsāktajiem projektiem tīkla inženieris 2019. gadā izskatījās jau tā.

Consul

Mēs nolēmām, ka visu, ko atradām, izmantojot pakalpojumu vadītājus, ievietosim Consul un no turienes rakstīsim iptables noteikumus.

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

• Savāksim visus pakalpojumus, tīklus un lietotājus.
• Balstoties uz tiem, izveidosim iptables noteikumus.
• Automatizēsim kontroli.
• ….
• PELNĪT.

Consul nav attālināta API, tas var darboties katrā mezglā un rakstīt iptables. Paliek tikai izdomāt automātiskos kontrolrīkus, kas attīrīs lieko, un lielākā daļa problēmu tiks atrisinātas! Pārējo uzlabosim procesa laikā.

Kāpēc Consul?

Labi parādījis sevi. 2014.-2015. gados mēs to izmantojām kā backend Vault, kurā glabājam paroles.

Nepazaudē datus.. Consul lietošanas laikā nav zaudējis datus ne vienā avārijā. Tas ir milzīgs plus ugunsmūra vadības sistēmā.

P2P savienojumi paātrina izmaiņu izplatīšanu.. P2P visas izmaiņas nāk ātri, nav jāgaida stundām.

Ērta REST API. Mēs apsvērām arī Apache ZooKeeper, bet tam nav REST API, būs jāuzstāda „problēmu risinājumi”.

Darbojas gan kā atslēgu krātuve (KV), gan kā katalogs (Service Discovery).. Var uzglabāt vienlaikus pakalpojumus, katalogus un datu centrus. Tas ir ērti ne tikai mums, bet arī blakus komandām, jo veidojot globālu pakalpojumu, mēs domājam plaši.

Uzrakstīts Go, kas ir daļa no Wargaming tehnoloģiju steka. Mums patīk šī valoda, mums ir daudz Go izstrādātāju.

Jaudīga ACL sistēma. Consul ļauj ar ACL pārvaldīt, kam un ko rakstīt. Mēs garantējam, ka ugunsmūra noteikumi vairs nesakrīt ar neko citu un mums nebūs ar to problēmu.

Taču Consul ir arī trūkumi.

• Tas nesniedzas datu centrā, ja jums nav biznesa versijas. Tas mērogojas tikai ar federāciju.
• Ļoti atkarīgs no tīkla kvalitātes un serveru slodzes. Consul nevarēs normāli darboties kā serveris noslogotā serverī, ja tīklā ir kādi aizkavējumi, piemēram, nevienmērīga ātruma dēļ. Tas ir saistīts ar P2P savienojumiem un atjauninājumu izplatīšanas modeļiem.
• Grūtības ar pieejamības uzraudzību. Consul statusā var teikt, ka viss ir kārtībā, bet tas jau sen ir miris.

Lielāko daļu šo problēmu mēs atrisinājām Consul lietošanas laikā, tieši tāpēc to izvēlējāmies. Uzņēmumā ir plāni par alternatīvo backend, bet mēs esam iemācījušies risināt problēmas un pagaidām dzīvojam ar Consul.

Kā darbojas Consul

Nosacītajā datu centrā uzstādīsim serverus — no trim līdz pieciem. Viens vai divi serveri nebūs piemēroti: tie nespēs izveidot kvorumu un noteikt, kas ir pareizi, kad dati nesakrīt. Vairāk nekā pieci nav jēgas, veiktspēja samazināsies.

Klienti, tāpat kā aģenti, pievienojas serveriem jebkurā secībā, tikai ar karogu server = false.

Pēc tam klienti saņem P2P savienojumu sarakstu un veido starp tiem saiknes.

Globālā līmenī mēs savienojam vairākus datu centrus kopā. Tie arī savienojas P2P un sazinās.

Kad mēs vēlamies saņemt datus no cita datu centra, pieprasījums notiek no servera uz serveri. Šo sistēmu sauc par Serf protokolu. Serf protokols, tāpat kā Consul, ir HashiCorp izstrāde.

Daži svarīgi fakti par Consul

Consul ir dokumentācija, kas apraksta tā darbību. Es sniegšu tikai izvēlētus faktus, kas jāzina.

Consul serveri izvēlas meistaru no balsojošajiem. Consul izvēlas meistaru no serveru saraksta katram datu centram, un visi pieprasījumi tiek nosūtīti tikai tam, neatkarīgi no serveru skaita. Meistara iestrēgšana nenoved pie atkārtotām vēlēšanām. Ja meistars nav izvēlēts — pieprasījumus neviens neapkalpo.

Vai jūs vēlējāties horizontālu mērogošanu? Atvainojiet, nav.

Pieprasījums uz citu datu centru notiek no meistara uz meistaru, neatkarīgi no tā, uz kuru serveri tas ierodas. Izvēlētais meistars saņem 100% slodzes, izņemot slodzi uz pieprasījuma pārsūtīšanu. Aktuāla datu kopija ir visiem datu centra serveriem, taču atbild tikai viens.

Vienīgais veids, kā paplašināt, ir aktivizēt stale režīmu klientā.

Stale režīmā var atbildēt bez kvora. Tas ir režīms, kurā mēs atsakāmies no datu saskaņotības, bet lasām nedaudz ātrāk nekā parasti, un atbild jebkurš servers. Protams, ieraksti tiek veikti tikai caur meistaru.

Consul neaizkopē datus starp datu centriem. Veidojot federāciju, katram serverim būs tikai savi dati. Par citiem viņš vienmēr vēršas pie kāda cita.

Operāciju atomiskums netiek garantēts ārpus transakcijas. Atcerieties, ka kaut ko var mainīt ne tikai jūs. Ja vēlaties darīt citādi, veiciet transakciju ar bloķēšanu.

Blokējošas operācijas negarantē bloķēšanu. Pieprasījums notiek no meistara uz meistaru, nevis tieši, tāpēc nav garantiju, ka bloķēšana darbosies, kad jūs veicat bloķēšanu, piemēram, citā datu centrā.

ACL arī negarantē piekļuvi (dažos gadījumos). ACL var nedarboties, jo tā tiek glabāta vienā datu centra federācijā — ACL datu centrā (Galvenais Datu Centrs). Ja DC jums neatbildēs, ACL nedarbosies.

Viens iesprūdis meistars novedīs pie visu federāciju iesprūšanas. Piemēram, federācijā ir 10 datu centri, un vienā ir slikta tīkla savienojums, un viens meistars sabrūk. Visi, kas ar viņu sazinās, iesprūst apli: notiek pieprasījums, nav atbildes, pavedienu iesprūst. Nebūs iespējams uzzināt, kad tas notiks, vienkārši pēc stundas vai divām sabruks visa federācija. Jūs neko ar to nevarat darīt.

Statuss, kvora un vēlēšanas apstrādā atsevišķs pavediena. Pārvēlēšanas nenotiks, statuss neko neuzrādīs. Jūs domājat, ka jūsu Consul ir dzīvs, pieprasāt, un nekas nenotiek — atbildes nav. Tajā pašā laikā statuss rāda, ka viss ir kārtībā.

Mēs sastapāmies ar šo problēmu, mums bija jāreorganizē konkrētas datu centra daļas, lai to izvairītos.

Biznesa versijā Consul Enterprise nav dažas iepriekš minētās trūkumi. Tajā ir daudz noderīgu funkciju: balsošanas izvēle, resursu sadale, mērogošana. Ir tikai viens «bet» — licences sistēma sadalītai sistēmai ir ļoti dārga.

Life hack: rm -rf /var/lib/consul — zāles pret visām aģenta slimībām. Ja kaut kas nedarbojas, vienkārši izdzēsiet savus datus un ielādējiet datus no dublējuma. Visticamāk, Consul darbosies.

BEFW

Tagad runāsim par to, ko mēs esam pievienojuši Consul.

BEFW — tas ir akronīms no BackEndFireWall. Bija nepieciešams kaut kā nosaukt produktu, kad es izveidoju repozitoriju, lai tajā ievietotu pirmos testa komitees. Šāds nosaukums arī palika.

Noteikumu veidnes

Noteikumi ir uzrakstīti iptables sintaksē.

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

Mums viss iet caur BEFW ķēdi, izņemot ESTABLISHED, RELATED un localhost. Šablons var būt jebkāds, tas ir tikai piemērs.

Kāds labums no BEFW?

Pakalpojumi

Mums ir pakalpojums, tajā vienmēr ir ports, mezgls, uz kura tas darbojas. No sava mezgla mēs varam lokāli jautāt aģentam un uzzināt, ka mums ir kāds pakalpojums. Ir iespējams arī pievienot tagus.

Ikviens pakalpojums, kas ir palaižams un reģistrēts Consul, pārvēršas par iptables noteikumu. Mums ir SSH — atveram portu 22. Bash skripts ir vienkāršs: curl un iptables, vairāk nekas nav vajadzīgs.

Klienti

Kā piekļūt ne visiem, bet selektīvi? Pēc pakalpojuma nosaukuma apkopot KV krātuvē IP sarakstus.

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

Piekļuves

Savienojam pakalpojumus un klientus: mums ir pakalpojums, katram ir pieejama KV krātuve. Tagad mēs nododam piekļuvi ne visiem, bet selektīvi.

Grupas

Ja katru reizi rakstīsim tūkstošiem IP piekļuvēm, tad būs nogurdinoši. Izdomāsim grupēšanu — atsevišķs apakškopums KV. Nosauksim to par Alias (vai grupām) un turēsim tur grupas pēc tā paša principa.

Savienojam: tagad varam atvērt SSH ne konkrēti uz P2P, bet uz veselu grupu vai vairākām grupām. Precīzi tāpat ir TTL — var pievienot grupai un izslēgt no grupas uz laiku.

Integrācija

Mūsu problēma — cilvēka faktors un automatizācija. Pagājuši esi to atrisinājuši tā.

Mēs strādājam ar Puppet un pārvietojam tajā visu, kas attiecas uz sistēmu (programmu kods). Puppetdb (parastais PostgreSQL) glabā sarakstu ar pakalpojumiem, kas tur ir palaisti, un tos var atrast pēc resursa veida. Tur var atrast arī, uz kuru pusi tiek vērsts pieprasījums. Mums ir arī pull request un merge request sistēma šim nolūkam.

Mēs uzrakstījām befw-sync — vienkāršāko risinājumu, kas palīdz pārvietot datus. Sākumā sync cookies vēršas pie puppetdb. Tur ir iestatīts HTTP API: mēs pieprasām, kādi pakalpojumi mums ir, un kas jādara. Pēc tam tiek veikts pieprasījums uz Consul.

Vai ir integrācija? Jā: mēs uzrakstījām noteikumus, atļāvām pieņemt Pull Request. Vai ir nepieciešams kāds ports vai pievienot hostu kādā grupā? Pull Request, atsauksmes — vairs nekādu "atrodi 200 citus ACL un mēģini kaut ko ar to izdarīt".

Optimizācija

Ping localhost ar tukšu noteikumu ķēdi aizņem 0,075 ms.

Pievienosim šai ķēdei 10 000 adreses iptables. Rezultātā ping palielināsies 5 reizes: iptables pilnībā lineārs, katras adreses apstrāde prasa kādu laiku.

Fajervolam, uz kuru mēs migrējam tūkstošiem ACL, mums ir daudz noteikumu, un tas ievieš aizturi. Tas ir slikti spēļu protokoliem.

Bet, ja mēs ievietosim 10 000 adreses ipset ping pat samazināsies.

Jēga ir tāda, ka "O" (algoritma sarežģītība) ipset vienmēr ir vienāda ar 1, cik daudz tur noteikumu nebūtu. Patiesībā tur ir ierobežojums — noteikumu nevar būt vairāk par 65535. Pagaidām dzīvojam ar to: tos var kombinēt, paplašināt, veikt divus ipset vienā.

Žurnālu glabāšana JSON formātā.

Loģisks turpinājums iterāciju procesam ir informācijas par klientiem glabāšana pakalpojumam ipset.

Tagad mums ir tas pats SSH, un mēs neuzrakstām uzreiz 100 IP, bet nosakām ipset nosaukumu, ar kuru jāsaņem kontaktinformācija, un nākamo noteikumu DROP. To var pārveidot vienā noteikumā "Kas nav šeit, tas DROP", bet tā ir vizuāli skaidrāk.

Tagad mums ir noteikumi un seti. Galvenā uzdevums ir izveidot setu pirms noteikuma rakstīšanas, jo citādi iptables neierakstīs noteikumu.

Kopējā shēma

Šemā viss, ko es pastāstīju, izskatās tā.

Mēs komitējam uz Puppet, viss tiek nosūtīts uz hostu, pakalpojumi šeit, ipset tur, bet kas tur nav norādīts, to neielaiž.

Atļaut & noraidīt

Lai ātri glābtu pasauli vai ātri kādu atslēgtu, ķēdes sākumā mēs izveidojām divus ipset: rules_allow un rules_deny. Kā tas darbojas?

Piemēram, kāds izmanto robotus, lai radītu slodzi uz mūsu tīmekļa vietni. Agrāk bija jāatrod tā IP adrese pēc žurnāliem un jānodod to tīkla inženieriem, lai viņi atrastu trafika avotu un to bloķētu. Tagad tas izskatās savādāk.

Mēs sūtām uz Consul, gaidām 2,5 sekunžu, un viss ir gatavs. Ņemot vērā, ka Consul P2P ātri izplata datus, tas darbojas visur, jebkurā vietā pasaulē.

Reiz es pilnībā apturēju WOT, kļūdoties ar ugunsmūri. rules_allow — tā ir mūsu apdrošināšana pret šādiem gadījumiem. Ja mēs kaut kur kļūdāmies ar ugunsmūri, un kaut kas tiek bloķēts, mēs vienmēr varam nosūtīt nosacītu 0.0/0, lai ātri visu atjaunotu. Pēc tam mēs visu salabosim ar rokām.

Citi ipseti

Var pievienot vienalga citus ipsetus telpā $IPSETS$.

Kāpēc? Dažreiz kādam ir nepieciešami ipseti, piemēram, lai emulētu kādas klastera daļas atslēgšanu. Ikviens var nest jebkādus ipsetus, tos nosaukt un tie tiks ņemti no Consul. Tajā pašā laikā ipseti var gan piedalīties iptables noteikumos, gan darboties kā komanda NOOP: konsekvence tiks uzturēta ar demonu.

Lietotāji

Agrāk bija tā: lietotājs pieslēdzās tīklam un caur domēnu saņēma parametrus. Līdz jauno paaudžu ugunsmūru parādīšanai Cisco nesaprata, kur ir lietotājs, un kur IP. Tāpēc piekļuve tika piešķirta tikai caur mašīnas hostname.

Ko mēs izdarījām? Mēs iejaucāmies brīdī, kad tiek saņemta adrese. Parasti tas ir dot1x, Wi-Fi vai VPN — viss notiek caur RADIUS. Katram lietotājam izveidojam grupu ar lietotājvārdu un ievietojam tajā IP ar TTL, kas ir vienāds ar viņa dhcp.lease — tiklīdz tas beidzas, noteikums izzūd.

Tagad mēs varam atvērt piekļuvi pakalpojumiem, kā arī citām grupām, pēc lietotājvārda. Mēs esam atbrīvojušies no sāpēm ar hostname, kad tie mainās, un mazinājuši slodzi no tīkla inženieriem, jo viņiem vairs nav nepieciešams Cisco. Tagad inženieri paši nosaka piekļuves savos serveros.

Izolācija

Vienlaicīgi mēs sākām analizēt izolāciju. Pakalpojumu pārvaldnieki veica inventarizāciju, un mēs analizējām visas mūsu tīklu struktūras. Mēs tās sadalīsim tādās pašās grupās, un vajadzīgajos servidores grupas pievienojām, piemēram, uz deny. Tagad tā pati izolācija stāvošā vidē nonāk rules_deny ražotnē, bet ne pašā ražotnē.

Shēma darbojas ātri un vienkārši: mēs noņemsim visas ACL no serveriem, atbrīvosim aparatūru, samazināsim izolēto VLAN skaitu.

Integritātes uzraudzība

Agrāk mēs izmantojām īpašu trigeri, kas ziņoja, kad kāds rokas darbs mainīja ugunsmūra noteikumu. Es rakstīju milzīgu ugunsmūra noteikumu pārbaudes linters, tas bija sarežģīti. Tagad integritāti kontrolē BEFW. Tas greizsirdīgi rūpējas, lai noteikumi, ko tas izveido, netiktu mainīti. Ja kāds maina ugunsmūra noteikumus, tas atgriezīs visu atpakaļ. "Es ātri uzstādīju proxy, lai strādātu no mājām" — šādu variantu vairs nav.

BEFW kontrolē ipset no pakalpojumiem un saraksta befw.conf, pakalpojumu noteikumus BEFW ķēdē. Bet tas neseko citiem ķēdēm, noteikumiem un citiem ipset.

Avariju aizsardzība

BEFW vienmēr saglabā pēdējo veiksmīgu stāvokli tieši binārā struktūrā state.bin. Ja kaut kas noiet greizi, tas vienmēr atgriežas atpakaļ uz šo state.bin.

Tas ir apdrošināšana pret nestabilu Consul darbību, kad tas nosūta datus vai kad kāds pieļauj kļūdu un izmanto noteikumus, kurus nevar piemērot. Lai mēs nepaliktu bez ugunsmūra, BEFW atgriezīsies uz pēdējo stāvokli, ja kādā posmā radīsies kļūda.

Kritiskās situācijās tā ir garantija, ka paliksim ar funkcionējošu ugunsmūri. Mēs atveram visas pelēkās tīklu daļas, cerot, ka administrators nāks un salabos. Kadreiz es to ievietošu konfigurācijās, bet šobrīd mums ir tikai trīs pelēkās tīklu daļas: 10/8, 172/12 un 192.168/16. Mūsu Consul kontekstā tā ir svarīga iezīme, kas palīdz attīstīties tālāk.

Demo: prezentācijas laikā Ivanā demonstrē BEFW demo režīmu. Demonstrāciju ērtāk skatīt uz video. Avota kods demo ir pieejams GitHub.

Zemūdens akmeņi

Pastāstīšu par kļūdām, ar kurām saskārāmies.

ipset add set 0.0.0.0/0. Kas notiks, ja pievienosim ipset 0.0.0.0/0? Vai pievienos visus IP? Vai tiks atvērts piekļuve internetam?

Nē, mēs iegūsim kļūdu, kas izmaksāja mums divas stundas dīkstāves. Un šī kļūda nedarbojas kopš 2016. gada, tā guļ RedHat Bugzilla ar numuru #1297092, un mēs to atradām nejauši — no izstrādātāja pārskata.

Tagad BEFW ir stingri noteikumi, ka 0.0.0.0/0 pārvēršas divos adresēs: 0.0.0.0/1 un 128.0.0.0/1.

ipset restore set < file. Ko ipset dara, kad sakāt tam restore? Вы думаете, он работает также, как iptables? Восстановит данные?

Nekas tamlīdzīgs — tas veic apvienošanu, un vecās adreses nekur nepazūd, piekļuve netiek slēgta.

Mēs atradām kļūdu, kad testējām izolāciju. Tagad tur ir diezgan sarežģīta sistēma — tā vietā restore notiek create temp, tad restore flush temp un restore temp. Beigās swap: atomiskumam, jo, ja vispirms veiktu flush Un šajā brīdī, ja pienāks kāds pakotne, tā tiks noraidīta un kaut kas noiet greizi. Tāpēc tur ir nedaudz melnās maģijas.

consul kv get -datacenter=other. Kā jau teicu, mēs domājam, ka pieprasām kādus datus, bet saņemsim vai nu datus, vai kļūdu. Mēs to varam darīt caur Consul lokāli, bet arī šajā gadījumā abos gadījumos tas iesaldēs.

Vietējais Consul klients ir pārklājums virs HTTP API. Bet tas vienkārši iesaldējas un neatbild ne uz Ctrl+C, ne uz Ctrl+Z, ne uz neko, tikai uz kill -9 blakus esošajā konsolē. Mēs ar to saskārāmies, kad veidojām lielu klasteri. Bet mums pagaidām nav risinājuma, mēs gatavojamies labot šo kļūdu Consul.

Consul līderis neatbild. Mums nedarbojas Master datu centrā, mēs domājam: “Droši vien tagad darbosies pārvēlēšanas algoritms?”

Nē, nedarbosies, un monitorings neko neparādīs: Consul teiks, ka ir saistību indekss, līderis atrasts, viss kārtībā.

Kā mēs ar to cīnāmies? service consul restart cron katru stundu. Ja jums ir 50 serveri — nav traki. Kad tos būs 16 000, jūs sapratīsiet, kā tas darbojas.

Secinājums

Galu galā mēs ieguvām šādus ieguvumus:

• 100% visām Linux mašīnām.
• Ātrums.
• Automatizāciju.
• Atbrīvojām aparatūru un tīkla inženierus no verdzības.
• Parādījās integrācijas iespējas, kas ir praktiski neierobežotas: pat ar Kubernetes, pat ar Ansible, pat ar Python.

Mīnusi: Consul, ar kuru mums tagad jādzīvo, un ļoti augsta kļūdas cena. Kā piemērs, reizi es plkst. 18:00 (pīķa laikā Krievijā) kaut ko mainīju tīklu sarakstā. Mēs tieši tolaik veidojām izolāciju uz BEFW. Es kaut kur kļūdījos, šķiet, norādīju ne to masku, bet viss sabruka divu sekunžu laikā. Aktivizējas monitors, atnāk atbalsta dienests: “Mums viss stāv!” Departamenta vadītājs paliecas pelēks, kad skaidroja biznesam, kāpēc tā notika.

Kļūdas cena ir tik augsta, ka mēs izdomājām savu sarežģīto profilakses procedūru. Ja jūs to implementēsiet lielā ražošanā, nevajag dot meistara token pār Consul visiem. Tas slikti beigsies.

Izmaksas. Es vienatnē rakstīju kodu 400 stundas. Uz atbalstu mana komanda no 4 cilvēkiem tērē 10 stundas mēnesī visiem. Salīdzinājumā ar jebkura jauna ģenerācijas ugunsmūra cenu, tas ir bezmaksas.

Plāni. Ilgtermiņa plāns ir meklēt alternatīvu transportu vietā vai papildus Consul. Varbūt tas būs Kafka vai kaut kas līdzīgs. Bet tuvākajos gados mēs dzīvosim uz Consul.

Nākošie plāni: integrācija ar Fail2ban, uzraudzības risinājumi, ar nftables, iespējams, arī citiem izplatījumiem, metri, paplašināta uzraudzība, optimizācija. Atbalsts Kubernetes arī ir plānots, jo šobrīd mums ir vairāki klasteri un vēlme.

Vēl no plāniem:

• anomaliju meklēšana satiksmē;
• tīkla kartes pārvaldība;
• Kubernetes atbalsts;
• pakotņu kompilācija visām sistēmām;
• Web-UI.

Nepārtraukti strādājam pie konfigurācijas paplašināšanas, metrikas palielināšanas un optimizācijas.

Pievienojieties projektam. Projekts ir izcils, bet, diemžēl, pašlaik tas ir viena cilvēka projekts. Nāciet uz GitHub un mēģiniet ko darīt: izdarīt commit, testēt, piedāvāt kādas idejas, sniegt savu novērtējumu.

Tikmēr mēs gatavojamies Saint HighLoad++, kas notiks 6. un 7. aprīlī Sanktpēterburgā, un aicinām augstas slodzes sistēmu izstrādātājus pieteikties uz ziņojumiem. Pieredzējuši runātāji jau zina, ko darīt, bet iesācējiem iesakām vismaz izmēģināt. Piedalīšanās konferencē kā runātājam sniedz vairākus ieguvumus. Par kādiem var lasīt, piemēram, noslēgumā šī raksta.

Avots: habr.com