Réponse détaillée au commentaire, ainsi qu'un aperçu de la vie des fournisseurs en Russie

Ce post a été inspiré par ce commentaire.

Je le reproduis ici :

kaleman aujourd'hui à 18:53

Mon fournisseur m'a réjoui aujourd'hui. Avec la mise à jour de son système de blocage de sites, il a bloqué le service de messagerie mail.ru. J'ai contacté le support technique depuis ce matin, mais ils ne peuvent rien faire. C'est un petit fournisseur et il semble qu'il soit bloqué par les fournisseurs de niveau supérieur. J'ai aussi remarqué un ralentissement dans l'ouverture de tous les sites, peut-être qu'ils ont mis en place une DLP défectueuse ? Avant, il n'y avait aucun problème d'accès. La destruction de la Runet se déroule sous mes yeux...

Le fait est que, apparemment, nous sommes ce fournisseur 🙁

Et en effet, kaleman j'avais presque deviné la cause des problèmes avec mail.ru (bien que nous ayons longtemps refusé de croire cela).

La suite sera divisée en deux parties :

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

Problèmes d'accessibilité de mail.ru

Oh, c'est une histoire assez longue.

Le fait est que pour mettre en œuvre les exigences de l'État (plus de détails dans la deuxième partie), nous avons acquis, configuré et installé certains équipements — tant pour filtrer les ressources interdites que pour effectuer des traductions NAT des abonnés.

Il y a quelque temps, nous avons enfin réorganisé le cœur du réseau de sorte que tout le trafic des abonnés passe strictement par cet équipement dans la direction souhaitée.

Il y a quelques jours, nous avons activé sur lui la filtration des contenus interdits (tout en laissant fonctionner l'ancien système) — tout semblait bien se passer.

Ensuite — nous avons progressivement commencé à activer le NAT sur cet équipement pour différentes parties des abonnés. Tout semblait également bien se passer.

Mais aujourd'hui, en activant le NAT pour une autre partie des abonnés — dès le matin, nous avons été confrontés à un nombre considérable de plaintes concernant l'inaccessibilité ou l'accès partiel à mail.ru et d'autres ressources de Mail Ru Group.

Nous avons commencé à vérifier : quelque chose quelque part parfois, occasionnellement envoie TCP RST en réponse aux demandes exclusivement aux réseaux mail.ru. De plus, il envoie des TCP RST mal générés (sans ACK), clairement artificiels. Voilà à quoi cela ressemblait :

Naturellement, les premières pensées concernaient le nouvel équipement : terrible DPI, aucune confiance en lui, que pourrait-il faire — après tout, le TCP RST est un phénomène assez courant parmi les outils de blocage.

Hypothèse kaleman concernant le fait que quelqu'un de « supérieur » filtre, nous l'avons également émise — mais nous l'avons tout de suite rejetée.

Tout d'abord, nous avons des uplinks suffisamment raisonnables pour ne pas souffrir de cela 🙂

Deuxièmement, nous sommes connectés à plusieurs IX à Moscou, et le trafic vers mail.ru passe précisément par eux — et eux n'ont ni obligations, ni aucune autre motivation à filtrer le trafic.

La seconde moitié de la journée a été consacrée à ce que l'on appelle généralement du chamanisme — avec le fournisseur d'équipement, pour cela merci à eux, ils ne nous ont pas laissés tomber 🙂

• la filtration a été complètement désactivée
• le NAT a été désactivé selon un nouveau schéma
• un PC de test a été isolé dans un pool distinct
• l'adressage IP était modifié

Dans la seconde moitié de la journée, une VM a été attribuée, sortant dans le réseau selon le schéma d'un utilisateur ordinaire, et elle ainsi que l'équipement ont été accessibles aux représentants du fournisseur. Le chamanisme a continué 🙂

Finalement, le représentant du fournisseur a affirmé avec assurance que le matériel n'était absolument pas en cause : les rst arrivent de quelque part plus haut.

RemarqueÀ ce stade, quelqu'un pourrait affirmer : mais il aurait été beaucoup plus simple de prendre un dump non pas depuis le PC de test, mais depuis la dorsale au-dessus du DPI ?

Non, malheureusement, prendre un dump (et même simplement faire un mirroring) à 40+ gbps n'est pas du tout trivial.

Après cela, déjà le soir — il ne restait plus rien d'autre à faire que de revenir sur l'hypothèse d'un étrange filtrage quelque part au-dessus.

J'ai vérifié par quel IX le trafic vers les réseaux MRG passait actuellement et j'ai simplement éteint les sessions BGP. Et — oh miracle ! — tout s'est immédiatement normalisé 🙁

D'une part — c'est vraiment dommage que toute la journée ait été consacrée à la recherche du problème, alors qu'il a été résolu en cinq minutes.

D'autre part :

— à ma connaissance, c'est un événement sans précédent. Comme je l'ai déjà écrit ci-dessus — aux IX vraiment il n'y a aucun sens à filtrer le trafic de transit. Ils en ont généralement des centaines de gigabits / téraoctets par seconde. Je n'ai tout simplement pas pu penser sérieusement à cela jusqu'à la fin.

— une coïncidence incroyablement chanceuse : un nouveau matériel complexe, auquel on ne fait pas vraiment confiance et dont on ne sait pas à quoi s'attendre — conçu justement pour bloquer des ressources, y compris avec des TCP RST

Actuellement, le NOC de cet internet exchange cherche le problème. Selon leurs affirmations (et je les crois), ils n'ont pas de système de filtration spécialement déployé. Mais, merci au ciel, la quête suivante — ce n'est déjà plus notre problème 🙂

C'était une petite tentative de justification, nous vous prions de comprendre et de pardonner 🙂

P.S.: je ne mentionne délibérément ni le fabricant DPI/NAT, ni IX (en fait, je n'ai même pas de réclamations particulières à leur sujet, l'essentiel est de comprendre que cela a eu lieu)

La réalité d'aujourd'hui (ainsi que celle d'hier et d'avant-hier) du point de vue d'un fournisseur d'accès Internet

Ces dernières semaines, j'ai passé beaucoup de temps à restructurer considérablement le cœur du réseau, effectuant toute une série de manipulations en direct, avec le risque d'affecter sérieusement le trafic utilisateur en temps réel. Compte tenu des objectifs, des résultats et des conséquences de tout cela, moralement, c'est assez lourd. Surtout en écoutant, encore une fois, les discours idéalistes sur la protection de la stabilité de l'internet russe, la souveraineté, etc.

Dans cette section, je vais tenter d'expliquer l'« évolution » du cœur du réseau d'un fournisseur d'accès Internet typique au cours de la dernière décennie.

Il y a dix ans.

À cette époque bénie, le cœur du réseau d'un fournisseur pouvait être aussi simple et fiable qu'un bouchon :

Sur cette image très simplifiée, il manque les autoroutes, les anneaux et le routage ip/mpls.

Son essence était que le trafic des utilisateurs arrivait finalement à une commutation de niveau cœur — d'où il allait vers BNG, d'où, en règle générale, il retournait à la commutation du cœur, et ensuite « à la sortie » — via une ou plusieurs gateway border vers Internet.

Un schéma similaire est très facilement redondé, tant au niveau L3 (routage dynamique) qu'au niveau L2 (MPLS).

Il est possible de mettre en place N+1 de quoi que ce soit : serveurs d'accès, commutateurs, frontières — et de les redonder d'une manière ou d'une autre pour un basculement automatique.

Après quelques années tout le monde en Russie a compris qu'il était impossible de continuer ainsi : il était urgent de protéger les enfants de l'influence néfaste du réseau.

Il est devenu nécessaire de trouver en urgence des moyens de filtrer le trafic des utilisateurs.

Il existe différentes approches.

Dans le pire des cas, quelque chose est installé « en travers » : entre le trafic utilisateur et Internet. Le trafic qui passe par cette « chose » est soumis à une analyse et, par exemple, un paquet falsifié avec une redirection est envoyé à l'abonné.

Dans un cas un peu meilleur — si les volumes de trafic le permettent — il est possible de faire une petite astuce : n'envoyer à la filtration que le trafic sortant des utilisateurs, uniquement vers les adresses qu'il est nécessaire de filtrer (pour cela, on peut soit prendre les adresses IP indiquées dans le registre, soit résoudre en plus les domaines présents dans le registre).

À l'époque, j'ai écrit un simple mini-dpi — bien que même le terme ne soit pas approprié. C'est très simple et peu performant — cependant, il nous a permis, ainsi qu'à des dizaines (voire des centaines) d'autres fournisseurs, de ne pas débourser immédiatement des millions pour des systèmes DPI industriels, et nous a donné quelques années supplémentaires.

À propos des DPI d’hier et d’aujourd’huiIl convient de mentionner que beaucoup de ceux qui ont acheté à l'époque des systèmes DPI disponibles sur le marché les ont déjà jetés. Ils ne sont tout simplement pas adaptés à cela : des centaines de milliers d'adresses, des dizaines de milliers d'URL.

Et en même temps, ce marché a beaucoup bénéficié aux fabricants nationaux. Je ne parle pas de la partie matérielle — c'est clair pour tout le monde, mais le logiciel — c'est la clé des DPI — est peut-être aujourd'hui, si ce n'est le plus avancé au monde, alors au moins a) il se développe à grands pas et b) au prix d'une boîte — il est tout simplement incomparable avec les concurrents étrangers.

J’aimerais pouvoir me vanter, mais c'est un peu triste =)

Maintenant, tout était comme suit :

Encore quelques années plus tard des vérificateurs étaient déjà présents partout ; les ressources dans le registre devenaient de plus en plus nombreuses. Pour un certain ancien équipement (comme le cisco 7600), le schéma de « filtration latérale » devenait tout simplement impraticable : le nombre de routes sur les plateformes 76 est limité à environ neuf cent mille, tandis que le nombre de routes IPv4 s'approche déjà des 800 000. Et si l'on ajoute ipv6... Que diriez-vous de... combien ? 900 000 adresses distinctes dans le ban RKN ? =)

Certains passaient à un schéma de réquisition de tout le trafic de transit vers un serveur de filtrage, qui devait analyser tout le flux et, en cas de détection de quelque chose de mauvais, renvoyer des RST dans les deux sens (à l'expéditeur et au destinataire).

Cependant, plus il y a de trafic, moins un tel schéma est applicable. Même un léger retard dans le traitement — le trafic réquisitionné passera simplement inaperçu, et le fournisseur recevra un protocole de pénalité.

De plus en plus de fournisseurs sont contraints d'installer des systèmes DPI de divers niveaux de fiabilité à travers les dorsales.

Il y a un an ou deux selon des rumeurs, pratiquement tous les FSB ont commencé à exiger l'installation réelle de l'équipement SORM (auparavant, la plupart des fournisseurs se contentaient d'une approbation avec les organes du plan SORM — un plan d'actions opérationnelles en cas de besoin de trouver quelque chose quelque part)

En plus de l'argent (pas si excessif que ça, mais tout de même — des millions), SORM a exigé pour beaucoup de nouvelles manipulations avec le réseau.

• SORM doit voir les adresses "grisées" des utilisateurs, avant la traduction NAT
• SORM a un nombre limité d'interfaces réseau

C'est pourquoi nous avons notamment dû restructurer une partie du noyau — juste pour rassembler le trafic des utilisateurs vers les serveurs d'accès en un seul endroit. Afin de réfléchir ce trafic à SORM via plusieurs liens.

En d'autres termes, de manière très simplifiée, c'était (à gauche) vs c'est devenu (à droite) :

Maintenant la plupart des fournisseurs doivent également mettre en œuvre SORM-3 — qui inclut, entre autres, l'enregistrement des traductions NAT.

À ces fins, il nous a fallu ajouter dans le schéma ci-dessus un équipement séparé pour le NAT (justement celui dont il était question dans la première partie). Et l'ajouter dans un certain ordre : puisque SORM doit "voir" le trafic avant la traduction des adresses — le trafic doit circuler exactement de la manière suivante : utilisateurs -> commutation, noyau -> serveurs d'accès -> SORM -> NAT -> commutation, noyau -> internet. Pour cela, nous avons dû, littéralement, "retourner" les flux de trafic dans l'autre sens en temps réel, ce qui était aussi assez compliqué.

En gros : au cours de dix ans, le schéma du noyau d'un fournisseur moyen s'est considérablement complexifié, et le nombre de points de défaillance supplémentaires (tant sous forme d'équipement que de lignes de commutation uniques) a considérablement augmenté. En fait, l'exigence même de "voir tout" implique de ramener tout cela à un seul point.

Je pense qu'il est tout à fait transparent de projeter cela sur les initiatives actuelles concernant la souveraineté de Runet, sa protection, sa stabilisation et son amélioration 🙂

Et à l'avenir, nous aurons Yarovaya.

Source : habr.com