ここ数か月、インターネットが頻繁に停止し、ローカル ネットワーク上のすべてのデバイスに影響が及ぶため、ケーブル モデムの電源を入れ直さざるを得ない状態に陥っています。今日、Blizzard の Battle.net でゲームをインストールすることで、この問題、または同様の症状の類似した問題を再現できることに気付きました。
それは単に帯域幅を飽和させるだけではありません。
- ダウンロード自体も停止し、
- ダウンロード速度を制限しているときにも発生します。
- ダウンロードを一時停止しても自動的には解決されません。モデムを再起動するだけが役立ちます。
インターネット接続がいつ切れるかを正確に知るために、同じネットワークに接続された別のLinuxノートブック（ちなみに私はArchを使用しています）でシンプルなものを実行していますping 8.8.8.8。しかし、インターネットが切れてもpingを続けることができます。実行中のものを停止するときのみピン再起動しても、応答がまったくありません。
この行動にはちょっと困惑しています。また、走ったり並んだりしてみましたping 8.8.8.8がwatch -n1 ping -c 1 8.8.8.8、ピンプロセスが動作し続けると、ピン定期的に再起動されるプロセス時計インターネットがダウンするとすぐに失敗します。
どうしてこんなことが可能なのでしょうか？どうやら「アクティブなpingセッション」は私の障害の影響を受けないようです。しかし、レイヤー3のICMPを使用したpingでは、なぜ維持することと維持しないことの違いがわかりません。ピン新たなスタートを切ることとは対照的に、ランニング。
Battle.net のダウンロードもこの問題の原因になっていることがわかったので、私はすぐに、ルーターを詰まらせている P2P 接続が多すぎるのではないかと思いました。しかし、Battle.net が実際に P2P を使用しているかどうかはわかりませんし、ルーター上でアクティブな接続 (最大 15,360 のうち 3,000 ～ 4,000 の接続)、メモリ使用量などに関して疑わしい点も見当たりません。
残念ながら、私の ISP は適切なインターフェイスを提供していないため、ケーブル モデムからのメトリックを実際に確認することはできません。これが、ブリッジ モードで実行している理由でもあります。
この動作には何か説明がありますか?
編集: Wireshark を使用して ICMP メッセージを確認しました。応答を取得した ICMP エコー要求と応答を取得した ICMP エコー要求の唯一の顕著な違いは次のとおりです。
- ICMP識別子はプロセスに関連付けられており、実行中のプロセスからの要求はピン同じIDを持つ場合、再起動pingからのリクエストは新しいIDを取得します
- シーケンス番号は実行中のサーバから送信されるリクエストごとに増加します。ピン、再起動の場合は1に設定されます
これは非常に予想された動作であり、私にとってはそれ以上の助けにはなりません。結局のところ、これによってリクエストが異なって処理されるのはなぜでしょうか?
答え1
どうしてこんなことが可能なのでしょうか? どうやら、「アクティブな ping セッション」は私の停止の影響を受けないようです。しかし、レイヤー 3 で ICMP を使用する ping の場合、ping を実行し続けることと、新たに開始することの間に違いがある理由がわかりません。
UDP や ICMP エコーのように明示的な状態を持たないプロトコルの場合でも、ルーターはファイアウォールや NAT 機能のために独自の状態を維持する必要があります (たとえば、NAT マッピングを追跡して、エコー応答パケットを返す内部ホストを把握します)。このようなプロトコルの場合、送信する最初のパケットによって状態が確立され、非アクティブ状態が続くとタイムアウトによって状態が削除されます。
TCP と同様に、状態テーブルは UDP パケット フローの送信元と送信先のポート、または ICMP エコー フローの単一の「要求 ID」を記憶します。ICMP にはポート番号はありませんが、エコー要求にはフローを互いに区別するという同じ目的を果たす ID があります (Wireshark でパケット キャプチャを見ると、これがわかります)。つまり、新しいping呼び出しごとに新しい状態エントリが追加されます。
(実際の例として、これを行うと、conntrack -Lコンピューターの iptables/nftables ファイアウォールによって追跡された状態を確認できます。これは、ほとんどの家庭用ルーターが内部で使用しているものと基本的に同じです。ICMPidエコー状態のフィールドに注意してください。)
あなたの問題の説明からすると、ルーターの状態テーブルが「接続」が多すぎるためにいっぱいになってしまい、ファームウェアが古い状態を押し出す代わりに新しい状態を受け入れないように設定されているようです。（公平を期すために、私は考えるそれが Linux conntrack のデフォルトの動作ですか?
問題のあるルーターにバグがあり、クリア状態が保存され、再起動するまでメモリがいっぱいになります。特に、ルータが NAT をハードウェア アクセラレーションにオフロードし、そのオフロードによって状態の削除が壊れている場合はそうです。(もしこれが事実で、ISP が週に 1 回再起動するようにプログラムしているだけなら、まったく驚きません。一般ユーザーにとっては「十分」でしょう。)
Battle.netは最近P2Pを使用しておらず、CDNからのHTTPのみを使用しています（以前はBitTorrentベースでしたが）が、する比較的大量の並列 HTTP ダウンロードを確立し、問題の一因となる可能性があります。
最後に、コメントで述べたように、可能(可能性はわかりませんが) ルーターのファイアウォールがすべてのフィルターおよび/または NAT ルールを失う可能性があります。これは Linux ベースのデバイスでは理にかなっています。実際、iptables は既存の状態の NAT を自動的に処理するため、送信 SNAT または MASQUERADE ルールが何らかの理由で削除されると、新しい接続は確立できなくなりますが、既存の接続は引き続き機能します (状態に既に保存されている情報に従って NAT が継続されます)。
解決方法が見つからない場合は、VPN が回避策になる可能性があります。ルーターが認識できる範囲では、VPN トンネル全体が 1 つの状態としてカウントされます。