コメントに対する詳細な回答と、ロシア連邦のプロバイダーの生活についての少し

この投稿に私を動かしてください。 これはコメントです。



ここに持ってきます：

今日のケールマン 18:53



今日、私はプロバイダーに満足しました。 サイトブロックシステムの更新に加えて、彼は禁止の下でmail.ruメールメーラーを取得しました。 午前中、私はテクニカルサポートを利用しますが、彼らは何もできません。 プロバイダーは小さく、上流のプロバイダーがブロックしているようです。 また、すべてのサイトのオープンが遅くなっていることに気づきました。おそらく、ある種のカーブDLPがハングしましたか？ 以前は、アクセスに問題はありませんでした。 Runetの破壊は私の目の前で起こります...

実際のところ、私たちはまさにプロバイダーです:(



実際、 kalemanはmail.ruの問題の原因をほとんど推測していました（ただし、長い間、そのようなことを信じることを拒否していました）。



さらに2つの部分に分かれます。

1. 今日のmail.ruの問題の原因とそれらを見つけるための刺激的な探求
2. 今日の現実におけるISPの存在、ソブリンルネットの安定性。

mail.ruの可用性に関する問題

ああ、それはかなり長い話です。



実際には、州の要件を実装するために（第2部でより詳細に）、禁止リソースのフィルタリングとサブスクライバーのNATブロードキャストの実行の両方のために、いくつかの機器を購入、構成、設置しました。



少し前に、最終的にネットワークのコアを再構築して、すべての加入者トラフィックがこの機器を正しい方向に通過するようにしました。



数日前に、禁止されたコンテンツのフィルタリングをオンにしました（同時に古いシステムを動作させたままにしました）-すべてうまくいったようです。



さらに-徐々に加入者のさまざまな部分にこの機器のNATを含めるようになりました。 外観では-すべてもうまくいったようです。



しかし、今日、次の加入者のNAT機器をオンにした後、午前中にmail.ruおよびその他のMail Ru Groupリソースの利用不能または部分的な利用可能性についてかなりの数の苦情がありました。



彼らはチェックを開始しました： 時々どこかで、mail.ruネットワークへの排他的要求に応じてTCP RSTを時々送信します。 さらに、不正に生成された（ACKなし）、明らかに人為的なTCP RSTを送信します。 このようなものに見えた：















当然のことながら、最初の考えは新しい機器についてでした。ひどいDPI、それに対する自信はありません。何ができるのか決してわかりません。TCPRSTはブロッキングツールでかなり一般的なものだからです。



誰かが「上位」をフィルタリングしているというケールマンの仮定、私たちも提案します-しかし、その後破棄されます。



まず、そのように苦しむことがないように、十分な正常なアップリンクがあります:)



第二に、モスクワの複数のIXに接続されており、mail.ruへのトラフィックはそれらを通過します。トラフィックをフィルタリングする義務やその他の動機はありません。



次の半分は、通常シャーマニズムと呼ばれるものに費やされました-おかげで、機器ベンダーと一緒に、放棄されませんでした:)

• フィルタリングは完全に無効になりました
• NATは新しいスキームに従って切断されました
• テストPCは別の分離プールに移動されました
• IPアドレスが変更されました

午後には、通常のユーザーのスキームに従ってネットワークに入る仮想マシンが割り当てられ、ベンダーの代表者が仮想マシンと機器へのアクセスを許可されました。 シャーマニズムは続きました:)



最終的に、ベンダーの代表者は、ハードウェアはそれとはまったく関係がないと自信を持って述べました。





その後、夕方に-上記のどこかで奇妙なフィルタリングの仮定に戻る以外に何もすることがありませんでした。



どのIXトラフィックが現在IWGのネットワークに送られているかを調べ、bgpセッションを支払いました。 そして-見よ！ -すべてがすぐに正規化されます:(



一方で、5分で解決されたにもかかわらず、1日が問題の検索に費やされたのは残念です。



一方、



-私の記憶では、これは前例のないことです。 上で書いたように-IXは通過トラフィックをフィルタリングすることには本当に意味がありません。 通常、1秒あたり数百ギガビット/テラビットです。 私はそのようなことを真剣に想像できませんでした。



-信じられないほど幸運な状況の組み合わせ：新しい複雑なハードウェア。信頼性が低く、何を期待すべきかが明確ではない-TCP RSTを含むリソースのブロックのすぐ下で鋭くなった



現在、このインターネットエクスチェンジのNOCは問題を探しています。 彼らによると（そして私は彼らを信じています）彼らは特別に開発されたろ過システムを持っていません。 しかし、天国のおかげで、さらなる探求はもはや私たちの問題ではありません:)



それは自分自身を正当化する小さな試みでした、理解して許してください:)



PS：私は意図的にDPI / NATやIXのメーカーに名前を付けません（実際、特別な苦情さえありません。主なことはそれが何であるかを理解することです）

インターネットプロバイダーの観点から見た今日（および昨日と前日）の現実

先週、ネットワークのコアを大幅に再構築し、多くの操作を「獲得」して実行しましたが、実際のユーザートラフィックに大きな影響を与えるリスクがありました。 このすべての目標、結果、結果を考えると、道徳的には、これはすべて非常に困難です。 特に-もう一度、ルネの安定、主権などを保護することについての寛大なスピーチを聞いています。 など



このセクションでは、過去10年間の典型的なインターネットサービスプロバイダーのコアネットワークの「進化」について説明します。



10年前。



これらの恵まれた時代には、プロバイダーネットワークのコアは、交通渋滞と同じくらい簡単で信頼性があります。







この非常に非常に単純化された図には、高速道路、リング、IP / MPLSルーティングはありません。



その本質は、ユーザートラフィックが最終的にカーネルレベルのスイッチングに到達したことです。そこからBNGに移動し、そこから原則としてカーネルスイッチングに戻り、1つ以上の境界ゲートウェイを経由してインターネットに「出ます」。



このようなスキームは、L3（動的ルーティング）とL2（MPLS）の両方で非常に簡単に予約されます。



サーバー、スイッチ、ボーダーにアクセスして、N + 1の何でも置くことができます-そして、何らかの方法でそれらを自動フェイルオーバー用に予約します。



数年後、ロシアのすべての人にとって、そのように生きることは不可能であることが明らかになりました。ネットワークの有害な影響から子供を保護することが緊急に必要でした。



ユーザートラフィックをフィルタリングする方法を見つけることが急務でした。



さまざまなアプローチがあります。



あまり良くないケースでは、ユーザートラフィックとインターネットの間に何かが「カット」されています。 この「何か」を通過するトラフィックが分析され、たとえば、偽のリダイレクトパケットが加入者側に送信されます。



少し良いケースでは-トラフィックの量が許せば-あなたは耳で小さな気分を作ることができます：ユーザーからの発信トラフィックのみをフィルタリングする必要があるアドレスに送信します（このために、レジストリからそこに指定されたIPアドレスを取得するか、利用可能なものをさらに解決することができますレジストリ内のドメイン）。



かつて、これらの目的のために、私は単純なミニDPIを作成しましたが、言語でさえあえてそれを呼び出すことはありません。 非常にシンプルで生産的ではありません-ただし、数百（数百ではないにしても）のプロバイダーが、数百万を工業用DPIシステムにすぐに費やさずに、さらに数年の時間を費やすことができました。





これですべてが次のようになりました







数年後 、誰もがすでに監査役を持っていました。 レジストリ内のリソースはますます多くなりました。 一部の古い機器（たとえば、Cisco 7600）では、「サイドフィルタリング」を使用したスキームは単純に適用できなくなりました。76プラットフォーム上のルートの数は約90万に制限されていますが、現在のIPv4ルートの数はすでに80万に近づいています。 そして、もしipv6 ...そして...また、そこにはいくらですか？ RCNバス内の900,000個の住所？ =）



誰かがすべての主要なトラフィックをフィルタリングサーバーにミラーリングするスキームに切り替えました。これは、ストリーム全体を分析し、何か悪いものが見つかった場合、両方のRST（送信者と受信者）に送信します。



ただし、トラフィックが多いほど、このようなスキームは適用されません。 処理のわずかな遅延で、ミラーリングされたトラフィックは気付かれずに単に飛行し、プロバイダーは細かいレポートを受け取ります。



ますます多くのプロバイダーが、高速道路のコンテキストでさまざまな程度の信頼性のDPIシステムを導入することを余儀なくされています。



1、2年前、噂によると、ほとんどすべてのFSBがSORM機器の実際の設置を要求し始めました（以前は、ほとんどのプロバイダーがSORM計画を当局と調整することができました-どこかに何かを見つける必要がある場合の運用措置の計画）



お金に加えて（それほど単純ではありませんが、それでも数百万）、SORMは多くのネットワーク操作をさらに必要としました。

• SORMは、NATブロードキャストの前に、ユーザーの「グレー」アドレスを確認する必要があります
• SORMには限られた数のネットワークインターフェイスがあります

したがって、特に、1か所のサーバーにアクセスするユーザートラフィックを収集するためだけに、カーネルの一部をクールに再構築する必要がありました。 SORMの複数のリンクでミラーリングするため。



つまり、非常に単純化され、（左側）対（右側）になりました。







現在 、ほとんどのプロバイダーはSORM-3の実装も必要とします。これには、NATブロードキャストのロギングが含まれますが、これに限定されません。



この目的のために、上記の回路にNAT用の別の機器を追加する必要がありました（最初の部分で説明した機器のみ）。 そして、特定の順序で追加します。SORMはアドレス変換の前にトラフィックを「見る」ため、トラフィックは次のように正確に移動する必要があります。ユーザー->スイッチング、カーネル->アクセスサーバー-> SORM-> NAT->スイッチング、コア->インターネット これを行うには、トラフィックフローを文字通り「展開」する必要がありましたが、これも非常に困難でした。



合計：十数年の間に、コアプロバイダーのコア回路は時々より複雑になり、追加の障害点（機器の形と統合された交換回線の形の両方）が大幅に増加しました。 実際、「すべてを見る」という要件自体は、この「すべて」を一点に減らすことを意味します。



これは、Runetの主権、その保護、安定化、改善に関する現在のイニシアチブに非常に透過的に外挿できると思われます:)



そして、先はヤロバヤです。