Im Jahr 2010 hatte das Unternehmen 50 Server und ein einfaches Netzwerkmodell: Backend, Frontend und Firewall. Die Anzahl der Server wuchs, das Modell wurde komplexer: Staging, isolierte VLAN mit ACL, dann VPN mit VRF, VLAN mit ACL auf L2, VRF mit ACL auf L3. Schwindelig geworden? Es wird noch spannender.
Als die Anzahl der Server auf 16.000 anstieg, wurde es unmöglich, ohne Tränen mit einer solchen Menge an heterogenen Segmenten zu arbeiten. Daher kam eine andere Lösung auf. Wir verwendeten den Netfilter-Stack, fügten ihm Consul als Datenquelle hinzu, und erhielten eine schnelle verteilte Firewall. Diese ersetzte ACL auf den Routern und wurde sowohl als externe als auch interne Firewall genutzt. Für die dynamische Verwaltung des Tools entwickelten wir das BEFW-System, das wir überall anwendeten: von der Benutzerzugangsverwaltung im Produktivnetzwerk bis zur Isolation von Netzwerkssegmenten voneinander.
Wie das alles funktioniert und warum Sie diesem System Aufmerksamkeit schenken sollten, erklärt Iwan Agarokov () – Leiter der Gruppe für Infrastruktur-Sicherheit der Maintenance-Abteilung im Entwicklungszentrum in Minsk des Unternehmens. Iwan ist ein Fan von SELinux, liebt Perl und schreibt Code. Als Leiter der IT-Sicherheitsgruppe arbeitet er regelmäßig mit Logs, Backups und R&D, um Wargaming vor Hackern zu schützen und den Betrieb aller Spieleserver im Unternehmen sicherzustellen.
Historisches Nachschlagewerk
Bevor ich erkläre, wie wir das gemacht haben, erzähle ich, wie wir überhaupt dazu gekommen sind und warum es notwendig war. Dafür reisen wir 9 Jahre zurück: Jahr 2010, World of Tanks just erschienen. Wargaming hatte etwa 50 Server.
Grafik des Serverwachstums des Unternehmens.
Wir hatten ein Netzwerkmodell. Zu der Zeit war es optimal.
Das Netzwerkmodell im Jahr 2010.
Im Frontend leben die Bösewichte, die uns kaputt machen wollen, aber es gibt eine Firewall. Im Backend gibt es keine Firewall, aber dort sind 50 Server, die wir alle kennen. Alles funktioniert gut.
In 4 Jahren wuchs der Serverpark auf das 100-fache, auf 5000. Die ersten isolierten Netzwerke - Staging - wurden eingeführt: sie können nicht in die Produktion gehen, dort drehte sich oft etwas, das gefährlich sein konnte.
Das Netzwerkmodell im Jahr 2014.
Wir verwendeten aus Gewohnheit die gleichen Geräte, und die gesamte Arbeit wurde auf isolierten VLAN durchgeführt: zu den VLAN wurden ACL geschrieben, die eine Verbindung erlauben oder verweigern.
Im Jahr 2016 erreichte die Anzahl der Server 8000. Wargaming übernahm andere Studios, und es entstanden zusätzliche Partnernetzwerke. Sie scheinen unsere zu sein, sind es aber nicht ganz: Für Partner funktioniert VLAN oft nicht, es muss ein VPN mit VRF verwendet werden, die Isolierungen werden komplizierter. Eine Mischung aus Isolierungen von ACL nahm zu.
Das Netzwerkmodell im Jahr 2016.
Anfang 2018 wuchs der Maschinenpark auf 16.000. Es gab 6 Segmente, die anderen haben wir nicht gezählt, einschließlich der geschlossenen, in denen Finanzdaten gespeichert waren. Es entstanden Containernetzwerke (Kubernetes), DevOps, Cloud-Netzwerke, die per VPN verbunden waren, beispielsweise aus IWS. Es gab sehr viele Regeln — es war schmerzhaft.
Das Netzwerkmodell und die Isolationsmethoden im Jahr 2018.
Für die Isolierung verwendeten wir: VLAN mit ACL auf L2, VRF mit ACL auf L3, VPN und vieles andere. Viel zu viel.
Probleme
Alle leben mit ACL und VLAN. Was ist überhaupt das Problem? Auf diese Frage wird Harold antworten, der den Schmerz verbirgt.
Es gab viele Probleme, aber die massiven — fünf.
- Geometrisches Wachstum der Kosten für neue Regeln. Jede neue Regel wurde länger hinzugefügt als die vorherige, weil zuerst geprüft werden musste, ob es diese Regel bereits gab.
- Kein Firewall innerhalb der Segmente. Die Segmente waren irgendwie voneinander getrennt, innen fehlten bereits die Ressourcen.
- Die Regeln wurden lange angewendet. Manuell konnte ein Operateur eine lokale Regel in einer Stunde schreiben. Eine globale dauerte mehrere Tage.
- Schwierigkeiten mit dem Audit der Regeln. Genauer gesagt, es war nicht möglich. Die ersten Regeln wurden bereits 2010 geschrieben, und die meisten ihrer Autoren arbeiteten nicht mehr im Unternehmen.
- Niedriges Kontrollniveau über die Infrastruktur. Das ist das Hauptproblem — wir wussten schlecht, was bei uns überhaupt vor sich ging.
So sah ein Netzwerkingenieur im Jahr 2018 aus, als er hörte: „Wir brauchen noch etwas mehr ACL“.
Lösungen
Anfang 2018 wurde beschlossen, etwas dagegen zu tun.
Die Kosten für Integrationen steigen kontinuierlich. Der Ausgangspunkt war, dass große Rechenzentren aufhörten, isolierte VLAN und ACL zu unterstützen, da der Speicher auf den Geräten zur Neige ging.
Lösung: Den menschlichen Faktor entfernt und den Zugang so weit wie möglich automatisiert.
Neue Regeln werden lange angewendet. Lösung: Das Anwenden von Regeln beschleunigen, es dezentral und parallel gestalten. Dafür ist ein verteiltes System erforderlich, damit die Regeln selbsttätig verteilt werden, ohne rsync oder SFTP auf tausend Systeme.
Das Fehlen einer Firewall innerhalb der Segmente. Die Firewall innerhalb der Segmente begann, uns zu erreichen, als in einem Netzwerk verschiedene Dienste auftauchten. Lösung: Verwenden Sie Firewalls auf Host-Ebene - host-basierte Firewalls. Überall haben wir Linux und überall gibt es iptables, das ist kein Problem.
Schwierigkeiten bei der Überprüfung der Regeln. Lösung: Alle Regeln an einem Ort für die Übersicht und Verwaltung speichern, so können wir alles überprüfen.
Niedriges Niveau der Kontrolle über die Infrastruktur. Lösung: Eine Inventarisierung aller Dienste und Zugriffe zwischen ihnen durchführen.
Das ist mehr ein administrativer Prozess als ein technischer. Manchmal haben wir 200-300 neue Releases pro Woche, besonders während von Aktionen und Feiertagen. Das ist nur für ein Team unserer DevOps. Mit so vielen Releases ist es unmöglich zu sehen, welche Ports, IPs, Integrationen benötigt werden. Daher benötigen wir speziell ausgebildete Service-Manager, die die Teams befragen: „Was gibt es und warum habt ihr das hochgefahren?“
Nach allem, was wir in 2019 gestartet haben, sah der Netzwerkingenieur bereits so aus.
Consul
Wir haben entschieden, alles, was wir mit Hilfe der Service-Manager gefunden haben, in Consul zu speichern und von dort die iptables-Regeln zu schreiben.
Wie haben wir beschlossen, das zu tun?
- Alle Dienste, Netzwerke und Benutzer sammeln.
- Darauf basierend iptables-Regeln erstellen.
- Die Kontrolle automatisieren.
- ….
- PROFIT.
Consul ist keine entfernte API, es kann auf jedem Knoten arbeiten und in iptables schreiben. Es bleibt nur, automatische Kontrollmittel zu erfinden, die Überflüssiges bereinigen, und der Großteil der Probleme wird gelöst! Den Rest werden wir im Prozess ausarbeiten.
Warum Consul?
Hat sich bewährt. In den Jahren 2014-15 haben wir es als Backend für Vault verwendet, in dem wir Passwörter speichern.
Verliert keine Daten.. Während der gesamten Nutzung hat Consul bei keinem Vorfall Daten verloren. Das ist ein großer Vorteil für das Firewallsystem.
P2P-Verbindungen beschleunigen die Verbreitung von Änderungen.. Mit P2P kommen alle Änderungen schnell, man muss nicht stundenlang warten.
Bequeme REST API. Wir haben auch Apache ZooKeeper in Betracht gezogen, aber es hat keine REST API, da müsste man Kompromisse eingehen.
Funktioniert sowohl als Schlüsselwertspeicher (KV) als auch als Verzeichnis (Service Discovery).. Man kann gleichzeitig Dienste, Verzeichnisse und Rechenzentren speichern. Das ist nicht nur für uns praktisch, sondern auch für benachbarte Teams, denn beim Aufbau eines globalen Dienstes denken wir groß.
Ist in Go geschrieben, das zum Stack von Wargaming gehört. Wir lieben diese Sprache, wir haben viele Go-Entwickler.
Leistungsstarkes ACL-System. Mit ACL in Consul kann man steuern, wer was schreiben darf. Wir garantieren, dass die Firewall-Regeln sich nicht mit etwas anderem überschneiden, und wir werden damit keine Probleme haben.
Aber Consul hat auch Nachteile.
- Skaliert nicht innerhalb des Rechenzentrums, wenn Sie nicht die Business-Version haben. Es skaliert nur über Föderation.
- Sehr abhängig von der Netzwerkqualität und der Serverlast. Consul wird nicht gut als Server auf einem stark belasteten Server laufen, wenn es im Netzwerk Verzögerungen gibt, zum Beispiel eine unregelmäßige Geschwindigkeit. Dies hängt mit P2P-Verbindungen und den Verteilungsmodellen von Updates zusammen.
- Schwierigkeiten bei der Überwachung der Verfügbarkeit. Im Status von Consul kann stehen, dass alles gut ist, während er schon längst down ist.
Die meisten dieser Probleme haben wir während des Betriebs von Consul gelöst, weshalb wir uns dafür entschieden haben. Es gibt Pläne für ein alternatives Backend, aber wir haben gelernt, mit den Problemen umzugehen und leben vorerst mit Consul.
Wie Consul funktioniert
Wir installieren Server in einem hypothetischen Rechenzentrum – von drei bis fünf. Ein oder zwei Server reichen nicht aus: sie können kein Quorum bilden und entscheiden, wer recht hat und wer nicht, wenn die Daten nicht übereinstimmen. Mehr als fünf sind nicht sinnvoll, die Leistung wird sinken.
Clients verbinden sich in beliebiger Reihenfolge mit den Servern: dieselben Agenten, nur mit dem Flag server = false.
Nach diesem Schritt erhalten die Clients eine Liste von P2P-Verbindungen und bauen untereinander Verbindungen auf.
Auf globaler Ebene verbinden wir mehrere Rechenzentren miteinander. Diese verbinden sich ebenfalls P2P und kommunizieren.
Wenn wir Daten von einem anderen Rechenzentrum abrufen möchten, geht die Anfrage von Server zu Server. Dieses Schema wird genannt Serf-Protokoll. Das Serf-Protokoll, wie auch Consul, ist eine Entwicklung von HashiCorp.
Einige wichtige Fakten über Consul
Consul hat eine Dokumentation, die seine Funktionsweise beschreibt. Ich werde nur einige ausgewählte Fakten anführen, die man wissen sollte.
Consul-Server wählen einen Master aus den abstimmenden. Consul wählt für jedes Rechenzentrum einen Master aus der Liste der Server, und alle Anfragen gehen nur an ihn, unabhängig von der Anzahl der Server. Ein Hänger des Masters führt nicht zu Neuwahlen. Wenn kein Master gewählt ist, werden keine Anfragen bearbeitet.
Wollten Sie horizontale Skalierung? Tut mir leid, nein.
Anfrage an ein anderes Rechenzentrum erfolgt von Master zu Master, unabhängig von dem Server, an den sie gesendet wurde. Der ausgewählte Master erhält 100% der Last, abgesehen von der Last der Weiterleitungsanfragen. Eine aktuelle Kopie der Daten befindet sich auf allen Servern des Rechenzentrums, aber nur einer antwortet.
Der einzige Weg zur Skalierung ist die Aktivierung des Stale-Modus auf dem Client.
Im Stale-Modus kann ohne Quorum geantwortet werden. Dies ist der Modus, in dem wir auf Konsistenz der Daten verzichten, aber etwas schneller lesen als gewöhnlich, und jeder Server antwortet. Natürlich erfolgt die Aufnahme nur über den Master.
Consul kopiert keine Daten zwischen den Rechenzentren. Bei der Zusammenstellung einer Föderation hat jeder Server nur seine eigenen Daten. Für andere wendet er sich immer an jemand anderen.
Die Atomarität von Operationen kann außerhalb von Transaktionen nicht gewährleistet werden. Denken Sie daran, dass nicht nur Sie etwas ändern können. Wenn Sie es anders möchten, führen Sie eine Transaktion mit Sperre durch.
Blockierende Operationen garantieren keine Sperren. Die Anfrage geht von Master zu Master und nicht direkt, daher gibt es keine Garantien, dass die Sperre funktioniert, wenn Sie sie z.B. in einem anderen Rechenzentrum durchführen.
ACL garantiert ebenfalls keinen Zugriff (in vielen Fällen). ACL könnte nicht funktionieren, weil sie in einem der Rechenzentren der Föderation gespeichert wird — im ACL-Rechenzentrum (Primär-DC). Wenn das DC Ihnen nicht antwortet, wird die ACL nicht funktionieren.
Ein hängender Master führt zu einem Hängen der gesamten Föderation. Zum Beispiel sind in einer Föderation 10 Rechenzentren, und eines hat ein schlechtes Netzwerk, und ein Master fällt aus. Alle, die mit ihm kommunizieren, hängen im Kreis: Es wird eine Anfrage gesendet, es gibt keine Antwort, der Thread hängt. Es wird nicht möglich sein, herauszufinden, wann dies passiert; einfach nach einer Stunde oder zwei wird die gesamte Föderation ausfallen. Sie werden nichts dagegen tun können.
Status, Quorum und Wahlen werden von einem separaten Thread verarbeitet. Es wird keine Neuwahlen geben, der Status wird nichts zeigen. Sie denken, dass Sie einen aktiven Consul haben, fragen nach, und es passiert nichts — keine Antwort. Dabei zeigt der Status, dass alles in Ordnung ist.
Wir sind auf dieses Problem gestoßen, wir mussten bestimmte Teile der Rechenzentren neu gestalten, um es zu vermeiden.
In der Business-Version von Consul Enterprise fehlen einige der oben genannten Nachteile.. Es gibt viele nützliche Funktionen: Auswahl der Abstimmenden, Verteilung, Skalierung. Es gibt nur ein „Aber“ – das Lizenzierungssystem für das verteilte System ist sehr teuer.
Lifehack: rm -rf /var/lib/consul – das Heilmittel für alle Probleme des Agents. Wenn bei Ihnen etwas nicht funktioniert, löschen Sie einfach Ihre Daten und laden Sie die Daten aus einer Kopie hoch. Höchstwahrscheinlich wird Consul wieder funktionieren.
BEFW
Lassen Sie uns nun darüber sprechen, was wir zu Consul hinzugefügt haben.
– das ist ein Akronym für BackEndFireWall. Ich musste dem Produkt irgendwie einen Namen geben, als ich das Repository erstellt habe, um die ersten Test-Commits abzulegen. Dieser Name ist geblieben.
Regelvorlagen
Die Regeln sind im iptables-Syntax geschrieben.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Alles läuft in die BEFW-Kette, außer ESTABLISHED, RELATED und localhost. Die Vorlage kann beliebig sein, das ist nur ein Beispiel.
Was ist nützlich an BEFW?
Dienste
Wir haben einen Dienst, der immer einen Port hat, und einen Knoten, auf dem er arbeitet. Von unserem Knoten aus können wir lokal den Agenten fragen und herausfinden, dass wir einen Dienst haben. Wir können auch Tags setzen.
Jeder Dienst, der läuft und in Consul registriert ist, wird zu einer iptables-Regel. Wir haben SSH – wir öffnen Port 22. Das Bash-Skript ist einfach: curl und iptables, mehr braucht man nicht.
Clients
Wie gewähren wir keinen allgemein, sondern selektiv Zugriff? Nach dem Dienstnamen IP-Listen im KV-Speicher ablegen.
Zum Beispiel möchten wir, dass alle aus dem zehnten Netzwerk auf den Dienst SSH_TCP_22 zugreifen können. Wir fügen ein kleines Feld TTL? hinzu und jetzt haben wir zeitlich begrenzte Berechtigungen, zum Beispiel für einen Tag.
Zugriffe
Wir verbinden Dienste und Clients: wir haben einen Dienst, für jeden ist ein KV-Speicher bereit. Jetzt gewähren wir den Zugriff nicht für alle, sondern selektiv.
Gruppen
Wenn wir jedes Mal tausende IP für Zugriffe angeben, werden wir müde. Lassen Sie uns Gruppierungen erfinden – einen separaten Subset im KV. Wir nennen ihn Alias (oder Gruppen) und speichern dort Gruppen nach dem gleichen Prinzip.
Verknüpfen: jetzt können wir SSH nicht spezifisch auf P2P öffnen, sondern auf eine ganze Gruppe oder mehrere Gruppen. Ebenso gibt es TTL – man kann temporär in die Gruppe aufnehmen oder aus der Gruppe entfernen.
Integration
Unser Problem – der menschliche Faktor und die Automatisierung. Bisher haben wir es so gelöst.
Wir arbeiten mit Puppet und übertragen alles, was mit dem System (Anwendungscode) zu tun hat. In puppetdb (normaler PostgreSQL) wird eine Liste der dort laufenden Dienste gespeichert, die nach Ressourcentyp gefunden werden kann. Hier kann man auch sehen, wer wo Anfragen stellt. Außerdem haben wir ein System für Pull-Requests und Merge-Requests dafür.
Wir haben befw-sync geschrieben – eine einfache Lösung, die hilft, Daten zu übertragen. Zuerst wenden sich Sync-Cookies an puppetdb. Dort ist eine HTTP-API eingerichtet: Wir fragen, welche Dienste wir haben, was zu tun ist. Dann stellen sie eine Anfrage an Consul.
Gibt es eine Integration? Ja: Wir haben Regeln geschrieben und erlaubt, Pull-Requests anzunehmen. Wird ein Port benötigt oder soll ein Host zu einer Gruppe hinzugefügt werden? Pull-Request, Überprüfung – keine weiteren "Finde 200 andere ACLs und versuche, etwas damit zu machen".
Optimierung
Ein Ping an localhost mit einer leeren Regelkette dauert 0,075 ms.
Wir fügen dieser Kette 10.000 Adressen von iptables hinzu. Infolgedessen erhöht sich der Ping um das 5-fache: iptables ist vollständig linear, die Verarbeitung jeder Adresse benötigt einige Zeit.
Für die Firewall, in die wir tausende von ACLs migrieren, haben wir viele Regeln, und das verursacht Verzögerungen. Für Spielerprotokolle ist das schlecht.
Aber wenn wir 10.000 Adressen in ipset bringen, wird der Ping sogar geringer.
Der Sinn ist, dass "O" (Algorithmuskomplexität) für ipset immer 1 ist, egal wie viele Regeln es gibt. Allerdings gibt es eine Einschränkung – es können nicht mehr als 65535 Regeln sein. Damit leben wir vorerst: Man kann sie kombinieren, erweitern, zwei ipsets in einem erstellen.
Speicherung
Eine logische Fortsetzung des Iterationsprozesses ist die Speicherung von Informationen über Clients für den Dienst in ipset.
Jetzt haben wir dasselbe SSH, und wir schreiben nicht sofort 100 IPs, sondern geben den Namen des ipsets an, mit dem wir kommunizieren müssen, und die nächste Regel DROP. Man kann es in eine Regel umformen: "Wer nicht hier ist, der wird DROP", aber so ist es anschaulicher.
Jetzt haben wir Regeln und Sets. Die Hauptaufgabe besteht darin, ein Set zu erstellen, bevor man eine Regel schreibt, denn sonst wird iptables die Regel nicht speichern.
Das allgemeine Schema
In Form eines Schemas sieht alles, was ich erzählt habe, so aus.
Wir comitten in Puppet, alles wird an den Host gesendet, die Dienste hier, ipset dort, und wer dort nicht eingetragen ist, wird nicht hineingelassen.
Erlauben & Verwehren
Um die Welt schnell zu retten oder jemand schnell abzuschalten, haben wir zu Beginn aller Ketten zwei ipsets erstellt: rules_allow und rules_deny. Wie funktioniert das?
Zum Beispiel erzeugt jemand mit Bots eine Belastung für unser Web. Früher musste man seine IP in den Logs finden, zu den Netzwerkingenieuren bringen, damit sie die Quelle des Traffics finden und sie sperren. Heute sieht das anders aus.
Wir senden es an Consul, warten 2,5 Sekunden und sind bereit. Da Consul über P2P schnell verteilt, funktioniert es überall, in jedem Teil der Welt.
Einmal habe ich WOT komplett angehalten, weil ich einen Fehler mit der Firewall gemacht habe. rules_allow — das ist unsere Versicherung gegen solche Fälle. Wenn wir irgendwo einen Fehler mit der Firewall gemacht haben und etwas irgendwo blockiert wird, können wir immer bedingt 0.0/0, um alles schnell wieder hochzufahren. Danach reparieren wir alles per Hand.
Andere Sets
Man kann beliebige andere Sets im Bereich hinzufügen $IPSETS$.
Warum? Manchmal benötigt jemand ipset, beispielsweise um das Abschalten eines Teils des Clusters zu emulieren. Jeder kann beliebige Sets mitbringen, sie benennen und sie werden aus Consul abgerufen. Dabei können die Sets sowohl an den iptables-Regeln teilnehmen, als auch wie eine Art NOOP: Die Konsistenz wird durch den Daemon sichergestellt.
Benutzer
Früher war es so: Der Benutzer schaute sich mit einem Domännamen in das Netzwerk ein und erhielt Parameter. Bis zur Einführung der neuen Generation von Firewalls konnte Cisco nicht verstehen, wo der Benutzer war und wo die IP war. Daher wurde der Zugriff nur über den Hostnamen der Maschine gewährt.
Was haben wir gemacht? Wir haben uns in den Moment eingeschaltet, in dem die Adresse abgerufen wird. In der Regel geschieht dies über dot1x, Wi-Fi oder VPN — alles läuft über RADIUS. Für jeden Benutzer erstellen wir eine Gruppe mit dem Benutzernamen und fügen die IP mit TTL hinzu, die gleich seiner dhcp.lease ist — sobald diese abläuft, verschwindet die Regel.
Jetzt können wir den Zugang zu Dienstleistungen wie in andere Gruppen nach Benutzernamen öffnen. Wir haben die Probleme mit Hostnames beseitigt, wenn sie sich ändern, und die Last von den Netzwerkingenieuren genommen, da sie jetzt keine Cisco mehr benötigen. Jetzt tragen die Ingenieure selbst die Zugänge auf ihren Servern ein.
Isolierung
Parallel dazu haben wir begonnen, die Isolierung zu überprüfen. Die Service-Manager haben eine Inventur erstellt und wir haben alle unsere Netzwerke analysiert. Wir gruppieren sie in ähnliche Gruppen und haben auf den benötigten Servern diese Gruppen, zum Beispiel, in deny hinzugefügt. Jetzt gelangt dieselbe Staging-Isolierung in rules_deny der Produktion, aber nicht in die eigentliche Produktion.
Das Schema funktioniert schnell und einfach: Wir entfernen alle ACLs von den Servern, entlasten die Hardware und verringern die Anzahl der isolierten VLANs.
Integritätskontrolle
Früher hatten wir einen speziellen Trigger, der meldete, wenn jemand manuell die Firewall-Regeln änderte. Ich schrieb einen riesigen Linter zur Überprüfung der Firewall-Regeln, das war kompliziert. Jetzt wird die Integrität von BEFW überwacht. Er achtet darauf, dass die Regeln, die er erstellt, nicht geändert werden. Wenn jemand die Firewall-Regeln ändert, wird alles zurückgesetzt. „Ich habe hier schnell einen Proxy eingerichtet, um von zu Hause aus zu arbeiten“ — solche Möglichkeiten gibt es nicht mehr.
BEFW überwacht die ipset aus den Diensten und der Liste in befw.conf, die Regeln der Dienste in der BEFW-Kette. Aber er überwacht keine anderen Ketten oder Regeln und andere ipsets.
Schutz vor Ausfällen
BEFW speichert immer den letzten erfolgreichen Zustand direkt in der Binärdatei state.bin. Wenn etwas schiefgeht, springt er immer auf diesen state.bin zurück.
Das ist eine Versicherung gegen instabile Arbeiten von Consul, wenn er keine Daten sendet oder jemand einen Fehler macht und Regeln verwendet, die nicht angewendet werden können. Damit wir nicht ohne Firewall dastehen, wird BEFW auf den letzten Zustand zurückgesetzt, wenn an irgendeinem Punkt ein Fehler auftritt.
In kritischen Situationen ist dies die Garantie, dass wir mit einer funktionierenden Firewall bleiben. Wir öffnen alle grauen Netzwerke in der Hoffnung, dass der Admin kommt und es repariert. Irgendwann werde ich das in die Konfigurationen bringen, aber jetzt haben wir einfach drei graue Netze: 10/8, 172/12 und 192.168/16. Im Rahmen unseres Consul ist dies eine wichtige Eigenschaft, die hilft, weiterzuentwickeln.
Demo: Während des Vortrags zeigt Ivan den Demomodus von BEFW. Die Demonstration lässt sich am besten anschauen unter . Der Quellcode der Demo ist verfügbar .
Herausforderungen
Ich werde über die Fehler sprechen, mit denen wir konfrontiert waren.
ipset add set 0.0.0.0/0. Was passiert, wenn Sie 0.0.0.0/0 in ipset hinzufügen? Werden alle IPs hinzugefügt? Wird der Zugang zum Internet geöffnet?
Nein, wir bekommen einen Fehler, der uns zwei Stunden Ausfall gekostet hat. Der Fehler besteht seit 2016 und liegt in der RedHat Bugzilla unter der Nummer #1297092. Wir haben ihn zufällig entdeckt — aus dem Bericht eines Entwicklers.
Jetzt gibt es in BEFW eine strenge Regel, dass 0.0.0.0/0 in zwei Adressen umgewandelt wird: 0.0.0.0/1 und 128.0.0.0/1.
ipset restore set < file. Was macht ipset, wenn Sie ihm sagen restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Nichts dergleichen — er führt einen Merge durch, und die alten Adressen verschwinden nicht, Sie schließen keinen Zugang.
Den Fehler haben wir gefunden, als wir die Isolierung getestet haben. Jetzt gibt es dort ein ziemlich komplexes System — anstelle von restore wird durchgeführt create temp, dann restore flush temp und restore temp. Am Ende swap: für Atomarität, denn wenn Sie zuerst flush Und in diesem Moment kommt ein Paket, das zurückgewiesen wird und etwas wird schiefgehen. Deshalb gibt es ein wenig schwarze Magie da.
consul kv get -datacenter=other. Wie ich bereits gesagt habe, denken wir, dass wir einige Daten anfragen, aber entweder Daten oder einen Fehler erhalten. Wir können das lokal über Consul tun, aber auch in diesem Fall wird beides hängen bleiben.
Der lokale Consul-Client ist eine Wrapper über das HTTP-API. Aber er hängt einfach und reagiert nicht auf Ctrl+C, Ctrl+Z oder irgendetwas, nur auf kill -9 in der benachbarten Konsole. Wir haben damit zu kämpfen gehabt, als wir ein großes Cluster aufgebaut haben. Aber bisher haben wir keine Lösung, wir bereiten uns vor, diesen Fehler im Consul zu beheben.
Der Consul-Leiter antwortet nicht. Unser Master im Rechenzentrum antwortet nicht, wir denken: „Wird der Wahlalgorithmus jetzt wahrscheinlich funktionieren?“
Nein, wird es nicht, und das Monitoring wird nichts anzeigen: Consul sagt, dass der Commitment-Index vorhanden ist, der Leiter gefunden wurde, alles ist in Ordnung.
Wie gehen wir damit um? service consul restart in cron jede Stunde. Wenn Sie 50 Server haben, ist das nicht so schlimm. Wenn es 16.000 werden, werden Sie verstehen, wie das funktioniert.
Fazit
Letztendlich haben wir folgende Vorteile erhalten:
- 100% Abdeckung aller Linux-Maschinen.
- Geschwindigkeit.
- Automatisierung.
- Wir haben die Hardware und die Netzwerkingenieure von der Knechtschaft befreit.
- Es gibt nahezu unbegrenzte Integrationsmöglichkeiten: sei es mit Kubernetes, Ansible oder Python.
Nachteile: Consul, mit dem wir jetzt leben müssen, und der Preis für Fehler ist sehr hoch. Zum Beispiel, einmal um 18 Uhr (Peak in Russland) habe ich etwas in den Netzlisten geändert. Wir haben gerade Isolation auf BEFW aufgebaut. Ich habe irgendwo einen Fehler gemacht, wahrscheinlich die falsche Maske angegeben, und in zwei Sekunden war alles weg. Das Monitoring geht an, der Support ist da: „Bei uns liegt alles!“ Der Abteilungsleiter wurde grau, als er dem Management erklärte, warum das passiert ist.
Der Preis für einen Fehler ist so hoch, dass wir ein eigenes komplexes Präventionsverfahren entwickelt haben. Wenn Sie dies in einer großen Produktion einführen wollen, sollten Sie nicht allen einfach so einen Master-Token über Consul geben. Das endet schlecht.
Kosten. Ich habe 400 Stunden lang allein programmiert. Für die Unterstützung benötigt mein Team von 4 Personen 10 Stunden im Monat für alle. Im Vergleich zu den Kosten einer neuen Generation von Firewalls ist das kostenlos.
Pläne. Der langfristige Plan ist die Suche nach einem alternativen Transportmittel zusätzlich oder anstelle von Consul. Vielleicht wird es Kafka oder etwas Ähnliches sein. Aber in den nächsten Jahren werden wir mit Consul leben.
Nächste Pläne: Integration mit Fail2ban, mit Monitoring, mit nftables, möglicherweise mit anderen Distributionen, Metriken, erweiterte Überwachung, Optimierung. Unterstützung für Kubernetes steht ebenfalls in den Plänen, da wir derzeit mehrere Cluster und ein gewisses Interesse haben.
Weitere Pläne:
- Anomalien im Datenverkehr suchen;
- Netzwerkkartenverwaltung;
- Unterstützung für Kubernetes;
- Paketerstellung für alle Systeme;
- Web-UI.
Wir arbeiten ständig an der Erweiterung der Konfiguration, der Erhöhung der Metriken und der Optimierung.
Schließt euch dem Projekt an. Das Projekt ist großartig geworden, aber leider ist es bisher ein Projekt von einer Person. Kommt zu und versucht, etwas zu machen: committen, testen, Vorschläge machen, eure Meinung abgeben.
In der Zwischenzeit bereiten wir uns auf , der am 6. und 7. April in St. Petersburg stattfindet, und laden Entwickler hochbelasteter Systeme ein, . Erfahrene Sprecher wissen bereits, was zu tun ist, und für Anfänger empfehlen wir zumindest, . Die Teilnahme an der Konferenz als Sprecher hat einige Vorteile. Welche, kann man beispielsweise am Ende nachlesen. .
Quelle: habr.com
