提示我看到这篇文章 .
我在这里引用一下：
今天在18：53
我对今天的提供商感到满意。 随着网站屏蔽系统的更新，他的邮件程序mail.ru也被屏蔽了。我从早上就一直打电话给技术支持，但他们也无能为力。 该提供商规模很小，而且显然排名较高的提供商会阻止它。 我还注意到所有网站的打开速度都变慢了，也许他们安装了某种不正当的 DLP？ 之前访问没有问题。 RuNet的毁灭就在我眼前发生……
事实上，我们似乎是同一个提供商:)
确实如此 我几乎猜到了 mail.ru 出现问题的原因（尽管我们很长一段时间拒绝相信这样的事情）。
下面将分为两部分：
- 当前 mail.ru 出现问题的原因以及寻找这些问题的激动人心的探索
- ISP在当今现实中的存在，主权RuNet的稳定性。
mail.ru 的可访问性问题
噢，这是一个很长的故事。
事实是，为了落实国家的要求（第二部分有更多细节），我们购买、配置和安装了一些设备——既是为了过滤禁止资源，也是为了实现 订户。
前一段时间，我们终于重建了网络核心，所有用户流量都严格按照正确的方向通过这个设备。
几天前，我们打开了禁止过滤功能（同时让旧系统继续工作）——一切似乎都很顺利。
接下来，他们逐渐开始在这个设备上为不同地区的用户启用NAT。 从表面上看，一切似乎也很顺利。
但今天，在为下一部分用户启用了设备上的 NAT 后，从早上起我们就收到了大量关于不可用或部分可用的投诉 以及其他Mail Ru Group 资源。
他们开始检查：某处有什么东西 有时, 偶尔 发送 仅响应 mail.ru 网络的请求。 此外，它还发送了一个错误生成的（没有 ACK）、显然是人为的 TCP RST。 它看起来是这样的：
自然，第一个想法是关于新设备：糟糕的 DPI，不信任它，你永远不知道它能做什么 - 毕竟 TCP RST 在拦截工具中是相当常见的东西。
假设条件 我们还提出了“上级”在过滤的想法，但立即就放弃了。
首先，我们有足够理智的上行链路，这样我们就不必遭受这样的痛苦:)
其次，我们连接到几个 在莫斯科，到 mail.ru 的流量都经过他们 - 他们既没有责任也没有任何其他动机来过滤流量。
接下来的半天时间都花在了通常所说的萨满教上——和设备供应商一起，为此我们感谢他们，他们没有放弃:)
- 过滤被完全禁用
- 使用新方案禁用 NAT
- 测试电脑被放置在一个单独的隔离池中
- IP 地址已更改
下午，根据普通用户的方案分配了一台连接到网络的虚拟机，并允许供应商代表访问该虚拟机和设备。 萨满教仍在继续:)
最后，供应商代表自信地表示，硬件与此完全无关：首先来自更高的地方。
注意此时，有人可能会说：但是不是从测试 PC 而是从 DPI 上方的高速公路上进行转储要容易得多？
不，不幸的是，以 40+gbps 的速度进行转储（甚至只是镜像）一点也不简单。
此后，到了晚上，除了回到上面某个地方有奇怪过滤的假设之外，别无他法。
我查看了 MRG 网络的流量现在正在通过哪个 IX，然后简单地取消了与它的 bgp 会话。 而且 - 你瞧！ - 一切立即恢复正常🙁
一方面，虽然五分钟就解决了问题，但花了一整天的时间来寻找问题，这很遗憾。
在另一方面：
——在我的记忆中，这是前所未有的事情。 正如我上面已经写过的 - IX 真 过滤过境流量是没有意义的。 它们通常每秒有数百吉比特/太比特。 直到最近我才认真想象这样的事情。
— 一个令人难以置信的幸运的巧合：一种新的复杂硬件不是特别值得信任，也不清楚从中可以期待什么 — 专门为阻塞资源（包括 TCP RST）而定制
该互联网交换机的 NOC 目前正在寻找问题。 根据他们的说法（我相信他们），他们没有任何专门部署的过滤系统。 但是，谢天谢地，进一步的探索不再是我们的问题:)
这是为自己辩护的一个小尝试，请理解和原谅:)
PS：我故意不点名DPI/NAT或IX的制造商（事实上，我什至对它们没有什么特别的抱怨，主要是了解它是什么）
从互联网提供商的角度来看今天（以及昨天和前天）的现实
过去几周，我花了很多时间重建网络核心，执行一系列“为了盈利”的操作，这可能会严重影响实时用户流量。 考虑到这一切的目标、结果和后果，从道义上讲，这一切都相当困难。 特别是——再次聆听关于保护符文稳定、主权等的精彩演讲。 等等。
在本节中，我将尝试描述过去十年来典型ISP的网络核心的“演变”。
十年前。
在那些幸福的时代，提供商网络的核心可以像交通拥堵一样简单可靠：
在这个非常非常简化的图中，没有中继、环、ip/mpls 路由。
它的本质是用户流量最终来到了内核级交换——从哪里到哪里 通常，从那里回到核心交换，然后“出去” - 通过一个或多个边界网关到达互联网。
这样的方案在 L3（动态路由）和 L2（MPLS）上都非常非常容易保留。
您可以安装 N+1 任何东西：访问服务器、交换机、边界 - 并以一种或另一种方式保留它们以进行自动故障转移。
几年后 俄罗斯每个人都清楚地意识到，这样的生活不可能再继续下去了：保护儿童免受互联网有害影响已刻不容缓。
迫切需要找到过滤用户流量的方法。
这里有不同的方法。
在不太好的情况下，某些东西被放置在“间隙”中：用户流量和互联网之间。 分析通过此“某物”的流量，例如，向订阅者发送带有重定向的虚假数据包。
在稍微好一点的情况下 - 如果流量允许 - 您可以用耳朵做一个小技巧：仅发送来自用户的流量进行过滤，仅发送到那些需要过滤的地址（为此，您可以获取 IP 地址从注册表中指定，或者另外解析注册表中的现有域）。
有一次，为了这些目的，我写了一个简单的 ——虽然我什至不敢这么称呼他。 它非常简单，而且效率不高 - 然而，它使我们和数十个（如果不是数百个）其他提供商不必立即在工业 DPI 系统上花费数百万美元，而是额外提供了几年的时间。
顺便说一下当时和现在的DPI顺便说一句，许多当时购买了市场上的 DPI 系统的人已经把它们扔掉了。 嗯，它们并不是为此而设计的：数十万个地址，数万个 URL。
与此同时，国内生产商已经非常强劲地进入这个市场。 我不是在谈论硬件组件 - 这里的每个人都清楚一切，但是软件 - DPI 拥有的主要内容 - 也许在今天，如果不是世界上最先进的，那么肯定是a）飞速发展， b) 盒装产品的价格——与国外竞争对手根本无法相比。
我想感到自豪，但有点悲伤 =)
现在一切看起来像这样：
再过几年 每个人都已经有审计员了； 注册表中的资源越来越多。 对于一些较旧的设备（例如 Cisco 7600），“侧面过滤”方案根本不适用：76 平台上的路由数量仅限于 4 万条左右，而如今仅 IPv800 路由数量就接近 6 条千。 如果也是 ipv900000...还有...有多少？ RKN 禁令中的 XNUMX 个个人地址？ =)
有人改用将所有主干流量镜像到过滤服务器的方案，该服务器应该分析整个流量，如果发现问题，则在两个方向（发送者和接收者）发送 RST。
但流量越大，该方案的适用性就越差。 如果处理过程中出现最轻微的延迟，镜像流量就会在不被注意的情况下飞驰而过，提供商将收到一份罚款报告。
越来越多的提供商被迫在高速公路上安装不同程度可靠性的 DPI 系统。
一两年前 据传言，几乎所有FSB都开始要求实际安装设备 （此前，大多数提供商都是经过当局批准进行管理的 SORM计划 - 需要在某处寻找某物时的操作措施计划）
除了金钱（不完全是昂贵的，但仍然是数百万美元）之外，SORM 还需要对网络进行更多的操作。
- SORM 需要在 nat 转换之前查看“灰色”用户地址
- SORM 的网络接口数量有限
因此，特别是，我们必须大力重建内核的一部分 - 只是为了将用户流量收集到某个地方的访问服务器。 为了通过多个链接将其镜像到 SORM 中。
也就是说，非常简单，它是（左）与成为（右）：
现在 大多数提供商还要求实施 SORM-3 - 其中包括记录 nat 广播。
为此，我们还必须在上图中添加单独的 NAT 设备（正是第一部分中讨论的内容）。 此外，按一定顺序添加：由于 SORM 在转换地址之前必须“查看”流量，因此流量必须严格按照以下顺序进行：用户 -> 交换、内核 -> 访问服务器 -> SORM -> NAT -> 交换、内核 - > 互联网。 为此，我们必须将流量“转向”另一个方向以获取利润，这也相当困难。
综上所述：在过去的十年中，一般提供商的核心设计变得复杂许多倍，并且额外的故障点（无论是设备形式还是单条交换线路形式）都显着增加。 事实上，“看到一切”的要求本身就意味着将这种“一切”简化为一点。
我认为这可以非常透明地推断到当前的 Runet 主权、保护、稳定和改进的举措:)
而 Yarovaya 仍然领先。
来源： habr.com