M'a invité à ce post .
Je le cite ici :
aujourd'hui en 18: 53
J'ai été satisfait du fournisseur aujourd'hui. Parallèlement à la mise à jour du système de blocage du site, son mailer mail.ru a été banni. J'appelle le support technique depuis le matin, mais ils ne peuvent rien faire. Le fournisseur est petit et, apparemment, les fournisseurs de rang supérieur le bloquent. J'ai également remarqué un ralentissement dans l'ouverture de tous les sites, peut-être ont-ils installé une sorte de DLP tordu ? Auparavant, il n'y avait aucun problème d'accès. La destruction de RuNet se produit sous mes yeux...
Le fait est qu'il semble que nous soyons le même fournisseur :)
Et en effet, J'ai presque deviné la cause des problèmes avec mail.ru (même si nous avons longtemps refusé d'y croire).
Ce qui suit sera divisé en deux parties :
- les raisons de nos problèmes actuels avec mail.ru et la quête passionnante pour les trouver
- l'existence des FAI dans les réalités d'aujourd'hui, la stabilité du RuNet souverain.
Problèmes d'accessibilité avec mail.ru
Oh, c'est une assez longue histoire.
Le fait est que afin de mettre en œuvre les exigences de l'État (plus de détails dans la deuxième partie), nous avons acheté, configuré et installé des équipements - à la fois pour filtrer les ressources interdites et pour mettre en œuvre les abonnés.
Il y a quelque temps, nous avons finalement reconstruit le cœur du réseau de manière à ce que tout le trafic des abonnés transite par cet équipement strictement dans le bon sens.
Il y a quelques jours, nous avons activé le filtrage interdit (tout en laissant l'ancien système fonctionner) - tout semblait bien se passer.
Ensuite, ils ont progressivement commencé à activer le NAT sur cet équipement pour différentes parties des abonnés. À première vue, tout semblait également bien se passer.
Mais aujourd'hui, après avoir activé le NAT sur les équipements pour la prochaine partie des abonnés, nous avons été confrontés dès le matin à un nombre décent de plaintes concernant l'indisponibilité ou la disponibilité partielle. et d'autres ressources du groupe Mail Ru.
Ils ont commencé à vérifier : quelque chose quelque part parfois, de temps en temps envoie en réponse à des demandes exclusivement adressées aux réseaux mail.ru. De plus, il envoie un TCP RST mal généré (sans ACK), évidemment artificiel. Voici à quoi cela ressemblait :
Naturellement, les premières pensées concernaient le nouvel équipement : un DPI terrible, aucune confiance en lui, on ne sait jamais ce qu'il peut faire - après tout, TCP RST est une chose assez courante parmi les outils de blocage.
supposition Nous avons également avancé l’idée que quelqu’un de « supérieur » filtre, mais nous l’avons immédiatement écartée.
Premièrement, nous avons des liaisons montantes suffisamment saines pour ne pas avoir à souffrir comme ça :)
Deuxièmement, nous sommes connectés à plusieurs à Moscou, et le trafic vers mail.ru passe par eux - et ils n'ont ni la responsabilité ni aucun autre motif de filtrer le trafic.
La moitié de la journée suivante a été consacrée à ce qu'on appelle habituellement le chamanisme - en compagnie du vendeur d'équipement, ce pour quoi nous les remercions, ils n'ont pas abandonné :)
- le filtrage a été complètement désactivé
- NAT a été désactivé à l'aide du nouveau schéma
- le PC de test a été placé dans un pool isolé séparé
- L'adresse IP a changé
Dans l'après-midi, une machine virtuelle a été attribuée, connectée au réseau selon le schéma d'un utilisateur régulier, et les représentants du fournisseur ont eu accès à celle-ci ainsi qu'à l'équipement. Le chamanisme a continué :)
En fin de compte, le représentant du fournisseur a affirmé avec assurance que le matériel n’avait absolument rien à voir là-dedans : les premiers venaient de quelque part plus haut.
NoterÀ ce stade, quelqu'un pourrait dire : mais il était beaucoup plus facile de faire un dump non pas depuis le PC de test, mais depuis l'autoroute au-dessus du DPI ?
Non, malheureusement, effectuer un dump (et même simplement mettre en miroir) 40+gbps n'est pas du tout anodin.
Après cela, le soir, il ne restait plus qu'à revenir à l'hypothèse d'une étrange filtration quelque part au-dessus.
J'ai regardé par quel IX passe actuellement le trafic vers les réseaux MRG et j'ai simplement annulé les sessions BGP vers celui-ci. Et voilà ! - tout est immédiatement revenu à la normale 🙁
D’une part, il est dommage que toute la journée ait été consacrée à la recherche du problème, même s’il a été résolu en cinq minutes.
D'autre part:
— dans ma mémoire, c'est une chose sans précédent. Comme je l'ai déjà écrit ci-dessus - IX vraiment il ne sert à rien de filtrer le trafic de transit. Ils ont généralement des centaines de gigabits/térabits par seconde. Je ne pouvais tout simplement pas sérieusement imaginer quelque chose comme ça jusqu’à récemment.
— une coïncidence de circonstances incroyablement heureuse : un nouveau matériel complexe qui n'est pas particulièrement fiable et dont on ne sait pas clairement ce que l'on peut attendre — spécialement conçu pour bloquer les ressources, y compris les RST TCP
Le NOC de cet échange Internet recherche actuellement un problème. Selon eux (et je les crois), ils ne disposent pas de système de filtration spécialement déployé. Mais, Dieu merci, la poursuite de la quête n'est plus notre problème :)
C'était une petite tentative de me justifier, s'il vous plaît, comprenez et pardonnez :)
PS : je ne nomme volontairement pas le fabricant de DPI/NAT ou IX (en fait, je n'ai même pas de plaintes particulières à leur sujet, l'essentiel est de comprendre de quoi il s'agissait)
La réalité d'aujourd'hui (ainsi qu'hier et avant-hier) du point de vue d'un fournisseur d'accès Internet
J'ai passé les dernières semaines à reconstruire considérablement le cœur du réseau, en effectuant un tas de manipulations « dans un but lucratif », avec le risque d'affecter considérablement le trafic des utilisateurs 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 encore une fois de beaux discours sur la protection de la stabilité du Runet, de la souveraineté, etc. et ainsi de suite.
Dans cette section, je vais essayer de décrire « l’évolution » du cœur de réseau d’un FAI typique au cours des dix dernières années.
Il y a dix ans.
En ces temps bénis, le cœur d’un réseau de fournisseurs pouvait être aussi simple et fiable qu’un embouteillage :
Dans cette image très, très simplifiée, il n’y a pas de lignes réseau, d’anneaux, de routage ip/mpls.
Son essence est que le trafic utilisateur est finalement arrivé au niveau du noyau en passant d'où il est allé vers , d'où, en règle générale, retour à la commutation principale, puis « sortie » - via une ou plusieurs passerelles frontalières vers Internet.
Un tel schéma est très, très simple à réserver aussi bien sur L3 (routage dynamique) que sur L2 (MPLS).
Vous pouvez installer N+1 de tout : serveurs d'accès, commutateurs, frontières - et d'une manière ou d'une autre les réserver pour un basculement automatique.
Après quelques années Il est devenu évident pour tout le monde en Russie qu'il était impossible de vivre ainsi plus longtemps : il était urgent de protéger les enfants de l'influence pernicieuse d'Internet.
Il était urgent de trouver des moyens de filtrer le trafic des utilisateurs.
Il existe différentes approches ici.
Dans un cas pas très bon, quelque chose est mis « dans l'espace » : entre le trafic des utilisateurs et Internet. Le trafic transitant par ce « quelque chose » est analysé et, par exemple, un faux paquet avec redirection est envoyé vers l'abonné.
Dans un cas légèrement meilleur - si les volumes de trafic le permettent - vous pouvez faire un petit truc avec vos oreilles : envoyer pour filtrer uniquement le trafic provenant des utilisateurs uniquement vers les adresses qui doivent être filtrées (pour ce faire, vous pouvez soit prendre les adresses IP spécifiés à partir du registre, ou résolvez en outre ceux existants domaines dans le registre).
À une époque, à ces fins, j'écrivais un simple - même si je n'ose même pas l'appeler ainsi. C'est très simple et peu productif - cependant, cela 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, mais nous a donné plusieurs années supplémentaires.
À propos, à propos du DPI d'alors et d'aujourd'huiD’ailleurs, beaucoup de ceux qui ont acheté les systèmes DPI disponibles sur le marché à l’époque les avaient déjà jetés. Eh bien, ils ne sont pas conçus pour ça : des centaines de milliers d’adresses, des dizaines de milliers d’URL.
Et dans le même temps, les producteurs nationaux se sont très fortement développés sur ce marché. Je ne parle pas du composant matériel - tout est clair pour tout le monde ici, mais le logiciel - l'essentiel du DPI - est peut-être aujourd'hui, sinon le plus avancé au monde, alors certainement a) se développant à pas de géant, et b) au prix d'un produit en boîte - tout simplement incomparable avec les concurrents étrangers.
J'aimerais être fier, mais un peu triste =)
Maintenant, tout ressemblait à ceci :
Dans quelques années tout le monde avait déjà des auditeurs ; Il y avait de plus en plus de ressources dans le registre. Pour certains équipements plus anciens (par exemple, Cisco 7600), le système de « filtrage latéral » est tout simplement devenu inapplicable : le nombre de routes sur 76 plates-formes est limité à environ neuf cent mille, alors que le nombre de routes IPv4 à lui seul approche aujourd'hui les 800. mille. Et si c'est aussi ipv6... Et aussi... combien ça coûte ? 900000 XNUMX adresses individuelles dans l’interdiction RKN ? =)
Quelqu'un est passé à un système de mise en miroir de tout le trafic principal vers un serveur de filtrage, qui devrait analyser l'intégralité du flux et, si quelque chose de mauvais est détecté, envoyer RST dans les deux sens (expéditeur et destinataire).
Cependant, plus le trafic est important, moins ce système est applicable. S'il y a le moindre retard dans le traitement, le trafic en miroir passera tout simplement inaperçu et le fournisseur recevra un rapport amende.
De plus en plus de fournisseurs sont obligés d’installer des systèmes DPI plus ou moins fiables sur les autoroutes.
Il y a un an ou deux selon les rumeurs, presque tous les FSB ont commencé à exiger l'installation effective des équipements (auparavant, la plupart des prestataires géraient avec l'accord des autorités Plan SORM - un plan de mesures opérationnelles en cas de besoin de trouver quelque chose quelque part)
En plus de l'argent (pas vraiment exorbitant, mais quand même des millions), SORM a nécessité bien plus de manipulations avec le réseau.
- SORM a besoin de voir les adresses des utilisateurs « grises » avant la traduction nationale
- SORM dispose d'un nombre limité d'interfaces réseau
Par conséquent, en particulier, nous avons dû reconstruire en grande partie une partie du noyau - simplement afin de collecter le trafic utilisateur vers les serveurs d'accès quelque part au même endroit. Afin de le refléter dans SORM avec plusieurs liens.
Autrement dit, de manière très simplifiée, c'était (à gauche) vs est devenu (à droite) :
tout de suite La plupart des fournisseurs exigent également la mise en œuvre de SORM-3, qui inclut, entre autres, la journalisation des diffusions nat.
À ces fins, nous avons également dû ajouter un équipement séparé pour NAT au schéma ci-dessus (exactement ce qui est discuté dans la première partie). De plus, ajoutez dans un certain ordre : puisque SORM doit « voir » le trafic avant de traduire les adresses, le trafic doit se dérouler strictement comme suit : utilisateurs -> commutation, noyau -> serveurs d'accès -> SORM -> NAT -> commutation, noyau - >Internet. Pour ce faire, nous avons dû littéralement « inverser » les flux de trafic dans un but lucratif, ce qui était également assez difficile.
En résumé : au cours des dix dernières années, la conception de base d'un fournisseur moyen est devenue beaucoup plus complexe et les points de défaillance supplémentaires (tant sous la forme d'équipements que sous la forme de lignes de commutation uniques) ont considérablement augmenté. En fait, l’exigence même de « tout voir » implique de réduire ce « tout » à un seul point.
Je pense que cela peut être extrapolé de manière tout à fait transparente aux initiatives actuelles visant à souverainiser le Runet, à le protéger, à le stabiliser et à l'améliorer :)
Et Yarovaya est toujours en avance.
Source: habr.com