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

Hat mich zu diesem Beitrag veranlasst das ist der Kommentar.

Ich zitiere es hier:

Kaleman heute in 18: 53

Ich war heute mit dem Anbieter zufrieden. Zusammen mit der Aktualisierung des Site-Blockierungssystems wurde sein Mailer mail.ru gesperrt. Ich rufe seit dem Morgen den technischen Support an, aber sie können nichts tun. Der Anbieter ist klein und wird offenbar von höherrangigen Anbietern blockiert. Mir ist auch eine Verlangsamung beim Öffnen aller Websites aufgefallen. Vielleicht haben sie eine Art krummes DLP installiert? Bisher gab es keine Probleme mit dem Zugang. Die Zerstörung von RuNet geschieht direkt vor meinen Augen ...

Tatsache ist, dass es den Anschein hat, dass wir derselbe Anbieter sind :)

In der Tat Kaleman Ich hätte fast die Ursache der Probleme mit mail.ru erraten (obwohl wir lange Zeit nicht daran glauben wollten).

Das Folgende gliedert sich in zwei Teile:

1. die Gründe für unsere aktuellen Probleme mit mail.ru und die spannende Suche, sie zu finden
2. die Existenz von ISP in der heutigen Realität, die Stabilität des souveränen RuNet.

Barrierefreiheitsprobleme mit mail.ru

Oh, das ist eine ziemlich lange Geschichte.

Tatsache ist, dass wir zur Umsetzung der staatlichen Anforderungen (mehr Details im zweiten Teil) einige Geräte gekauft, konfiguriert und installiert haben – sowohl für die Filterung verbotener Ressourcen als auch für die Implementierung NAT-Übersetzungen Abonnenten.

Vor einiger Zeit haben wir den Netzwerkkern endlich so umgebaut, dass der gesamte Teilnehmerverkehr durch diese Geräte streng in die richtige Richtung geleitet wurde.

Vor ein paar Tagen haben wir die verbotene Filterung aktiviert (wobei das alte System funktionsfähig blieb) – alles schien gut zu laufen.

Als nächstes begannen sie nach und nach, NAT auf diesen Geräten für verschiedene Teile der Abonnenten zu aktivieren. So wie es aussah, schien auch alles gut zu laufen.

Aber heute, nachdem wir NAT auf den Geräten für den nächsten Teil der Abonnenten aktiviert hatten, wurden wir vom Morgen an mit einer beträchtlichen Anzahl von Beschwerden über Nichtverfügbarkeit oder Teilverfügbarkeit konfrontiert mail.ru und andere Ressourcen der Mail Ru Group.

Sie begannen zu überprüfen: irgendwo etwas manchmal, von Zeit zu Zeit sendet TCP-RST als Antwort auf Anfragen ausschließlich an mail.ru-Netzwerke. Darüber hinaus sendet es ein falsch generiertes (ohne ACK) offensichtlich künstliches TCP-RST. So sah es aus:

Natürlich drehten sich die ersten Gedanken um die neue Ausrüstung: schreckliche DPI, kein Vertrauen in sie, man weiß nie, was sie kann – schließlich ist TCP RST eine ziemlich häufige Sache unter Blockierungstools.

Annahme Kaleman Wir haben auch die Idee vertreten, dass jemand „Vorgesetzter“ filtert, diese aber sofort verworfen.

Erstens haben wir ausreichend vernünftige Uplinks, sodass wir nicht so leiden müssen :)

Zweitens sind wir mit mehreren verbunden IX in Moskau, und der Verkehr zu mail.ru läuft über sie - und sie haben weder Verantwortung noch ein anderes Motiv, den Verkehr zu filtern.

Die nächste Hälfte des Tages verbrachten wir mit dem, was man üblicherweise Schamanismus nennt – zusammen mit dem Ausrüstungsverkäufer, wofür wir ihnen danken, gaben sie nicht auf :)

• Die Filterung wurde vollständig deaktiviert
• NAT wurde mit dem neuen Schema deaktiviert
• Der Test-PC wurde in einem separaten isolierten Pool platziert
• IP-Adressierung geändert

Am Nachmittag wurde eine virtuelle Maschine zugewiesen, die sich nach dem Schema eines regulären Benutzers mit dem Netzwerk verband, und Vertretern des Anbieters wurde Zugang zu ihr und der Ausrüstung gewährt. Der Schamanismus ging weiter :)

Am Ende stellte der Vertreter des Herstellers selbstbewusst fest, dass die Hardware überhaupt nichts damit zu tun habe: Die ersten Teile kämen von irgendwo höher.

BeachtenAn dieser Stelle könnte jemand sagen: Aber war es viel einfacher, einen Dump nicht vom Test-PC, sondern von der Autobahn über der DPI zu machen?

Nein, leider ist es keineswegs trivial, einen Dump (und auch nur eine Spiegelung) mit 40+ Gbit/s zu erstellen.

Danach, am Abend, blieb uns nichts anderes übrig, als zu der Annahme einer seltsamen Filterung irgendwo oben zurückzukehren.

Ich habe nachgeschaut, über welches IX der Datenverkehr zu den MRG-Netzwerken jetzt läuft, und habe einfach die BGP-Sitzungen dazu abgebrochen. Und – siehe da! - alles hat sich sofort wieder normalisiert 🙁

Einerseits ist es schade, dass der ganze Tag mit der Suche nach dem Problem verbracht wurde, obwohl es in fünf Minuten gelöst wurde.

Andererseits:

– In meiner Erinnerung ist das eine beispiellose Sache. Wie ich oben bereits geschrieben habe - IX wirklich Es macht keinen Sinn, den Transitverkehr zu filtern. Sie haben normalerweise Hunderte von Gigabit/Terabit pro Sekunde. Ich konnte mir so etwas bis vor Kurzem einfach nicht ernsthaft vorstellen.

– ein unglaublich glücklicher Zufall: eine neue komplexe Hardware, die nicht besonders vertrauenswürdig ist und von der nicht klar ist, was zu erwarten ist – speziell auf das Blockieren von Ressourcen, einschließlich TCP-RSTs, zugeschnitten

Das NOC dieser Internetbörse sucht derzeit nach einem Problem. Ihren Angaben zufolge (und ich glaube ihnen) verfügen sie über kein speziell eingesetztes Filtersystem. Aber Gott sei Dank ist die weitere Suche nicht mehr unser Problem :)

Das war ein kleiner Rechtfertigungsversuch, bitte verstehen und verzeihen :)

PS: Den Hersteller von DPI/NAT oder IX nenne ich bewusst nicht (eigentlich habe ich nicht einmal besondere Beschwerden darüber, Hauptsache man versteht, was es war)

Die heutige (sowie die gestrige und vorgestern) Realität aus Sicht eines Internetproviders

Ich habe die letzten Wochen damit verbracht, den Kern des Netzwerks erheblich umzubauen und eine Reihe von Manipulationen „aus Profitgründen“ durchzuführen, mit dem Risiko, den Live-Benutzerverkehr erheblich zu beeinträchtigen. Wenn man die Ziele, Ergebnisse und Konsequenzen all dessen bedenkt, ist das alles moralisch ziemlich schwierig. Vor allem - wieder einmal schöne Reden über den Schutz der Stabilität des Runet, Souveränität usw. hören. usw.

In diesem Abschnitt werde ich versuchen, die „Entwicklung“ des Netzwerkkerns eines typischen ISP in den letzten zehn Jahren zu beschreiben.

Vor zehn Jahren.

In diesen gesegneten Zeiten könnte der Kern eines Anbieternetzwerks so einfach und zuverlässig sein wie ein Stau:

In diesem sehr, sehr vereinfachten Bild gibt es keine Trunks, Ringe oder IP/MPS-Routing.

Das Wesentliche ist, dass der Benutzerverkehr letztendlich zum Kernel-Level-Switching gelangte – von dort, wo er hinging BNG, von wo aus in der Regel zurück zum Kern-Switching und dann „raus“ – über ein oder mehrere Grenz-Gateways zum Internet.

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

Sie können N+1 von allem installieren: Zugriffsserver, Switches, Grenzen – und sie auf die eine oder andere Weise für automatisches Failover reservieren.

Nach ein paar Jahren Allen in Russland wurde klar, dass es unmöglich war, so weiterzuleben: Es war dringend notwendig, Kinder vor dem schädlichen Einfluss des Internets zu schützen.

Es bestand ein dringender Bedarf, Möglichkeiten zu finden, den Benutzerverkehr zu filtern.

Hier gibt es unterschiedliche Ansätze.

In einem nicht sehr guten Fall wird etwas „in die Lücke“ gelegt: zwischen Benutzerverkehr und Internet. Der durch dieses „Etwas“ fließende Datenverkehr wird analysiert und beispielsweise ein gefälschtes Paket mit einer Weiterleitung an den Abonnenten gesendet.

Im etwas besseren Fall – wenn das Verkehrsaufkommen es zulässt – können Sie einen kleinen Trick mit Ihren Ohren machen: Senden Sie zum Filtern nur den Verkehr, der von Benutzern stammt, nur an die Adressen, die gefiltert werden müssen (dazu können Sie entweder die IP-Adressen nehmen). die dort angegebenen Domains aus der Registry entfernen oder zusätzlich bestehende Domains in der Registry auflösen).

Zu diesem Zweck habe ich einmal ein einfaches geschrieben Mini-DPI - obwohl ich mich nicht einmal traue, ihn so zu nennen. Es ist sehr einfach und nicht sehr produktiv – es ermöglichte uns und Dutzenden (wenn nicht Hunderten) anderen Anbietern jedoch, nicht sofort Millionen für industrielle DPI-Systeme auszugeben, sondern verschaffte uns mehrere zusätzliche Jahre Zeit.

Übrigens, über die damalige und aktuelle DPIViele Käufer der damals auf dem Markt erhältlichen DPI-Systeme hatten diese übrigens bereits weggeworfen. Nun, dafür sind sie nicht ausgelegt: Hunderttausende Adressen, Zehntausende URLs.

Und gleichzeitig sind inländische Produzenten sehr stark in diesen Markt vorgedrungen. Ich spreche nicht von der Hardwarekomponente – hier ist jedem klar, aber Software – das Wichtigste, was DPI hat – ist heute vielleicht, wenn nicht die fortschrittlichste der Welt, dann sicherlich a) eine sprunghafte Entwicklung, und b) zum Preis eines verpackten Produkts – einfach unvergleichlich mit ausländischen Konkurrenten.

Ich wäre gerne stolz, aber ein bisschen traurig =)

Nun sah alles so aus:

In ein paar weiteren Jahren jeder hatte bereits Auditoren; Es gab immer mehr Ressourcen in der Registrierung. Für einige ältere Geräte (z. B. Cisco 7600) wurde das „Side-Filtering“-Schema einfach nicht mehr anwendbar: Die Anzahl der Routen auf 76 Plattformen ist auf etwa neunhunderttausend begrenzt, während allein die Anzahl der IPv4-Routen heute bei fast 800 liegt tausend. Und wenn es auch IPv6 ist... Und außerdem... wie viel kostet es? 900000 Einzeladressen im RKN-Verbot? =)

Jemand ist auf ein Schema mit Spiegelung des gesamten Backbone-Verkehrs auf einen Filterserver umgestiegen, der den gesamten Fluss analysieren und, wenn etwas Schlimmes gefunden wird, RST in beide Richtungen (Absender und Empfänger) senden sollte.

Allerdings ist dieses Schema umso weniger anwendbar, je mehr Verkehr vorhanden ist. Bei der geringsten Verzögerung in der Verarbeitung fliegt der gespiegelte Verkehr einfach unbemerkt vorbei und der Anbieter erhält eine Bußgeldmeldung.

Immer mehr Anbieter sind gezwungen, auf Autobahnen DPI-Systeme unterschiedlicher Zuverlässigkeit zu installieren.

Vor ein oder zwei Jahren Gerüchten zufolge begann fast der gesamte FSB, die tatsächliche Installation von Ausrüstung zu fordern SORM (Früher liefen die meisten Anbieter mit Genehmigung der Behörden SORM-Plan - ein Plan mit operativen Maßnahmen für den Fall, dass irgendwo etwas gefunden werden muss)

Zusätzlich zu Geld (nicht gerade exorbitant, aber immer noch in Millionenhöhe) erforderte SORM noch viele weitere Manipulationen am Netzwerk.

• SORM muss vor der NAT-Übersetzung „graue“ Benutzeradressen sehen
• SORM verfügt über eine begrenzte Anzahl von Netzwerkschnittstellen

Daher mussten wir insbesondere einen Teil des Kernels stark umbauen – einfach um den Benutzerverkehr zu den Zugriffsservern irgendwo an einem Ort zu sammeln. Um es in SORM mit mehreren Links zu spiegeln.

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

im Moment Die meisten Anbieter verlangen außerdem die Implementierung von SORM-3 – was unter anderem die Protokollierung von NAT-Broadcasts beinhaltet.

Zu diesem Zweck mussten wir dem obigen Diagramm auch separate Geräte für NAT hinzufügen (genau das, was im ersten Teil besprochen wird). Fügen Sie außerdem in einer bestimmten Reihenfolge hinzu: Da SORM den Datenverkehr „sehen“ muss, bevor Adressen übersetzt werden, muss der Datenverkehr streng wie folgt ablaufen: Benutzer -> Switching, Kernel -> Zugriffsserver -> SORM -> NAT -> Switching, Kernel - > Internet. Dazu mussten wir die Verkehrsströme aus Profitgründen buchstäblich in die andere Richtung „umdrehen“, was ebenfalls ziemlich schwierig war.

Zusammenfassend lässt sich sagen: Das Kerndesign eines durchschnittlichen Anbieters ist in den letzten zehn Jahren um ein Vielfaches komplexer geworden und zusätzliche Fehlerquellen (sowohl in Form von Geräten als auch in Form von einzelnen Vermittlungsleitungen) haben deutlich zugenommen. Tatsächlich bedeutet die bloße Forderung, „alles zu sehen“, dieses „alles“ auf einen Punkt zu reduzieren.

Ich denke, dass dies ganz transparent auf aktuelle Initiativen zur Souveränisierung, zum Schutz, zur Stabilisierung und zur Verbesserung des Runet übertragen werden kann :)

Und Yarovaya liegt immer noch vorne.

Source: habr.com