Ausführliche Antwort auf den Kommentar sowie ein wenig über das Leben der Anbieter in der Russischen Föderation

Das hat mich zu diesem Beitrag inspiriert dieser Kommentar hier.

Ich bringe ihn hier:

kaleman heute um 18:53

Heute hat mich der Anbieter erfreut. Zusammen mit dem Update des Systems zur Sperrung von Websites wurde der Mailanbieter mail.ru blockiert. Ich habe den Support den ganzen Morgen kontaktiert, sie können nichts tun. Der Anbieter ist klein und wird offenbar von übergeordneten Anbietern blockiert. Ich habe auch eine Verlangsamung beim Öffnen aller Websites bemerkt; vielleicht wurde ein fehlerhaftes DLP-System installiert? Früher gab es keine Probleme mit dem Zugriff. Die Zerstörung des Runets geschieht direkt vor meinen Augen...

Die Sache ist die, dass wir anscheinend genau dieser Anbieter sind 🙁

Und tatsächlich, kaleman hatte ich fast die richtige Vermutung für die Probleme mit mail.ru (obwohl wir lange Zeit nicht daran glauben wollten).

Das Weitere wird in zwei Teile gegliedert:

1. die Gründe für unsere heutigen Probleme mit mail.ru und eine spannende Schatzsuche zu deren Auffindung
2. die Existenz von ISPs in der heutigen Realität, die Stabilität des souveränen Runets.

Zugänglichkeit Probleme mit mail.ru

Oh, das ist eine ziemlich lange Geschichte.

Die Sache ist die, dass wir zur Erfüllung der Anforderungen des Staates (nähere Informationen im zweiten Teil) einige Geräte angeschafft, konfiguriert und installiert haben — sowohl zur Filterung von gesperrten Ressourcen als auch zur Durchführung von NAT-Übersetzungen für Abonnenten.

Vor einiger Zeit haben wir endlich das Kernnetz so umgebaut, dass der gesamte Traffic der Abonnenten durch diese Geräte strikt in die richtige Richtung geleitet wird.

Vor einigen Tagen haben wir die Filterung der Sperrung auf diesen Geräten aktiviert (während wir gleichzeitig das alte System weiterbetrieben haben) — anfangs schien alles gut zu laufen.

Danach haben wir schrittweise für verschiedene Teile der Abonnenten NAT auf diesem Gerät aktiviert. Scheinbar lief auch das ganz gut.

Aber heute, als wir NAT für einen weiteren Teil der Abonnenten auf dem Gerät aktiviert haben — hatten wir seit dem Morgen eine Reihe von Beschwerden über die Nichterreichbarkeit oder teilweise Nichterreichbarkeit von mail.ru und anderen Ressourcen der Mail Ru Group.

Wir haben begonnen zu überprüfen: Irgendetwas schickt manchmal, gelegentlich TCP RST als Antwort auf Anfragen ausschließlich an die Netzwerke von mail.ru. Darüber hinaus — wird ein falsch generiertes (ohne ACK), offensichtlich künstliches TCP RST geschickt. So sah es ungefähr aus: Natürlich lagen unsere ersten Gedanken beim neuen Gerät: schreckliches DPI, kein Vertrauen in es, wer weiß, was es anstellen könnte — denn TCP RST ist eine ziemlich gängige Sache bei Blockierungsmaßnahmen.

Natürlich waren die ersten Gedanken an neue Ausrüstung gerichtet: schrecklicher DPI, kein Vertrauen in ihn, wer weiß, was er anstellen kann – denn TCP RST ist eine ziemlich verbreitete Sache unter Blockierungsinstrumenten.

Vermutung kaleman darüber, dass jemand "übergeordnetes" filtert, haben wir ebenfalls geäußert – haben es aber sofort verworfen.

Erstens haben wir ausreichend vernünftige Uploads, um unter solchen Bedingungen nicht zu leiden 🙂

Zweitens sind wir mit mehreren IX in Moskau verbunden, und der Verkehr zu mail.ru läuft genau über diese — und sie haben weder Pflichten noch irgendeinen anderen Grund, den Verkehr zu filtern.

Die nächste Hälfte des Tages wurde damit verbracht, was normalerweise als Schamanismus bezeichnet wird – zusammen mit dem Hardwareanbieter, wofür ich ihnen danke, haben wir nicht aufgegeben 🙂

• Die Filterung wurde komplett deaktiviert
• NAT wurde nach dem neuen Schema abgeschaltet
• Der Test-PC wurde in einen separaten isolierten Pool verschoben
• Die IP-Adressierung wurde geändert

Am Nachmittag wurde eine virtuelle Maschine выделена, die mit dem Netzwerk wie ein normaler Benutzer verbunden ist, und sowohl diese als auch die Hardware wurden den Vertretern des Anbieters zugänglich gemacht. Der Schamanismus ging weiter 🙂

Letztendlich erklärte der Vertreter des Anbieters überzeugt, dass die Hardware ganz sicher nicht das Problem ist: Die rst'ys kommen irgendwo her.

HinweisAn dieser Stelle könnte jemand sagen: Aber es wäre viel einfacher gewesen, ein Dump nicht vom Test-PC, sondern von der Leitung oberhalb des DPI zu nehmen?

Nein, leider ist es alles andere als trivial, einen Dump (und sogar einfach nur zu mirrorisieren) mit 40+gbps zu machen.

Nachdem es bereits Abend wurde, blieb uns nichts anderes übrig, als zur Vermutung über eine seltsame Filterung irgendwo höher zurückzukehren.

Ich habe mir angeschaut, über welchen IX der Verkehr derzeit zu den MRG-Netzen läuft, und habe einfach die bgp-Sitzungen zu ihm deaktiviert. Und – oh Wunder! – alles normalisierte sich sofort 🙁

Einerseits ist es sehr schade, dass der gesamte Tag für die Fehlersuche aufgewendet wurde, obwohl sie in fünf Minuten gelöst werden konnte.

Andererseits:

– meines Wissens ist das eine beispiellose Sache. Wie ich oben geschrieben habe – für IX's tatsächlich macht es keinen Sinn, Transitverkehr zu filtern. Normalerweise haben sie hunderte Gigabit / Terabits pro Sekunde. Ich konnte mir bis zuletzt nicht ernsthaft vorstellen, dass so etwas möglich ist.

– eine unglaublich glückliche Fügung: neue komplexe Hardware, der man nicht besonders vertraut und von der man nicht weiß, was man erwarten kann – speziell ausgelegt zur Blockierung von Ressourcen, einschließlich TCP RST's

Im Moment sucht NOC dieses Internet-Exchanges nach dem Problem. Nach deren Aussage (und ich glaube ihnen) haben sie kein speziell eingerichtetes Filtersystem. Aber, danken wir dem Himmel, die weitere Suche ist schon nicht mehr unser Problem 🙂

Es war ein kleiner Versuch, sich zu rechtfertigen, wir bitten um Verständnis und Vergebung 🙂

P.S.: Ich nenne absichtlich weder den Hersteller DPI/NAT noch IX (ich habe eigentlich keine speziellen Beschwerden über sie, das Wichtigste ist zu verstehen, was passiert ist)

Die heutige (sowie die gestrige und vorgestrige) Realität aus der Sicht eines Internetanbieters

Die letzten Wochen habe ich damit verbracht, das Netzwerk-Kernsystem erheblich umzugestalten, dabei viele Operationen „live“ durchzuführen, mit dem Risiko, den echten Benutzerdatenverkehr erheblich zu beeinflussen. Angesichts der Ziele, Ergebnisse und Folgen all dessen ist es moralisch ziemlich belastend. Besonders, wenn man erneut die schönen Reden über den Schutz der Stabilität des Runet, Souveränität usw. anhört.

In diesem Abschnitt werde ich versuchen, die „Evolution“ des Kernsystems eines typischen Internetanbieters in den letzten zehn Jahren zu beschreiben.

Vor zehn Jahren.

In diesen gesegneten Zeiten konnte das Kernsystem des Anbieternetzwerks so einfach und zuverlässig sein wie ein Korken:

Auf diesem sehr vereinfachten Bild fehlen die Hauptleitungen, Ringe, IP/MPLS-Routing.

Die Essenz besteht darin, dass der Datenverkehr der Benutzer letztendlich zur Kern-Switching-Ebene kam — von wo aus er zu BNG, von wo er in der Regel — zurück zur Kern-Switching-Ebene und dann „nach draußen“ — über einen oder mehrere Border Gateways ins Internet ging.

Ein solches Schema lässt sich sehr leicht sowohl auf L3 (dynamisches Routing) als auch auf L2 (MPLS) redundieren.

Man kann beliebig viele Server, Switches, Border-Elemente im N+1-Verfahren installieren und diese für einen automatischen Failover reservieren.

Nach einigen Jahren wurden allen in Russland klar, dass man so nicht weiterleben kann: Es ist dringend notwendig, Kinder vor dem schädlichen Einfluss des Internets zu schützen.

Es bestand die Notwendigkeit, dringend Möglichkeiten zu finden, den Benutzerverkehr zu filtern.

Hier gibt es verschiedene Ansätze.

Im nicht so guten Fall wird irgendetwas „quer“ geschaltet: zwischen dem Benutzertraffic und dem Internet. Der durch dieses „etwas“ fließende Traffic wird analysiert und beispielsweise wird ein gefälschtes Paket mit einer Umleitung an den Abonnenten gesendet.

Im besten Fall – vorausgesetzt, das Verkehrsvolumen erlaubt es – kann man einen kleinen Trick anwenden: Man filtert nur den Verkehr der Benutzer, der an die Adressen geschickt wird, die gefiltert werden müssen (dazu kann man entweder die dort angegebenen IP-Adressen aus dem Register nehmen oder zusätzlich die im Register vorhandenen Domains auflösen).

Zu diesem Zweck habe ich damals einen einfachen Mini-DPI geschrieben – auch wenn es mir schwerfällt, ihn so zu nennen. Er ist sehr einfach und nicht besonders leistungsfähig – jedoch hat er uns und Dutzenden (wenn nicht Hunderten) anderen Providern ermöglicht, nicht sofort Millionen in industrielle DPI-Systeme zu investieren, sondern hat uns mehrere zusätzliche Jahre Zeit gegeben.

Übrigens, zu den damals und heute bestehenden DPIEs sei gesagt, viele, die damals auf dem Markt angebotene DPI-Systeme gekauft haben, haben diese bereits entsorgt. Sie sind einfach nicht für so etwas geeignet: Hunderttausende von Adressen, Zehntausende von URLs.

Gleichzeitig sind in diesem Bereich nationale Hersteller stark gewachsen. Ich spreche nicht von der Hardware – da versteht jeder Bescheid, jedoch ist die Software – das Wesentliche, was es im DPI gibt – vielleicht heute, wenn nicht das weltweit fortschrittlichste, dann doch zumindest a) entwickelt sie sich rasant weiter, und b) im Preisvergleich zu standardisierten Lösungen ist sie einfach ungleich günstiger als ihre ausländischen Wettbewerber.

Ich möchte stolz sein, aber es ist ein wenig traurig =)

Jetzt sah alles so aus:

Nach ein paar Jahren hatten alle bereits Prüfer; die Ressourcen im Register wurden immer mehr. Für einige alte Hardware (zum Beispiel Cisco 7600) wurde das Schema mit der "seitlichen Filterung" einfach unbrauchbar: Die Anzahl der Routen auf der 76-Plattform ist auf etwas rund neunhunderttausend begrenzt, während die Anzahl der IPv4-Routen heute bereits die 800.000 erreicht. Und wenn wir noch IPv6 und… wie viele? 900.000 einzelne Adressen im RKN-Verbot? =)

Einige wechselten zu einem Schema, bei dem der gesamte Hauptverkehr auf einen Filterserver gespiegelt wurde, der den gesamten Datenstrom analysieren sollte, und beim Auffinden von etwas Schädlichem Rückmeldungen (RST) in beide Richtungen (an Sender und Empfänger) sendete.

Je mehr Verkehr es gibt, desto weniger ist ein solches Schema anwendbar. Bei der geringsten Verzögerung in der Verarbeitung – wird der gespiegelte Verkehr einfach unbemerkt ins Nichts fliegen, und der Provider erhält ein Protokoll über eine Strafe.

Immer mehr Anbieter sind gezwungen, DPI-Systeme unterschiedlicher Zuverlässigkeit in den Hauptleitungen zu implementieren.

Vor ein oder zwei Jahren wurde gemunkelt, dass praktisch alle FSB eine echte Installation der Ausrüstung forderten SORM (früher kam die Mehrheit der Anbieter mit einer Genehmigung der Behörden aus SORM-Plan — einem Plan operativer Maßnahmen für den Fall, dass etwas irgendwo gefunden werden muss)

Neben Geld (nicht dass es völlig astronomisch wäre, aber dennoch Millionen) forderte SORM von vielen auch zusätzliche Manipulationen mit dem Netzwerk.

• SORM muss die "grauen" Adressen der Nutzer vor der NAT-Umsetzung sehen.
• SORM hat eine begrenzte Anzahl an Netzwerkinterfaces.

Deshalb mussten wir insbesondere einen Teil des Kernels drastisch umgestalten — einfach um den Nutzerverkehr an den Zugangservern an einem Ort zu bündeln. Um diesen über mehrere Links an SORM zu spiegeln.

Das heißt, sehr vereinfacht, war (links) vs wurde (rechts):

Jetzt Die meisten Anbieter müssen auch SORM-3 implementieren — das umfasst unter anderem die Protokollierung von NAT-Umsetzungen.

Zu diesem Zweck mussten wir in das obige Schema zusätzlich separate Hardware für NAT einfügen (genau das, worum es im ersten Teil geht). Außerdem musste dies in einer bestimmten Reihenfolge geschehen: Da SORM den Verkehr vor der Adressumsetzung "sehen" muss, muss der Verkehr genau folgendermaßen verlaufen: Nutzer -> Switch, Kernel -> Zugangserver -> SORM -> NAT -> Switch, Kernel -> Internet. Dafür mussten wir buchstäblich die Verkehrsströme in die andere Richtung umleiten, was ebenfalls recht kompliziert war.

Insgesamt: Über ein Jahrzehnt hat sich das Schema des Kernels eines durchschnittlichen Anbieters erheblich kompliziert, und die zusätzlichen Ausfallpunkte (sowohl in Form von Hardware als auch in Form einheitlicher Schaltleitungen) haben deutlich zugenommen. Tatsächlich impliziert die Forderung, "alles zu sehen", die Verdichtung dieses "Alles" an einem einzigen Punkt.

Ich denke, dass dies recht transparent auf die aktuellen Initiativen zur Souveränität des Runet, zu seiner Sicherheit, Stabilisierung und Verbesserung extrapoliert werden kann 🙂

Und vor uns steht noch Jarowaja.

Quelle: habr.com