提示我看到這篇文章 .
我在這裡引用一下：
今天 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 任何東西：訪問伺服器、交換器、邊界 - 並以一種或另一種方式保留它們以進行自動故障轉移。
幾年後 俄羅斯每個人都清楚地意識到，這樣的生活不可能再繼續下去了：保護兒童免受網路有害影響已刻不容緩。
迫切需要找到過濾用戶流量的方法。
這裡有不同的方法。
在不太好的情況下，某些東西被放置在「間隙」：用戶流量和網路之間。 分析通過此「某物」的流量，例如，向訂閱者發送帶有重定向的虛假資料包。
在稍微好一點的情況下 - 如果流量允許 - 您可以用耳朵做一個小技巧：僅發送來自用戶的流量進行過濾，僅發送到那些需要過濾的地址（為此，您可以從註冊表中指定，或另外解析註冊表中的現有網域）。
有一次，為了這些目的，我寫了一個簡單的 ——雖然我甚至不敢這麼稱呼他。 它非常簡單，而且效率不高- 然而，它使我們和數十個（如果不是數百個）其他提供者不必立即在工業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 仍然領先。
來源： www.habr.com