W 2010 roku firma było 50 serwerów i prosty model sieci: backend, frontend i firewall. Wzrosła liczba serwerów, model stał się bardziej złożony: staging, izolowane sieci VLAN z listami ACL, następnie VPN z listami ACL, sieci VLAN z listami ACL na L2, VRF z listami ACL na L3. Głowa się kręci? Później będzie zabawniej.
Kiedy było 16 000 serwerów, praca bez łez z tak dużą liczbą heterogenicznych segmentów stała się niemożliwa. Dlatego wymyśliliśmy inne rozwiązanie. Wzięliśmy stos Netfilter, dodaliśmy do niego Consul jako źródło danych i otrzymaliśmy szybko rozproszoną zaporę ogniową. Zastąpili listy ACL na routerach i wykorzystali je jako zewnętrzną i wewnętrzną zaporę ogniową. Aby dynamicznie zarządzać narzędziem, opracowaliśmy system BEFW, który znalazł zastosowanie wszędzie: od zarządzania dostępem użytkowników do sieci produktowej po izolowanie od siebie segmentów sieci.
Opowie Ci jak to wszystko działa i dlaczego warto bliżej przyjrzeć się temu systemowi. Iwan Agarkow () jest szefem grupy ds. bezpieczeństwa infrastruktury w dziale Utrzymania Ruchu w centrum rozwoju firmy w Mińsku. Ivan jest fanem SELinuksa, kocha Perla i pisze kod. Jako szef grupy ds. bezpieczeństwa informacji regularnie pracuje z logami, kopiami zapasowymi oraz badaniami i rozwojem, aby chronić Wargaming przed hakerami i zapewnić działanie wszystkich serwerów gier w firmie.
Historyczne informacje
Zanim opowiem Wam, jak tego zrobiliśmy, opowiem przede wszystkim, jak do tego doszliśmy i dlaczego było to potrzebne. Aby to zrobić, cofnijmy się o 9 lat: 2010, właśnie pojawił się World of Tanks. Wargaming miał około 50 serwerów.
Wykres rozwoju serwerów firmy.
Mieliśmy model sieciowy. Na tamte czasy było optymalnie.
Model sieciowy w 2010 roku.
Na froncie są źli ludzie, którzy chcą nas złamać, ale ma zaporę ogniową. Na backendzie nie ma firewalla, ale jest tam 50 serwerów, znamy je wszystkie. Wszystko działa dobrze.
W ciągu 4 lat flota serwerów wzrosła 100-krotnie, do 5000. Pojawiły się pierwsze izolowane sieci - stacjonujące: nie mogły iść na produkcję, a często działy się tam rzeczy, które mogły być niebezpieczne.
Model sieciowy w 2014 roku.
Dzięki bezwładności użyliśmy tych samych elementów sprzętu, a cała praca została przeprowadzona na izolowanych sieciach VLAN: listy ACL są zapisywane w sieciach VLAN, które umożliwiają lub odmawiają pewnego rodzaju połączenia.
W 2016 roku liczba serwerów osiągnęła 8000. Wargaming wchłonął inne studia, pojawiły się dodatkowe sieci afiliacyjne. Wydają się być nasze, ale nie do końca: VLAN często nie działa u partnerów, trzeba używać VPN z VRF, izolacja staje się bardziej skomplikowana. Mieszanka izolacyjna ACL urosła.
Model sieciowy w 2016 roku.
Na początku 2018 roku flota maszyn powiększyła się do 16 000. Segmentów było 6, a pozostałych nie liczyliśmy, łącznie z zamkniętymi, w których przechowywane były dane finansowe. Pojawiły się sieci kontenerowe (Kubernetes), DevOps, sieci chmurowe połączone poprzez VPN np. z IVS. Zasad było mnóstwo – to było bolesne.
Model sieci i metody izolacji w 2018 roku.
Do izolacji użyliśmy: VLAN z ACL na L2, VRF z ACL na L3, VPN i wiele więcej. Zbyt wiele.
Problemy
Wszyscy żyją z ACL i VLAN. Co jest nie tak? Na to pytanie odpowie Harold, ukrywając ból.
Problemów było wiele, ale było pięć ogromnych.
- Geometryczny wzrost cen dla nowych zasad. Dodanie każdej nowej reguły trwało dłużej niż poprzedniej, ponieważ trzeba było najpierw sprawdzić, czy taka reguła już istnieje.
- Brak zapory ogniowej wewnątrz segmentów. Segmenty były w jakiś sposób od siebie oddzielone, a w środku było już za mało zasobów.
- Przepisy obowiązywały przez długi czas. Operatorzy mogliby ręcznie napisać jedną lokalną regułę w ciągu godziny. Globalne trwało kilka dni.
- Trudności z zasadami audytu. Dokładniej, nie było to możliwe. Pierwsze zasady powstały w 2010 roku, a większość ich autorów nie pracowała już w firmie.
- Niski poziom kontroli infrastruktury. To jest główny problem – nie bardzo wiedzieliśmy, co się dzieje w naszym kraju.
Tak wyglądał inżynier sieciowy w 2018 roku, gdy usłyszał: „Potrzebuję więcej list ACL”.
Solutions
Na początku 2018 roku postanowiono coś z tym zrobić.
Cena integracji stale rośnie. Punktem wyjścia było to, że duże centra danych przestały obsługiwać izolowane sieci VLAN i listy ACL, ponieważ w urządzeniach zabrakło pamięci.
Rozwiązanie: usunęliśmy czynnik ludzki i maksymalnie zautomatyzowaliśmy zapewnianie dostępu.
Nowe zasady obowiązują długo. Rozwiązanie: przyspiesz stosowanie reguł, spraw, aby było rozproszone i równoległe. Wymaga to systemu rozproszonego, aby reguły były dostarczane samodzielnie, bez rsync lub SFTP, do tysiąca systemów.
Brak zapory ogniowej wewnątrz segmentów. Zapora sieciowa w segmentach zaczęła do nas przychodzić, gdy w tej samej sieci pojawiły się różne usługi. Rozwiązanie: użyj zapory ogniowej na poziomie hosta - zapory oparte na hoście. Prawie wszędzie mamy Linuksa i wszędzie mamy iptables, nie stanowi to problemu.
Trudności z zasadami audytu. Rozwiązanie: Trzymaj wszystkie reguły w jednym miejscu, aby można było je przeglądać i zarządzać, abyśmy mogli wszystko kontrolować.
Niski poziom kontroli nad infrastrukturą. Rozwiązanie: przeprowadź inwentaryzację wszystkich usług i dostępów między nimi.
Jest to bardziej proces administracyjny niż techniczny. Czasami mamy 200-300 nowości tygodniowo, szczególnie w czasie promocji i świąt. Co więcej, dotyczy to tylko jednego zespołu naszych DevOps. Przy tak dużej liczbie wydań nie można określić, jakie porty, adresy IP i integracje są potrzebne. Dlatego potrzebowaliśmy specjalnie przeszkolonych menedżerów usług, którzy pytali zespoły: „Co tam w ogóle jest i dlaczego o tym poruszyliście?”
Po tym wszystkim co uruchomiliśmy, inżynier sieciowy w 2019 roku zaczął wyglądać tak.
Konsul
Zdecydowaliśmy, że wszystko, co znajdziemy przy pomocy menadżerów usług, umieścimy w Consul i stamtąd napiszemy reguły iptables.
Jak zdecydowaliśmy się to zrobić?
- Zbierzemy wszystkie usługi, sieci i użytkowników.
- Stwórzmy na ich podstawie reguły iptables.
- Automatyzujemy kontrolę.
- ....
- ZYSK.
Consul nie jest zdalnym API, może działać na każdym węźle i zapisywać do iptables. Pozostaje tylko wymyślić automatyczne sterowanie, które usunie niepotrzebne rzeczy, a większość problemów zostanie rozwiązana! Resztę ustalimy w trakcie.
Dlaczego Konsul?
Sprawdził się dobrze. W latach 2014-15 używaliśmy go jako backendu dla Vault, w którym przechowujemy hasła.
Nie traci danych. W czasie użytkowania Consul nie utracił danych w wyniku ani jednego wypadku. Jest to ogromny plus dla systemu zarządzania zaporą sieciową.
Połączenia P2P przyspieszają rozprzestrzenianie się zmian. Dzięki P2P wszystkie zmiany następują szybko, nie trzeba czekać godzinami.
Wygodny interfejs API REST. Rozważaliśmy także Apache ZooKeeper, ale nie ma on interfejsu API REST, więc będziesz musiał zainstalować kule.
Działa zarówno jako magazyn kluczy (KV), jak i katalog (wykrywanie usług). Możesz jednocześnie przechowywać usługi, katalogi i centra danych. Jest to wygodne nie tylko dla nas, ale także dla sąsiednich zespołów, ponieważ budując globalną usługę, myślimy na dużą skalę.
Napisane w Go, które jest częścią stosu Wargaming. Kochamy ten język, mamy wielu programistów Go.
Potężny system ACL. W programie Consul możesz używać list ACL do kontrolowania, kto i co pisze. Gwarantujemy, że reguły firewalla nie będą się nakładać na nic innego i nie będziemy mieli z tym problemów.
Ale Consul ma też swoje wady.
- Nie skaluje się w centrum danych, chyba że masz wersję biznesową. Można go skalować wyłącznie w ramach federacji.
- Bardzo zależy od jakości sieci i obciążenia serwera. Consul nie będzie działał poprawnie jako serwer na obciążonym serwerze, jeśli w sieci występują opóźnienia, np. nierówna prędkość. Wynika to z połączeń P2P i modeli dystrybucji aktualizacji.
- Trudność w monitorowaniu dostępności. Będąc konsulem, może powiedzieć, że wszystko jest w porządku, ale zmarł już dawno temu.
Większość tych problemów rozwiązaliśmy korzystając z programu Consul, dlatego go wybraliśmy. Firma ma plany na alternatywny backend, ale nauczyliśmy się radzić sobie z problemami i obecnie mieszkamy z Consulem.
Jak działa Konsul
Zainstalujemy od trzech do pięciu serwerów w warunkowym centrum danych. Jeden czy dwa serwery nie będą działać: nie będą w stanie zorganizować kworum i zdecydować, kto ma rację, a kto nie, gdy dane się nie zgadzają. Więcej niż pięć nie ma sensu, produktywność spadnie.
Klienci łączą się z serwerami w dowolnej kolejności: ci sami agenci, tylko z flagą server = false.
Następnie klienci otrzymują listę połączeń P2P i budują połączenia między sobą.
Na poziomie globalnym łączymy kilka centrów danych. Łączą także P2P i komunikują się.
Gdy chcemy pobrać dane z innego centrum danych, żądanie przechodzi z serwera na serwer. Ten schemat nazywa się Protokół Serfa. Protokół Serf, podobnie jak Consul, został opracowany przez HashiCorp.
Kilka ważnych faktów o Konsulu
Konsul posiada dokumentację opisującą jak to działa. Podam tylko wybrane fakty, które warto poznać.
Serwery konsulów wybierają mistrza spośród wyborców. Consul wybiera mastera z listy serwerów dla każdego centrum danych i wszystkie żądania trafiają tylko do niego, niezależnie od liczby serwerów. Zamrożenie mistrza nie prowadzi do reelekcji. Jeżeli master nie zostanie wybrany, żądania nie będą przez nikogo obsługiwane.
Czy chciałeś skalować poziomo? Przepraszam, nie.
Żądanie do innego centrum danych przechodzi od głównego do głównego, niezależnie od tego, do którego serwera dotarło. Wybrany master otrzymuje 100% obciążenia, z wyjątkiem obciążenia w przypadku żądań forward. Wszystkie serwery w centrum danych mają aktualną kopię danych, ale tylko jeden odpowiada.
Jedynym sposobem skalowania jest włączenie trybu przestarzałego na kliencie.
W trybie nieaktualnym można odpowiadać bez kworum. Jest to tryb, w którym rezygnujemy ze spójności danych, ale czytamy je nieco szybciej niż zwykle, a dowolny serwer odpowiada. Naturalnie nagrywanie tylko poprzez master.
Consul nie kopiuje danych pomiędzy centrami danych. Po utworzeniu federacji każdy serwer będzie miał tylko własne dane. W przypadku innych zawsze zwraca się do kogoś innego.
Nie gwarantuje się atomowości operacji poza transakcją. Pamiętaj, że nie jesteś jedyną osobą, która może coś zmienić. Jeśli chcesz inaczej, przeprowadź transakcję z zamkiem.
Operacje blokujące nie gwarantują zablokowania. Żądanie przechodzi od mastera do mastera, a nie bezpośrednio, więc nie ma gwarancji, że blokada zadziała, gdy zablokujesz na przykład w innym centrum danych.
ACL również nie gwarantuje dostępu (w wielu przypadkach). Lista ACL może nie działać, ponieważ jest przechowywana w jednym federacyjnym centrum danych — w centrum danych ACL (główny kontroler domeny). Jeśli DC nie odpowie, lista ACL nie będzie działać.
Jeden zamrożony mistrz spowoduje zamrożenie całej federacji. Na przykład w federacji istnieje 10 centrów danych, jedno ma złą sieć, a jeden master ulega awarii. Każdy, kto się z nim komunikuje, utknie w kręgu: jest prośba, nie ma na nią odpowiedzi, wątek się zawiesza. Nie wiadomo, kiedy to nastąpi, zaledwie za godzinę lub dwie cała federacja upadnie. Nic nie możesz na to poradzić.
Status, kworum i wybory to osobny wątek. Reelekcji nie będzie, status nic nie pokaże. Myślisz, że masz żywego Konsula, pytasz i nic się nie dzieje – nie ma odpowiedzi. Jednocześnie status pokazuje, że wszystko jest w porządku.
Napotkaliśmy ten problem i aby go uniknąć, musieliśmy przebudować określone części centrów danych.
Wersja biznesowa Consul Enterprise nie ma części z powyższych wad. Posiada wiele przydatnych funkcji: selekcja wyborców, dystrybucja, skalowanie. Jest tylko jedno „ale” – system licencjonowania systemu rozproszonego jest bardzo drogi.
Hackowanie życia: rm -rf /var/lib/consul - lekarstwo na wszystkie choroby agenta. Jeśli coś Ci nie odpowiada, po prostu usuń swoje dane i pobierz dane z kopii. Najprawdopodobniej Consul będzie działać.
BEFW
Porozmawiajmy teraz o tym, co dodaliśmy do Consula.
jest skrótem od BackEndFgniewWWszystko. Musiałem jakoś nazwać produkt, kiedy tworzyłem repozytorium, aby umieścić w nim pierwsze zatwierdzenia testowe. To imię pozostało.
Szablony reguł
Reguły są napisane w składni iptables.
- -N BEFW
- -P SPADEK WEJŚCIA
- -A WEJŚCIE -m stan – stan POWIĄZONY, USTALONY -j AKCEPTUJ
- -A WEJŚCIE -i lo -j AKCEPTUJĘ
- -A WEJŚCIE -j BEFW
Wszystko oprócz tego trafia do łańcucha BEFW ESTABLISHED, RELATED i host lokalny. Szablon może być dowolny, to tylko przykład.
W jaki sposób BEFW jest przydatny?
Usługi
Mamy usługę, zawsze ma ona port, węzeł, na którym działa. Z naszego węzła możemy lokalnie zapytać agenta i dowiedzieć się, że mamy jakąś usługę. Możesz także umieścić tagi.
Każda usługa uruchomiona i zarejestrowana w Consul zamienia się w regułę iptables. Mamy SSH - otwarty port 22. Skrypt Bash jest prosty: curl i iptables, nic więcej nie jest potrzebne.
Klienci
Jak otworzyć dostęp nie dla wszystkich, ale wybiórczo? Dodaj listy adresów IP do pamięci KV według nazwy usługi.
Na przykład chcemy, aby wszyscy w dziesiątej sieci mieli dostęp do usługi SSH_TCP_22. Dodać jedno małe pole TTL? i teraz mamy pozwolenia tymczasowe, np. na jeden dzień.
Dostęp
Łączymy usługi i klientów: mamy serwis, magazyn KV jest gotowy na każdego. Teraz dajemy dostęp nie każdemu, ale wybiórczo.
Grupa
Jeśli za każdym razem będziemy pisać tysiące adresów IP w celu uzyskania dostępu, zmęczymy się. Wymyślmy grupy - oddzielny podzbiór w KV. Nazwijmy to Aliasem (lub grupami) i przechowujmy tam grupy według tej samej zasady.
Połączmy się: teraz możemy otworzyć SSH nie specjalnie dla P2P, ale dla całej grupy lub kilku grup. Podobnie jest z TTL - możesz dodawać do grupy i tymczasowo usuwać z grupy.
integracja
Naszym problemem jest czynnik ludzki i automatyzacja. Do tej pory rozwiązaliśmy to w ten sposób.
Współpracujemy z Puppetem i przekazujemy im wszystko co związane z systemem (kod aplikacji). Puppetdb (zwykły PostgreSQL) przechowuje listę usług, które tam działają, można je znaleźć według typu zasobu. Tam dowiesz się, kto gdzie aplikuje. Mamy do tego również system żądania ściągnięcia i żądania połączenia.
Napisaliśmy befw-sync, proste rozwiązanie pomagające przesyłać dane. Po pierwsze, dostęp do plików cookie synchronizacji uzyskuje puppetdb. Tam konfiguruje się API HTTP: pytamy, jakie mamy usługi, co należy zrobić. Następnie zwracają się z prośbą do Konsula.
Czy jest integracja? Tak: napisali zasady i zezwolili na akceptowanie żądań ściągnięcia. Czy potrzebujesz określonego portu lub dodać hosta do jakiejś grupy? Pull Request, przegląd – koniec z „Znajdź 200 innych list ACL i spróbuj coś z tym zrobić”.
Optymalizacja
Pingowanie hosta lokalnego z pustym łańcuchem reguł zajmuje 0,075 ms.
Dodajmy do tego łańcucha 10 000 adresów iptables. W rezultacie ping wzrośnie 5 razy: iptables działa całkowicie liniowo, przetwarzanie każdego adresu zajmuje trochę czasu.
W przypadku zapory sieciowej, do której migrujemy tysiące list ACL, mamy wiele reguł, co wprowadza opóźnienia. Jest to niekorzystne dla protokołów gier.
Ale jeśli umieścimy 10 000 adresów w ipset Ping nawet spadnie.
Chodzi o to, że „O” (złożoność algorytmu) dla ipset jest zawsze równa 1, niezależnie od tego, ile jest reguł. To prawda, że istnieje ograniczenie - nie może być więcej niż 65535 reguł. Na razie z tym żyjemy: możesz je łączyć, rozszerzać, tworzyć dwa ipsety w jednym.
magazynowanie
Logiczną kontynuacją procesu iteracji jest przechowywanie informacji o klientach usługi w ipset.
Teraz mamy to samo SSH i nie piszemy 100 adresów IP na raz, ale ustawiamy nazwę ipset, z którym musimy się komunikować, i następującą regułę DROP. Można to sprowadzić do jednej zasady „Kogo tu nie ma, DROP”, ale jest bardziej przejrzysta.
Teraz mamy zasady i zestawy. Głównym zadaniem jest utworzenie zestawu przed napisaniem reguły, ponieważ w przeciwnym razie iptables nie napisze reguły.
Schemat ogólny
W formie diagramu wszystko, co powiedziałem, wygląda tak.
Zobowiązujemy się do Puppet, wszystko jest wysyłane do hosta, usługi tutaj, ipset tam, a każdy, kto nie jest tam zarejestrowany, nie jest dozwolony.
Pozwalają zaprzeczyć
Aby szybko uratować świat lub szybko kogoś unieszkodliwić, na początku wszystkich łańcuchów utworzyliśmy dwa ipsety: rules_allow и rules_deny. Jak to działa?
Na przykład ktoś tworzy obciążenie w naszej sieci za pomocą botów. Wcześniej trzeba było znaleźć jego adres IP z logów, zanieść go inżynierom sieci, aby mogli znaleźć źródło ruchu i zablokować go. Teraz wygląda to inaczej.
Wysyłamy do Konsula, czekamy 2,5 sekundy i gotowe. Ponieważ Consul szybko dystrybuuje poprzez P2P, działa wszędzie, w dowolnej części świata.
Kiedyś w jakiś sposób całkowicie zatrzymałem WOT z powodu błędu w zaporze sieciowej. rules_allow - to nasze ubezpieczenie od takich przypadków. Jeśli popełniliśmy gdzieś błąd z firewallem, coś gdzieś jest zablokowane, zawsze możemy wysłać warunkowe 0.0/0aby szybko wszystko zebrać. Później naprawimy wszystko ręcznie.
Inne zestawy
Możesz dodać dowolne inne zestawy w przestrzeni $IPSETS$.
Po co? Czasami ktoś potrzebuje ipset, na przykład, aby emulować zamknięcie jakiejś części klastra. Każdy może przynieść dowolne zestawy, nadać im nazwę, a następnie je odebrać u Konsula. Jednocześnie zestawy mogą albo uczestniczyć w zasadach iptables, albo działać jako zespół NOOP: Spójność będzie utrzymywana przez demona.
użytkowników
Poprzednio było tak: użytkownik łączył się z siecią i odbierał parametry przez domenę. Przed pojawieniem się zapór ogniowych nowej generacji Cisco nie wiedziało, jak zrozumieć, gdzie znajduje się użytkownik i gdzie znajduje się jego adres IP. Dlatego dostęp został przyznany tylko poprzez nazwę hosta komputera.
Co zrobiliśmy? Utknęliśmy w momencie otrzymania adresu. Zwykle jest to dot1x, Wi-Fi lub VPN - wszystko przechodzi przez RADIUS. Dla każdego użytkownika tworzymy grupę według nazwy użytkownika i umieszczamy w niej adres IP z TTL równym jego dhcp.lease - gdy tylko wygaśnie, reguła zniknie.
Teraz możemy otwierać dostęp do usług, podobnie jak innych grup, według nazwy użytkownika. Odciążyliśmy uciążliwości związane ze zmianą nazw hostów i odciążyliśmy inżynierów sieciowych, którzy nie potrzebowali już Cisco. Teraz inżynierowie sami rejestrują dostęp na swoich serwerach.
Izolacja
Jednocześnie rozpoczęliśmy demontaż izolacji. Menedżerowie usług przeprowadzili inwentaryzację i przeanalizowaliśmy wszystkie nasze sieci. Podzielmy je na te same grupy i na niezbędnych serwerach dodaliśmy grupy np. do odmowy. Teraz ta sama izolacja inscenizacji kończy się zaprzeczeniem zasad produkcji, ale nie samą produkcją.
Schemat działa szybko i prosto: usuwamy wszystkie listy ACL z serwerów, zwalniamy sprzęt i zmniejszamy liczbę izolowanych sieci VLAN.
Kontrola integralności
Wcześniej mieliśmy specjalny wyzwalacz, który raportował, gdy ktoś ręcznie zmienił regułę zapory. Pisałem ogromny linter do sprawdzania reguł zapory ogniowej, było to trudne. Integralność jest teraz kontrolowana przez BEFW. Gorliwie dba o to, aby ustanawiane przez niego zasady nie uległy zmianie. Jeśli ktoś zmieni reguły zapory sieciowej, wszystko się zmieni. „Szybko skonfigurowałem proxy, żeby móc pracować z domu” – nie ma już takich opcji.
BEFW kontroluje ipset z usług i umieszcza w befw.conf reguły usług w łańcuchu BEFW. Ale nie monitoruje innych łańcuchów i reguł ani innych zestawów ipset.
Ochrona przed awarią
BEFW zawsze przechowuje ostatni znany dobry stan bezpośrednio w strukturze binarnej state.bin. Jeśli coś pójdzie nie tak, zawsze powraca do tego stanu.bin.
Jest to zabezpieczenie przed niestabilną pracą Konsula, gdy nie przesłał danych lub ktoś się pomylił i zastosował reguły, których nie można zastosować. Aby mieć pewność, że nie pozostaniemy bez zapory ogniowej, BEFW przywróci najnowszy stan, jeśli na którymkolwiek etapie wystąpi błąd.
W sytuacjach krytycznych jest to gwarancja, że pozostanie nam działający firewall. Otwieramy wszystkie szare sieci w nadziei, że administrator przyjdzie i to naprawi. Któregoś dnia umieszczę to w konfiguracji, ale teraz mamy tylko trzy szare sieci: 10/8, 172/12 i 192.168/16. W naszym Konsulu jest to ważna cecha, która pomaga nam dalej się rozwijać.
Demo: podczas relacji Ivan demonstruje tryb demonstracyjny BEFW. Łatwiej jest oglądać demonstrację . Dostępny kod źródłowy wersji demonstracyjnej .
Pułapki
Opowiem Ci o błędach, które napotkaliśmy.
ipset dodaj zestaw 0.0.0.0/0. Co się stanie, jeśli dodasz 0.0.0.0/0 do ipset? Czy wszystkie adresy IP zostaną dodane? Czy będzie dostępny dostęp do Internetu?
Nie, dostaniemy błąd, który będzie kosztował nas dwie godziny przestoju. Co więcej, błąd nie działa od 2016 roku, znajduje się on w RedHat Bugzilla pod numerem #1297092, a znaleźliśmy go przez przypadek - na podstawie raportu dewelopera.
Obecnie w BEFW jest to surową zasadą 0.0.0.0/0 zamienia się w dwa adresy: 0.0.0.0/1 и 128.0.0.0/1.
ipset zestaw przywracania < plik. Co robi ipset, gdy mu to każesz restore? Czy myślisz, że działa tak samo jak iptables? Czy odzyska dane?
Nic takiego - następuje scalanie, a stare adresy nigdzie nie idą, nie blokujesz dostępu.
Podczas testowania izolacji znaleźliśmy błąd. Teraz istnieje dość złożony system - zamiast restore trzymany create temp, a następnie restore flush temp и restore temp. Na koniec zamiana: na atomowość, bo jeśli zrobisz to pierwszy flush i w tym momencie nadejdzie jakiś pakiet, zostanie on odrzucony i coś pójdzie nie tak. Jest więc w tym trochę czarnej magii.
consul kv get -datacenter=inne. Jak powiedziałem, wydaje nam się, że prosimy o pewne dane, ale albo otrzymamy dane, albo wystąpi błąd. Możemy to zrobić lokalnie za pośrednictwem Consula, ale w tym przypadku oba się zamrożą.
Lokalny klient Consul jest opakowaniem interfejsu API HTTP. Ale po prostu się zawiesza i nie reaguje tylko na Ctrl+C, Ctrl+Z czy cokolwiek innego kill -9 w następnej konsoli. Napotkaliśmy to, gdy budowaliśmy duży klaster. Ale nie mamy jeszcze rozwiązania; przygotowujemy się do naprawienia tego błędu w programie Consul.
Lider konsula nie odpowiada. Nasz mistrz w centrum danych nie odpowiada, myślimy: „Być może algorytm ponownego wyboru będzie teraz działać?”
Nie, to nie zadziała, monitoring nic nie pokaże: Konsul powie, że jest wskaźnik zaangażowania, lider się znalazł, wszystko jest w porządku.
Jak sobie z tym radzimy? service consul restart w cronie co godzinę. Jeśli masz 50 serwerów, nie ma problemu. Kiedy będzie ich 16 000, zrozumiecie, jak to działa.
wniosek
W rezultacie otrzymaliśmy następujące korzyści:
- 100% pokrycie wszystkich maszyn z systemem Linux.
- Prędkość.
- Automatyzacja.
- Uwolniliśmy inżynierów sprzętu i sieci z niewoli.
- Pojawiły się możliwości integracji, które są niemal nieograniczone: nawet z Kubernetesem, nawet z Ansible, nawet z Pythonem.
Wady: Konsul, z którym musimy teraz żyć, i bardzo wysoki koszt błędu. Przykładowo raz o 6:XNUMX (prime time w Rosji) edytowałem coś na listach sieci. W tym czasie budowaliśmy izolację w BEFW. Gdzieś się pomyliłem, zdaje się, że wskazałem złą maskę, ale wszystko padło w dwie sekundy. Włącza się monitoring, przybiega dyżurujący pomocnik: „Mamy wszystko!” Kierownik działu posiwiał, gdy wyjaśnił firmie, dlaczego tak się stało.
Koszt błędu jest tak wysoki, że opracowaliśmy własną, złożoną procedurę zapobiegania. Jeśli wdrożysz to w dużym zakładzie produkcyjnym, nie musisz dawać wszystkim tokena głównego nad Consul. To się źle skończy.
Koszt. Sam pisałem kod przez 400 godzin. Mój 4-osobowy zespół spędza 10 godzin miesięcznie na wsparciu dla wszystkich. W porównaniu do ceny dowolnej zapory nowej generacji, jest ona bezpłatna.
Plany. Plan długoterminowy zakłada znalezienie alternatywnego transportu, który zastąpi lub uzupełni usługę Consul. Być może będzie to Kafka lub coś podobnego. Ale w nadchodzących latach będziemy mieszkać na Konsulu.
Plany doraźne: integracja z Fail2ban, z monitoringiem, z nftables, ewentualnie z innymi dystrybucjami, metryki, zaawansowany monitoring, optymalizacja. Wsparcie Kubernetesa też jest gdzieś w planach, bo teraz mamy kilka klastrów i chęci.
Więcej z planów:
- szukać anomalii w ruchu;
- zarządzanie mapą sieci;
- Wsparcie Kubernetesa;
- kompletowanie pakietów dla wszystkich systemów;
- Interfejs sieciowy.
Stale pracujemy nad rozbudową konfiguracji, zwiększeniem metryk i optymalizacją.
Dołącz do projektu. Projekt okazał się fajny, ale niestety jest to nadal projekt jednoosobowy. Przyjść do i spróbuj coś zrobić: zatwierdź, przetestuj, zasugeruj coś, wystaw ocenę.
Tymczasem przygotowujemy się do , które odbędzie się 6 i 7 kwietnia w Petersburgu, na które zapraszamy twórców systemów wysokoobciążeniowych . Doświadczeni mówcy już wiedzą, co robić, ale tym, którzy dopiero zaczynają mówić, polecamy przynajmniej . Udział w konferencji w roli prelegenta niesie ze sobą szereg korzyści. Które z nich możesz przeczytać np. na końcu .
Źródło: www.habr.com