☰

uTorrent により DNS が時々機能しなくなる

tag-icon • tag-icon windows utorrent
uTorrent により DNS が時々機能しなくなる

uTorrent の使用中に、DNS が定期的に応答を停止します。

この問題は、帯域幅の使用量 (ルーターからコンピューターまで) が多すぎることに関係しているのではなく、ルーターが提供する何らかのフラッド保護 (Windows が受け入れるよりも多くのルーターへの着信接続) に関係している可能性があります。

ネットワークを正常に動作させるにはどうすればよいですか (もちろん、uTorrent も引き続き使用できます)?

答え1

ビットトレントクライアント積極的に仲間とつながる...一部のルータはこれを SYN フラッドとして解釈します。

オープン接続

uTorrent が読み込まれ、アップロード/ダウンロードが一時停止 (停止ではない) されると、ピアとの接続が維持されます。その間、多数のインターネット ピアが、必要なビットを持っているかどうかを確認するために、引き続き接続を試行します。

最終的には、OS によって課せられたオープン接続制限 (Windows 7 では 10 接続) に達し、新しいクライアントからの接続がルーターでキューイングされ始めます。

キューに入れられたクライアントは、接続が空いているかどうかを積極的に確認します。この積極的なポーリングは、ルータによって SYN フラッド攻撃と解釈される可能性があります。

ソリューション

  • ビットトレントソフトウェアの半オープン接続制限をOSによって課せられた接続制限より低くします。
  • ルーター/モデムで IP フラッド保護を無効にします。

帯域幅の飽和

さらに、uTorrent (または任意のバルク トラフィック) 接続が制限なしで実行されると、アップロード (および場合によってはダウンロード) パイプの使用率が最大に達し、一部の「維持」トラフィックが後回しにされ、ネットワークの有用性が低下します。

次に例を示します。

  1. 高速ダウンロード (torrent など) により、ダウンストリーム リンクが飽和状態になります。
  2. ユーザーは、最近アクセスしていないサイトを参照しようとします。コンピューターは、目的のサイトの DNS 情報の要求を生成します。DNS サーバーへの要求の「アップロード」は成功します (アップストリーム パイプ アクセスは要求されません)。
  3. DNS サーバーは応答します (または応答しようとします) が、ダウンロード パイプがダウンロード コンテンツで飽和状態になっているため、ユーザーのマシンに到達しようとして応答が停止し、何かをドロップする必要があり、ダウンロードが速度の維持に積極的に取り組んでいるため、DNS 応答がドロップされます (ローカル ルーターに到達する前のある時点で)。

アップロードが制限されていない場合にも同じことが起こる可能性があります。アップロードが飽和状態になると、TCP-ACK と呼ばれるパケット (「パケット xyz を正常に受信しました」というタイプの応答として送信されます) がハングアップし、ダウンロードが停止し、Web ブラウジングが非常に不安定になります。

ソリューション

  • 接続の最大能力 (上りと下り、それぞれ) を把握し、バルク転送クライアントの最大速度をその速度の約 80% を超えないように設定してください。これにより、DNS や TCP-ACK パケットなどの「余裕」が確保され、バルク トラフィックをバイパスして迅速に処理できるようになります。
  • 特定のトラフィック (DNS、IMCP Ping、TCP-ACK) を他の形式のトラフィックよりも優先し、一部のトラフィック (特にトレント) を優先順位の低いものにするトラフィック シェーピングを処理できるルーターを使用します。これは私が推奨する方法です。これにより、優先度の高いトラフィックが問題にならない場合に、アップ パイプとダウン パイプ全体をトレント トラフィックに使用できるという追加の利点が得られます。
  • 1 と 2 を組み合わせて使用​​し、「不正な」トラフィックを抑制します。

Linux/BSDディストリビューションのトラフィックシェーピングに関する詳細情報にご興味がおありの場合は、モノウォールそしてIPCopどちらにも有益な情報があります。

答え2

そういうことがあると、ワイヤーシャーク私の親友です。

しかし、まず次の 3 つのことを認識しておくとよいでしょう。

  • ping が機能しているという事実は、DNS (またはその他のサービス) が機能していることを意味するわけではなく、その逆も同様です。

    これは、ping がまったく異なるプロトコル (ICMP、DNS は IP と UDP および TCP の組み合わせを使用) を使用し、まったく異なるレベルのネットワーク モデルを使用しているためです。パーソナル ファイアウォールからルーターの数、サービスが稼働している実際のホストに至るまでのあらゆる要素は、これらのいずれかを破棄し、もう一方を破棄しないように構成できます (管理者の偏執症または何らかの障害の場合)。ただし、通常は ICMP の方が他のものよりもよく発生します。

  • 一般的に、失われているのが (DNS) 要求なのか応答なのかを明確にすることも重要です。

    まあ、使用している特定のプログラムではこれが明確に示されるはずですが、一般的なルールとしては、Wireshark GUI で自分で確認する方が簡単です :)

  • 前述したように、DNS は通常、要求と応答の内容を配信する方法として UDP を使用します。

    兄弟であるTCPとは対照的に、UDPは次のよ​​うに定義されています。保証なし パケットが配信されること、およびルータが失敗を通知するために行う必要のない（または行うことができない）こと。（これは、UDP の別の機能である、信じられないほど高速であることの犠牲になっています。ルータは、送信者やパケットの順序に関する情報を保持する必要がなく、それを迅速に渡して忘れるだけです。ルータは、TCP よりも高い優先度を安全に与えることさえできます。）

通常、私が最初に行うことは次のようになります。

  1. Wiresharkを起動する
  2. キャプチャオプションをクリック
  3. キャプチャフィルタでは、host 1.2.3.4自分と1.2.3.4の間のトラフィックのみをキャプチャするように設定します。
  4. キャプチャを開始
  5. すべてこのように起動したら、コマンドを試してください

ただし、あなたの最後の更新に基づくと、私はこのソフトウェアについては知りませんが、間違いなく uTorrent クライアントを疑うでしょう。アプリケーションが UDP を大量に送信し、たとえば自宅のルーターで何らかの制限に達して UDP パケットを破棄し始める可能性があります。

答え3

私は試してみたいGRC の DNS ベンチマーク ツール. 使用するように設定されている DNS サーバーだけでなく、他の多くの DNS サーバーもテストします。速度だけでなく信頼性もテストします。無料で、インストールする必要はありません (ただし、Windows のみです)。これらのページには、DNS に関する有益な情報も多数掲載されています。

答え4

解決策を見つけましたが、完全には理解していません。誰かが適切に説明できる場合は、回答として投稿してください。他の回答は役に立たなかったので、その人に賞金をあげます。

質問の付録で述べたように、uTorrent が問題に関連していました。uTorrent を閉じると問題が解決したからです。uTorrent を閉じることなく問題を解決する方法を見つけることにしました。このスレッドそしてこれです（そこにいる人たちは同じISPとルーターを持っているので、非常に関連性がありました）無効にすべきだという提案を見つけましたIPフラッド保護ルーターで試したらうまくいきました! 問題と解決策は特殊なもので、おそらくルータ Cisco EPC3925 または特定の ISP (ヨーロッパで人気があるため、英語で Google 検索するのが困難でした) に固有のものでした。

関連情報