Hat mich zu diesem Beitrag inspiriert. .
Ich führe ihn hier an:
heute um 18:53
Heute hat mich der Anbieter erfreut. Zusammen mit dem Update des Systems zur Blockierung von Websites wurde auch der E-Mail-Dienst mail.ru gesperrt. Ich habe morgens den Support kontaktiert, aber sie können nichts tun. Der Anbieter ist klein, und anscheinend blockieren die übergeordneten Anbieter. Ich habe außerdem eine Verlangsamung beim Laden aller Websites bemerkt, vielleicht haben sie irgendein fehlerhaftes DLP-System installiert? Früher gab es keine Zugangsprobleme. Die Zerschlagung des RuNet geschieht direkt vor meinen Augen...
Das Problem ist, dass wir anscheinend der besagte Anbieter sind 🙁
Und tatsächlich, ich habe fast den Grund für die Probleme mit mail.ru erraten (obwohl wir lange nicht glauben wollten, dass es so ist).
Der weitere Verlauf wird in zwei Teile unterteilt:
- die Gründe für unsere heutigen Probleme mit mail.ru und eine spannende Suche danach.
- die Existenz von ISPs in der heutigen Realität, die Stabilität des souveränen RuNet.
Probleme mit der Verfügbarkeit von mail.ru.
Oh, das ist eine ziemlich lange Geschichte.
Der Grund liegt darin, dass wir zur Erfüllung der Anforderungen des Staates (mehr dazu im zweiten Teil) bestimmte Hardware angeschafft, konfiguriert und installiert haben – sowohl zur Filterung unerlaubter Ressourcen als auch zur Durchführung von der Nutzer.
Vor einiger Zeit haben wir das Kernnetz so umgebaut, dass der gesamte Datenverkehr der Nutzer über diese Hardware in die gewünschte Richtung geleitet wird.
Vor einigen Tagen haben wir die Filterung unerlaubter Inhalte aktiviert (während das alte System weiterhin läuft) – äußerlich lief alles gut.
Anschließend haben wir schrittweise für verschiedene Nutzergruppen NAT auf dieser Hardware aktiviert. Auch hier schien alles zunächst gut zu funktionieren.
Doch heute, nachdem wir NAT für eine weitere Gruppe von Nutzern aktiviert hatten, erhielten wir bereits am Morgen eine Vielzahl an Beschwerden über unerreichbare oder teilweise erreichbare und andere Ressourcen der Mail.Ru Group.
Wir begannen zu überprüfen: Irgendetwas sendet manchmal, gelegentlich TCP RST In Reaktion auf Anfragen, die ausschließlich an die Netzwerke von mail.ru gerichtet sind. Darüber hinaus wird ein offensichtlich künstlicher TCP RST, der ohne ACK generiert wurde, gesendet. So sah das ungefähr aus:
Natürlich dachte ich zuerst an die neue Hardware: ein schrecklicher DPI, kein Vertrauen in ihn, wer weiß, was er anrichten könnte – schließlich ist TCP RST ein recht gängiger Mechanismus bei Blockierungswerkzeugen.
Vermutung dass jemand 'oberhalb' filtert, hatten wir ebenfalls geäußert – aber sofort wieder verworfen.
Erstens haben wir ausreichend vernünftige Up-Links, um nicht davon betroffen zu sein 🙂
Zweitens sind wir mit mehreren in Moskau verbunden, und der Traffic zu mail.ru läuft genau über diese – sie haben weder Verpflichtungen noch irgendeinen anderen Anreiz, den Traffic zu filtern.
Die nächste Hälfte des Tages wurde mit dem verbracht, was man normalerweise Schamanismus nennt – zusammen mit dem Hardwareanbieter, wofür wir ihnen danken, haben sie uns nicht im Stich gelassen 🙂
- die Filterung wurde vollständig deaktiviert
- NAT wurde nach einem neuen Schema deaktiviert
- der Test-PC wurde in einen separaten isolierten Pool gebracht
- die IP-Adressierung wurde geändert
Am Nachmittag wurde eine VM bereitgestellt, die über das Schema eines normalen Nutzers ins Netz ging, und zu ihr sowie zur Hardware hatten die Vertreter des Anbieters Zugang. Der Schamanismus ging weiter 🙂
Letztendlich erklärte der Vertreter des Anbieters mit Nachdruck, dass die Hardware ganz sicher nicht das Problem ist: Die RST-Pakete kommen irgendwoher von weiter oben.
HinweisAn dieser Stelle könnte jemand sagen: Es wäre doch viel einfacher gewesen, ein Dump nicht vom Test-PC, sondern von der Leitung oberhalb des DPI zu machen?
Nein, leider ist es nicht trivial, einen Dump (und selbst einfach nur zu mirrorn) von 40+ gbps zu erstellen.
Nach diesem Abend blieb uns nichts anderes übrig, als zur Annahme zurückzukehren, dass es irgendwo weiter oben eine merkwürdige Filterung gibt.
Ich habe geschaut, über welchen IX der Traffic jetzt zu den MRG-Netzwerken geht und einfach die BGP-Sitzungen zu ihm deaktiviert. Und – oh Wunder! – alles normalisierte sich sofort 🙁.
Einerseits ist es sehr schade, dass wir den ganzen Tag mit der Problemlösung verbracht haben, obwohl sie sich in fünf Minuten lösen ließ.
Andererseits:
– nach meinem Gedächtnis ist das eine beispiellose Sache. Wie ich zuvor erwähnt habe – bei den IX gibt es wirklich keinen Sinn, den Transit-Traffic zu filtern. Normalerweise haben sie Hunderte von Gigabits/Terabits pro Sekunde. Bis zuletzt konnte ich mir so etwas einfach nicht ernsthaft vorstellen.
— eine unglaublich günstige Wendung der Umstände: neue, komplexe Hardware, der man wenig vertraut und von der man nicht weiß, was man erwarten kann — exakt abgestimmt auf die Blockade von Ressourcen, einschließlich TCP RST.
Momentan sucht das NOC dieses Internet Exchanges nach dem Problem. Ihrer Aussage nach (und ich glaube ihnen) haben sie kein spezielles Filtersystem eingerichtet. Doch, dank des Himmels, ist die nächste Herausforderung — nicht mehr unser Problem 🙂.
Das war ein kleiner Versuch, sich zu rechtfertigen, wir bitten um Verständnis und Verzeihung 🙂.
P.S.: Ich nenne absichtlich weder den Hersteller von DPI/NAT noch den IX (ich habe im Grunde keine besonderen Beschwerden gegen sie, das Wichtigste ist zu verstehen, was passiert ist).
Die heutige (sowie die gestrige und vorgestern) Realität aus der Sicht eines Internetanbieters.
Die letzten Wochen habe ich damit verbracht, das Kernnetzwerk erheblich umzubauen und eine Menge Manipulationen „live“ durchzuführen, mit dem Risiko, den laufenden Benutzerdatenverkehr erheblich zu beeinträchtigen. Angesichts der Ziele, Ergebnisse und Konsequenzen all dies — ist es moralisch ziemlich belastend. Besonders — wieder einmal den idealistischen Reden über den Schutz der Stabilität des russischen Internets, der Souveränität usw. zuzuhören.
In diesem Abschnitt möchte ich über die "Entwicklung" des Netzwerkkerns eines typischen Internetanbieters in den letzten zehn Jahren sprechen.
Vor einem Jahrzehnt.
In diesen segensreichen Zeiten konnte der Kern des Anbieter-Netzwerks so einfach und zuverlässig sein wie ein Korken:
Auf diesem sehr stark vereinfachten Bild fehlen Autobahnen, Ringe, IP/MPLS-Routing.
Die Essenz war, dass der Nutzertraffic letztendlich in die Kernschaltung gelangte – von wo er weiterging nach , von wo aus er in der Regel zurück zur Kerngestaltung und dann "nach draußen" – durch einen oder mehrere Border Gateways ins Internet.
Ein solches Schema lässt sich sehr einfach sowohl auf L3 (dynamisches Routing) als auch auf L2 (MPLS) redundieren.
Man kann N+1 von allem einrichten: Zugangserver, Switches, Border-Gateways – und diese irgendwie für automatisches Failover redundieren.
Nach einigen Jahren wurde allen in Russland klar, dass es so nicht weitergehen kann: Es ist dringend notwendig, die Kinder vor dem schädlichen Einfluss des Netztes zu schützen.
Es entstand die Notwendigkeit, dringend Möglichkeiten zur Filterung des Nutzertraffics zu finden.
Es gibt verschiedene Ansätze.
Im weniger günstigen Fall wird etwas „quer“ installiert: zwischen dem Benutzertreffen und dem Internet. Der darüberlaufende Traffic wird analysiert und beispielsweise wird ein gefälschtes Paket mit einer Umleitung an den Abonnenten gesendet.
Im etwas besseren Fall — wenn das Datenvolumen es zulässt — kann man einen kleinen Trick anwenden: Nur den ausgehenden Traffic von Benutzern an die Adressen zu filtern, die gefiltert werden müssen (dazu kann man entweder die dort angegebenen IP-Adressen aus dem Register verwenden oder die vorhandenen Domains im Register zusätzlich auflösen).
Zu diesem Zweck habe ich damals einen einfachen geschrieben — obwohl man sich nicht trauen würde, es so zu nennen. Er ist sehr einfach und nicht sehr leistungsfähig — jedoch hat er uns und Dutzenden (wenn nicht Hunderten) anderen Anbietern ermöglicht, nicht sofort Millionen in industrielle DPI-Systeme zu investieren, sondern uns einige zusätzliche Jahre Zeit zu verschaffen.
Übrigens, über die damaligen und heutigen DPIÜbrigens haben viele, die zu diesem Zeitpunkt verfügbare DPI-Systeme erworben haben, diese bereits entsorgt. Sie sind einfach nicht dafür geeignet: Hunderte Tausende von Adressen, Zehntausende von URLs.
Gleichzeitig haben in diesem Markt heimische Hersteller enorm an Bedeutung gewonnen. Ich spreche nicht von der Hardware – das ist allgemein bekannt. Doch die Software, die das Herzstück der DPI ausmacht, ist heute, ob sie nun die fortschrittlichste der Welt ist oder nicht, a) entwickelt sich rasant, und b) im Vergleich zum Preis für vergleichbare ausländische Produkte einfach nicht zu schlagen.
Es wäre schön, stolz darauf zu sein, aber es ist ein wenig traurig =)
Nun sah alles so aus:
Noch ein paar Jahre später hatten bereits alle Überwachungsgeräte installiert; die Ressourcen im Register wurden immer zahlreicher. Für bestimmte ältere Geräte (z.B. Cisco 7600) war das Schema mit der "seitlichen Filterung" einfach nicht mehr anwendbar: Die Anzahl der Routen auf 76 Plattformen ist auf etwa neunhunderttausend beschränkt, während die Anzahl der IPv4-Routen mittlerweile fast die 800.000 erreicht. Und wenn man noch IPv6 hinzurechnet… Ach ja, und… wie viele sind es jetzt? 900.000 einzelne Adressen in der RKN-Sperrliste? =)
Einige Anbieter haben auf eine Methode umgestellt, bei der der gesamte Backbone-Verkehr auf einen Filterserver gespiegelt wird, der den gesamten Datenstrom analysieren soll. Bei der Entdeckung von Unregelmäßigkeiten sendet er RST-Pakete in beide Richtungen (an den Absender und den Empfänger).
Je mehr Verkehr jedoch generiert wird, desto weniger ist dieses Schema anwendbar. Bei der kleinsten Verzögerung in der Verarbeitung fliegt der gespiegelte Verkehr einfach unbemerkt ins Leere, und der Anbieter erhält eine Strafe.
Immer mehr Anbieter sehen sich gezwungen, DPI-Systeme verschiedener Zuverlässigkeitsgrade in die Backbone-Netze zu integrieren.
Vor ein oder zwei Jahren gab es Gerüchte, dass praktisch alle Anbieter der FSB die tatsächliche Installation von Geräten verlangen. (zuvor gaben die meisten Anbieter sich mit Genehmigungen durch die Behörden zufrieden) SORM-Plan (die operative Maßnahmen für den Fall festlegen, dass irgendwo etwas gefunden werden muss)
Neben finanziellen Aspekten (nicht gerade exorbitant, aber dennoch Millionen) forderte SORM von vielen zusätzliche Manipulationen im Netzwerk.
- SORMapparat muss die "grauen" IP-Adressen der Benutzer vor der NAT-Übersetzung erkennen.
- SORM hat eine begrenzte Anzahl von Netzwerkschnittstellen.
Deshalb mussten wir insbesondere einen großen Teil des Kernels umgestalten — nur um den Datenverkehr der Benutzer zu den Zugangsservern an einem Ort zu bündeln. Um es durch mehrere Verbindungen im SORM zu spiegeln.
Das heißt, stark vereinfacht, war es (links) vs. ist es geworden (rechts):
Jetzt verlangen die meisten Anbieter auch die Implementierung von SORM-3 — das unter anderem auch das Logging von NAT-Übersetzungen umfasst.
Zu diesem Zweck mussten wir in das oben dargestellte Schema zusätzlich separate Hardware für NAT integrieren (genau das, worum es im ersten Teil geht). Und das musste in einer bestimmten Reihenfolge hinzugefügt werden: da SORM den Datenverkehr vor der Adressübersetzung "sehen" muss — der Datenverkehr muss strikt folgendermaßen fließen: Benutzer -> Switching, Kern -> Zugangsserver -> SORM -> NAT -> Switching, Kern -> Internet. Dazu mussten wir buchstäblich die Verkehrsströme in die entgegengesetzte Richtung umleiten, was auch ziemlich schwierig war.
Insgesamt hat sich die Kernarchitektur eines durchschnittlichen Anbieters über ein Jahrzehnt stark verkompliziert, und die Anzahl zusätzlicher Ausfallstellen (sowohl durch Hardware als auch durch einheitliche Verbindungsleitungen) ist deutlich gestiegen. Das reinen Erfordernis, "alles zu sehen", impliziert die Zusammenführung all dieser "Alles" an einem Punkt.
Ich denke, dass dies durchaus transparent auf die aktuellen Initiativen zur Souveränität des russischen Internets, dessen Schutz, Stabilisierung und Verbesserung extrapoliert werden kann 🙂.
Und vor uns steht noch Jarowaja.
Quelle: habr.com
