Une réponse détaillée au commentaire, ainsi qu'un peu sur la vie des prestataires en Fédération de Russie

Déplacer moi vers ce post celui-ci est ici un commentaire .

Je l'amène ici:

kaleman aujourd'hui à 18:53

Aujourd'hui, j'étais satisfait du fournisseur. Parallèlement à la mise à jour du système de blocage de site, il a reçu un mailer mail.ru sous l'interdiction. Le matin, je tire le support technique, ils ne peuvent rien faire. Le fournisseur est petit, et apparemment les fournisseurs en amont le bloquent. J'ai également remarqué un ralentissement de l'ouverture de tous les sites, peut-être une sorte de courbe DLP bloquée? Auparavant, il n'y avait aucun problème d'accès. La destruction de Runet passe juste devant mes yeux ...

Le fait est que, semble-t-il, nous sommes le fournisseur même :(

En effet, Kaleman a presque deviné la cause des problèmes avec mail.ru (bien que pendant longtemps nous ayons refusé de croire en une telle chose).

Plus loin sera divisé en deux parties:

1. les causes de nos problèmes aujourd'hui avec mail.ru et une quête passionnante pour les trouver
2. l'existence du FAI dans les réalités d'aujourd'hui, la stabilité du runet souverain.

Problèmes avec la disponibilité de mail.ru

Oh, c'est une assez longue histoire.

Le fait est que pour mettre en œuvre les exigences de l'État (plus en détail dans la deuxième partie), nous avons acheté, configuré, installé du matériel - à la fois pour filtrer les ressources interdites et pour effectuer des diffusions NAT des abonnés.

Il y a quelque temps, nous avons finalement reconstruit le cœur du réseau afin que tout le trafic des abonnés passe par cet équipement dans la bonne direction.

Il y a quelques jours, nous avons activé le filtrage du contenu interdit (en même temps, laissant l'ancien système fonctionner) - tout semblait bien se passer.

En outre - progressivement commencé à inclure pour différentes parties des abonnés NAT sur cet équipement. En apparence - tout semble également s'être bien passé.

Mais aujourd'hui, après avoir activé l'équipement NAT pour la prochaine partie des abonnés, le matin, nous avons rencontré un nombre décent de plaintes concernant l'indisponibilité ou la disponibilité partielle de mail.ru et d'autres ressources de Mail Ru Group.

Ils ont commencé à vérifier: quelque chose quelque part quelquefois , envoie parfois TCP RST en réponse à des demandes exclusivement aux réseaux mail.ru. De plus, il envoie un RST TCP mal généré (sans ACK), évidemment artificiel. Quelque chose comme ça ressemblait:







Naturellement, les premières réflexions ont porté sur le nouvel équipement: un DPI épouvantable, on n'y fait pas confiance, on ne sait jamais ce qu'il peut faire - TCP RST est une chose assez courante parmi les outils de blocage.

L'hypothèse de Kaleman que quelqu'un filtre "supérieur", nous avons également avancé - mais ensuite rejetée.

Tout d'abord, nous avons suffisamment de liaisons montantes sensées pour ne pas souffrir comme ça :)

Deuxièmement, nous sommes connectés à plusieurs IXs à Moscou, et le trafic vers mail.ru les traverse précisément - et ils n'ont aucun devoir ni aucun autre motif pour filtrer le trafic.

La prochaine moitié de la journée a été consacrée à ce que l'on appelle habituellement le chamanisme - avec le vendeur d'équipement, pour lequel ils vous remercient, ils n'ont pas abandonné :)

• le filtrage a été complètement désactivé
• NAT a été déconnecté selon le nouveau schéma
• le PC de test a été déplacé vers un pool isolé séparé
• L'adressage IP a changé

Dans l'après-midi, une machine virtuelle a été allouée qui est allée au réseau selon le schéma d'un utilisateur ordinaire, et des représentants du vendeur ont eu accès à celle-ci et à l'équipement. Le chamanisme a continué :)

En fin de compte, le représentant du vendeur a déclaré avec confiance que le matériel n'avait absolument rien à voir avec cela: les premières provenaient d'un endroit plus élevé.


Après cela, le soir, il ne restait plus qu'à revenir à l'hypothèse d'un filtrage étrange quelque part au-dessus.

J'ai regardé ce que le trafic IX va maintenant vers les réseaux des IWG et je viens de payer les sessions bgp. Et - et voilà! - tout est immédiatement revenu à la normale :(

D'une part, il est regrettable que toute la journée ait été consacrée à la recherche du problème, bien qu'il ait été résolu en cinq minutes.

D'un autre côté:

- dans ma mémoire, c'est une chose sans précédent. Comme je l'ai écrit ci-dessus - IX, il n'y a vraiment aucun intérêt à filtrer le trafic de transit. Ils ont généralement des centaines de gigabits / térabits par seconde. Jusqu'à ce que le dernier ne puisse pas sérieusement imaginer cela.

- un ensemble de circonstances incroyablement réussi: un nouveau matériel complexe, qui n'a pas beaucoup de confiance et dont on ne sait pas trop à quoi s'attendre - aiguisé juste sous le blocage des ressources, y compris les TCP RST

Actuellement, le CNO de cet échange Internet recherche un problème. Selon eux (et je les crois), ils n'ont pas de système de filtration spécialement développé. Mais, grâce au paradis, la poursuite de la quête n'est plus notre problème :)

C'était une petite tentative pour nous justifier, veuillez comprendre et pardonner :)

PS: Je ne nomme pas intentionnellement le fabricant de DPI / NAT, ni IX (je n'ai d'ailleurs pas de plainte particulière contre eux, l'essentiel est de comprendre de quoi il s'agit)

Aujourd'hui (comme hier et avant-hier) la réalité du point de vue du fournisseur d'accès Internet

J'ai passé les dernières semaines à reconstruire de manière significative le cœur du réseau, à effectuer un tas de manipulations "de gain", avec le risque d'affecter significativement le trafic utilisateur en direct. Compte tenu des objectifs, des résultats et des conséquences de tout cela - moralement, tout cela est assez difficile. Surtout - en écoutant à nouveau les discours magnanimes sur la protection de la stabilité de Runet, la souveraineté, etc. etc.

Dans cette section, je vais essayer de raconter «l'évolution» du réseau central d'un fournisseur de services Internet typique au cours des dix dernières années.

Il y a dix ans.

En ces temps bénis, le cœur du réseau de fournisseurs pourrait être aussi simple et fiable qu'un embouteillage:



Sur cette image très, très simplifiée, il n'y a pas d'autoroutes, d'anneaux, de routage ip / mpls.

Son essence est que le trafic des utilisateurs est finalement arrivé à la commutation au niveau du noyau - d'où il est allé à BNG , d'où, en règle générale, revenir à la commutation du noyau, puis «quitter» - via une ou plusieurs passerelles frontalières vers Internet.

Un tel schéma est très, très facilement réservé à la fois sur L3 (routage dynamique) et sur L2 (MPLS).

Vous pouvez tout mettre N + 1: accéder aux serveurs, commutateurs, internes - et les réserver en quelque sorte pour le basculement automatique.

Après quelques années, il est devenu clair pour tout le monde en Russie qu'il était impossible de vivre comme ça: il était urgent de protéger les enfants de l'influence néfaste du réseau.

Il était urgent de trouver des moyens de filtrer le trafic des utilisateurs.

Il existe différentes approches.

Dans un cas moins bon, quelque chose est mis «dans la coupure»: entre le trafic des utilisateurs et Internet. Le trafic passant par ce «quelque chose» est analysé et, par exemple, un faux paquet de redirection est envoyé du côté de l'abonné.

Dans un cas légèrement meilleur - si le volume de trafic le permet - vous pouvez faire une petite feinte avec vos oreilles: envoyer uniquement le trafic sortant des utilisateurs vers les adresses qui doivent être filtrées (pour cela, vous pouvez soit prendre les adresses IP spécifiées dans le registre, soit résoudre en plus celles existantes. domaines dans le registre).

À une certaine époque, à ces fins, j'ai écrit un simple mini-dpi - bien que même la langue n'ose pas l'appeler ainsi. C'est très simple et pas très productif - cependant, cela nous a permis, ainsi qu'à des dizaines (voire des centaines) d'autres fournisseurs, de ne pas dépenser immédiatement des millions pour des systèmes DPI industriels, mais compte tenu de plusieurs années supplémentaires.


Maintenant, cela ressemblait à ceci:



Après quelques années , tout le monde avait déjà des vérificateurs; les ressources du registre sont devenues de plus en plus nombreuses. Pour certains équipements anciens (par exemple, le Cisco 7600), le système de «filtrage latéral» est tout simplement devenu inapplicable: le nombre de routes sur 76 plates-formes était limité à environ neuf cent mille, tandis que le nombre de routes IPv4 à lui seul approche déjà les 800 mille. Et si aussi ipv6 ... Et aussi ... combien y en a-t-il? 900 000 adresses individuelles dans le bain de la MRC? =)

Quelqu'un est passé à un schéma avec mise en miroir de tout le trafic principal vers le serveur de filtrage, qui devrait analyser l'ensemble du flux et envoyer quelque chose de RST aux deux côtés (expéditeur et destinataire) lorsqu'il trouve quelque chose de mauvais.

Cependant, plus il y a de trafic, moins un tel système est applicable. Au moindre retard dans le traitement, le trafic en miroir passera simplement inaperçu et le fournisseur recevra un rapport fin.

De plus en plus de fournisseurs sont obligés de placer des systèmes DPI de divers degrés de fiabilité dans le contexte des autoroutes.

Il y a un an ou deux, selon des rumeurs, presque tous les FSB ont commencé à exiger l'installation réelle de l'équipement SORM (auparavant, la plupart des prestataires avaient réussi à coordonner le plan SORM avec les autorités - un plan de mesures opérationnelles en cas de besoin de trouver quelque chose quelque part)

En plus de l'argent (pas si simple, mais toujours des millions), SORM a nécessité beaucoup plus de manipulations de réseau pour beaucoup.

• SORM a besoin de voir les adresses "grises" des utilisateurs, avant la diffusion nat
• SORM dispose d'un nombre limité d'interfaces réseau

Par conséquent, en particulier, nous avons dû reconstruire froidement un morceau du noyau - juste pour collecter le trafic utilisateur pour accéder aux serveurs quelque part en un seul endroit. Afin de le refléter avec plusieurs liens dans SORM.

Autrement dit, très simplifié, il était (à gauche) vs il est devenu (à droite):



Désormais , la plupart des fournisseurs exigent également l'introduction de SORM-3 - qui inclut, mais sans s'y limiter, la journalisation des diffusions NAT.

À ces fins, nous avons dû ajouter un équipement distinct pour NAT dans le circuit ci-dessus (juste celui qui est discuté dans la première partie). Et ajoutez dans un certain ordre: puisque SORM devrait «voir» le trafic avant la traduction d'adresse - le trafic devrait se dérouler exactement comme suit: utilisateurs -> commutation, noyau -> serveurs d'accès -> SORM -> NAT -> commutation, cœur -> Internet. Pour ce faire, nous avons dû littéralement «déployer» les flux de trafic dans l'autre sens, ce qui était également assez difficile.

Total: sur une douzaine d'années, le circuit central du fournisseur principal est parfois devenu plus complexe et les points de défaillance supplémentaires (à la fois sous forme d'équipement et sous forme de lignes de commutation uniques) ont considérablement augmenté. En fait, l'exigence de «tout voir» implique en soi la réduction de ce «tout» à un point.

Il me semble que cela peut être extrapolé de manière assez transparente aux initiatives actuelles sur la souveraineté de Runet, sa protection, sa stabilisation et son amélioration :)

Et devant est Yarovaya.