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

Bewegen Sie mich zu diesem Beitrag. Dieser hier ist ein Kommentar .

Ich bringe ihn hierher:

Kaleman heute um 18:53

Heute war ich mit dem Anbieter zufrieden. Zusammen mit der Aktualisierung des Site-Blocking-Systems erhielt er einen Mail-Mail-Mailer unter dem Verbot. Am Morgen ziehe ich technischen Support an, sie können nichts tun. Der Anbieter ist klein, und anscheinend blockieren Upstream-Anbieter ihn. Ich bemerkte auch eine Verlangsamung bei der Eröffnung aller Websites, vielleicht hing eine Art Kurven-DLP? Bisher gab es keine Probleme mit dem Zugriff. Die Zerstörung von Runet geht direkt vor meinen Augen ...

Tatsache ist, dass wir anscheinend genau der Anbieter sind :(

In der Tat ahnte Kaleman fast, was die Probleme mit mail.ru waren (obwohl wir uns lange Zeit geweigert hatten, an so etwas zu glauben).

Weiter wird in zwei Teile unterteilt:

1. die Ursachen unserer heutigen Probleme mit mail.ru und eine aufregende Suche nach ihnen
2. die Existenz des ISP in der heutigen Realität, die Stabilität der souveränen Runet.

Probleme mit der Verfügbarkeit von mail.ru

Oh, das ist eine ziemlich lange Geschichte.

Tatsache ist, dass wir zur Umsetzung der Anforderungen des Staates (ausführlicher im zweiten Teil) einige Geräte gekauft, konfiguriert und installiert haben - sowohl zum Filtern verbotener Ressourcen als auch zum Ausführen von NAT-Sendungen von Abonnenten.

Vor einiger Zeit haben wir endlich den Kern des Netzwerks neu aufgebaut, sodass der gesamte Teilnehmerverkehr durch dieses Gerät in die richtige Richtung geleitet wurde.

Vor ein paar Tagen haben wir das Filtern verbotener Inhalte aktiviert (gleichzeitig das alte System funktionieren lassen) - alles schien gut zu laufen.

Weiter - begann allmählich für verschiedene Teile der Abonnenten NAT auf diesem Gerät aufzunehmen. In der Erscheinung scheint auch alles gut gelaufen zu sein.

Nachdem wir heute NAT-Geräte für den nächsten Teil der Abonnenten eingeschaltet hatten, stießen wir am Morgen auf eine anständige Anzahl von Beschwerden über die Nichtverfügbarkeit oder teilweise Verfügbarkeit von mail.ru und anderen Ressourcen der Mail Ru Group.

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







Die ersten Gedanken betrafen natürlich neue Geräte: eine schreckliche DPI, es gibt kein Vertrauen in sie, man weiß nie, was sie kann, weil TCP RST unter blockierenden Tools ziemlich häufig vorkommt.

Die Annahme von Kaleman, dass jemand "überlegen" filtert , haben wir ebenfalls vorgebracht - aber dann verworfen.

Erstens haben wir genug vernünftige Uplinks, um nicht so zu leiden :)

Zweitens sind wir mit mehreren IXs in Moskau verbunden, und der Verkehr zu mail.ru wird durch sie geleitet - und sie haben keine Pflichten oder andere Motive, um den Verkehr zu filtern.

Die nächste Hälfte des Tages wurde mit dem verbracht, was normalerweise Schamanismus genannt wird - zusammen mit dem Ausrüstungsverkäufer, für den sie sich bedanken, gaben sie nicht auf :)

• Die Filterung wurde vollständig deaktiviert
• NAT wurde gemäß dem neuen Schema getrennt
• Der Test-PC wurde in einen separaten isolierten Pool verschoben
• IP-Adresse geändert

Am Nachmittag wurde eine virtuelle Maschine zugewiesen, die nach dem Schema eines normalen Benutzers in das Netzwerk einging, und Vertreter des Anbieters erhielten Zugriff darauf und auf die Ausrüstung. Der Schamanismus ging weiter :)

Am Ende erklärte der Vertreter des Anbieters zuversichtlich, dass die Hardware absolut nichts damit zu tun habe: Die ersten kamen von irgendwo höher.


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

Ich habe durchgesehen, was der IX-Verkehr jetzt in die Netzwerke der IWGs leitet, und habe nur BGP-Sitzungen dafür ausgezahlt. Und siehe da! - alles normalisierte sich sofort wieder :(

Einerseits ist es bedauerlich, 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 dies eine beispiellose Sache. Wie ich oben geschrieben habe - IX macht es wirklich keinen Sinn, den Transitverkehr zu filtern. Sie haben normalerweise Hunderte von Gigabit / Terabit pro Sekunde. Ich konnte mir das bis zuletzt nicht ernsthaft vorstellen.

- eine unglaublich erfolgreiche Reihe von Umständen: eine neue komplexe Hardware, die nicht viel Vertrauen hat und von der nicht klar ist, was zu erwarten ist - geschärft nur unter der Blockierung von Ressourcen, einschließlich TCP-RSTs

Derzeit sucht das NOC dieser Internetbörse nach einem Problem. Ihnen zufolge (und ich glaube ihnen) haben sie kein speziell entwickeltes Filtersystem. Aber dank des Himmels ist die weitere Suche nicht länger unser Problem :)

Es war ein kleiner Versuch, uns zu rechtfertigen, bitte verstehe und vergebe :)

PS: Ich nenne absichtlich weder den Hersteller von DPI / NAT noch IX (ich habe sogar keine besonderen Beschwerden gegen sie, die Hauptsache ist zu verstehen, was es war).

Heute (sowie gestern und vorgestern) Realität aus Sicht des Internetproviders

Ich habe die letzten Wochen damit verbracht, den Kern des Netzwerks erheblich neu aufzubauen und eine Reihe von Manipulationen durchzuführen, mit dem Risiko, den Live-Benutzerverkehr erheblich zu beeinträchtigen. Angesichts der Ziele, Ergebnisse und Konsequenzen all dessen - moralisch gesehen - ist dies alles ziemlich schwierig. Besonders - noch einmal die großmütigen Reden über den Schutz der Stabilität von Runet, Souveränität usw. anhören. usw.

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

Vor zehn Jahren.

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



Auf diesem sehr, sehr vereinfachten Bild gibt es keine Autobahnen, Ringe, IP / MPLS-Routing.

Das Wesentliche ist, dass der Benutzerverkehr letztendlich über ein oder mehrere Grenzgateways zum Internet zum Switching auf Kernel-Ebene gelangte - von dort zu BNG , von wo aus in der Regel zurück zum Kernel-Switching und dann zum „Beenden“.

Ein solches Schema ist sowohl für L3 (dynamisches Routing) als auch für L2 (MPLS) sehr, sehr leicht reserviert.

Sie können N + 1 alles setzen: auf Server, Switches, Boarder zugreifen - und sie irgendwie für ein automatisches Failover reservieren.

Nach einigen Jahren wurde allen in Russland klar, dass es unmöglich ist, so weiterzuleben: Es war dringend notwendig, Kinder vor dem schädlichen Einfluss des Netzwerks zu schützen.

Es war dringend erforderlich, Wege zu finden, um den Benutzerverkehr zu filtern.

Es gibt verschiedene Ansätze.

In einem nicht so guten Fall wird etwas „in den Schnitt“ gebracht: zwischen Benutzerverkehr und Internet. Der durch dieses "Etwas" fließende Verkehr wird analysiert und beispielsweise ein gefälschtes Umleitungspaket an die Teilnehmerseite gesendet.

In einem etwas besseren Fall - wenn das Verkehrsaufkommen dies zulässt - können Sie eine kleine Finte mit Ihren Ohren machen: Senden Sie nur ausgehenden Verkehr von Benutzern an die Adressen, die gefiltert werden müssen (dazu können Sie entweder die dort angegebenen IP-Adressen aus der Registrierung übernehmen oder vorhandene auflösen Domains in der Registrierung).

Zu diesen Zwecken habe ich einmal ein einfaches Mini-dpi geschrieben - obwohl selbst die Sprache es nicht wagt, es so zu nennen. Es ist sehr einfach und nicht sehr produktiv - es hat uns und Dutzenden (wenn nicht Hunderten) anderer Anbieter jedoch ermöglicht, nicht sofort Millionen für industrielle DPI-Systeme auszugeben, sondern mehrere zusätzliche Jahre Zeit zu haben.


Jetzt sah es so aus:



Nach ein paar Jahren hatten alle bereits Wirtschaftsprüfer; Ressourcen in der Registrierung wurden immer mehr. Bei einigen alten Geräten (z. B. Cisco 7600) wurde das Schema der „Seitenfilterung“ einfach nicht mehr anwendbar: Die Anzahl der Routen auf 76 Plattformen war auf etwa neunhunderttausend begrenzt, während sich die Anzahl der IPv4-Routen heute bereits 800.000 nähert. Und wenn auch ipv6 ... und auch ... wie viel gibt es? 900.000 Einzeladressen im RCN-Bad? =)

Jemand wechselte zu einem Schema mit Spiegelung des gesamten Hauptverkehrs zum Filterserver, der den gesamten Stream analysieren und etwas RST an beide Seiten (Absender und Empfänger) senden sollte, wenn er etwas Schlechtes findet.

Je mehr Verkehr jedoch vorhanden ist, desto weniger ist ein solches Schema anwendbar. Bei der geringsten Verzögerung bei der Verarbeitung wird der gespiegelte Verkehr einfach unbemerkt fliegen und der Anbieter erhält einen guten Bericht.

Immer mehr Anbieter sind gezwungen, DPI-Systeme mit unterschiedlichem Zuverlässigkeitsgrad in den Kontext von Autobahnen zu stellen.

Gerüchten zufolge forderten vor ein oder zwei Jahren fast alle FSBs die tatsächliche Installation von SORM- Geräten (zuvor gelang es den meisten Anbietern, den SORM-Plan mit den Behörden zu koordinieren - ein Plan mit operativen Maßnahmen für den Fall, dass irgendwo etwas gefunden werden muss).

Neben Geld (nicht so einfach, aber immer noch Millionen) erforderte SORM für viele viel mehr Netzwerkmanipulationen.

• SORM muss die "grauen" Adressen der Benutzer sehen, bevor sie gesendet werden
• SORM verfügt über eine begrenzte Anzahl von Netzwerkschnittstellen

Daher mussten wir insbesondere einen Teil des Kernels kühl neu erstellen - nur um Benutzerdatenverkehr zu sammeln und auf Server an einem Ort zuzugreifen. Um es mit mehreren Links in SORM zu spiegeln.

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



Jetzt verlangen die meisten Anbieter auch die Einführung von SORM-3 - einschließlich, aber nicht beschränkt auf die Protokollierung von NAT-Broadcasts.

Zu diesem Zweck mussten wir in der obigen Schaltung separate Geräte für NAT hinzufügen (nur das, was im ersten Teil besprochen wird). Und um in einer bestimmten Reihenfolge hinzuzufügen: Da SORM den Datenverkehr vor der Adressübersetzung „sehen“ sollte, sollte der Datenverkehr genau wie folgt verlaufen: Benutzer -> Switching, Kernel -> Zugriffsserver -> SORM -> NAT -> Switching, Core -> Internet. Dazu mussten wir die Verkehrsströme buchstäblich in die andere Richtung „implementieren“, was ebenfalls recht schwierig war.

Insgesamt: Über ein Dutzend Jahre ist die Kernschaltung des Kernanbieters zeitweise komplexer geworden, und zusätzliche Fehlerstellen (sowohl in Form von Geräten als auch in Form einzelner Schaltleitungen) haben erheblich zugenommen. Tatsächlich impliziert das Erfordernis, „alles zu sehen“, die Reduktion dieses „Alles“ auf einen Punkt.

Es scheint mir, dass dies ziemlich transparent auf aktuelle Initiativen zur Souveränisierung von Runet, seinem Schutz, seiner Stabilisierung und Verbesserung hochgerechnet werden kann :)

Und vor uns liegt Yarovaya.