web-dev-qa-db-ja.com

非常に奇妙なホームルーターの問題

長い間、自宅のWi-Fiネットワークで非常に奇妙な問題が発生していました。 BT Voyager 2100 ADSLモデム とiMacがあり、老朽化し​​たPowerBookとそれにワイヤレスで接続するPCがあります。問題は、特定のWebサイトが常にタイムアウトするため、それらにアクセスできないことです。

これらのウェブサイトを何らかの方法で接続する明らかなものは何もありません。私が遭遇したいくつかの例は、www.Adobe.comwww.Microsoft.comwww.portsmouthguildhall.co.uk(ローカル会場)およびsubtraction.com (ブログ)。一部のサイトに問題なくpingを実行できます。タイムアウトはありません。実際、以前はsubtractation.comにアクセスできましたが、RSSフィードを取得できます。 Webブラウザでサイトを表示できなくなりました。これは非常に孤立した問題です。私のインターネット使用の大部分では、すべてが正常に機能します。

すべてのコンピューターにこの問題があるため、個々のコンピューターでは明らかに問題ではありません。したがって、ルーターまたはISPのダウンストリームの問題である必要があります。ルーターを最新のファームウェアにアップグレードしてリセットしようとしましたが、問題は解決しませんでした。

問題がどこにあるかを診断するにはどうすればよいですか?どこから始めたらいいのかわからない!使用できるUNIXネットワークコマンドはありますか(Mac OS Xを使用しています)?

助けてくれてありがとう。

編集:Alnitakの提案に従って、tracerouteを試し、Adobe.comでpingを実行しました。ご覧のとおり、tracerouteはそこに到達しません:

$ traceroute Adobe.com
traceroute to Adobe.com (192.150.18.117), 64 Hops max, 40 byte packets
 1  voyager.home (192.168.1.1)  1.975 ms  1.505 ms  1.574 ms
 2  lo0-plusnet.ptn-ag2.plus.net (195.166.128.53)  28.476 ms  47.139 ms  28.036 ms
 3  ge0-0-0-204.ptn-gw02.plus.net (84.92.3.93)  28.520 ms  37.297 ms  33.186 ms
 4  te2-2.pte-gw2.plus.net (212.159.1.106)  35.670 ms  36.262 ms  34.995 ms
 5  80.239.193.141 (80.239.193.141)  33.932 ms  28.600 ms  28.764 ms
 6  ldn-bb1-link.telia.net (80.91.248.90)  29.649 ms  28.149 ms  30.857 ms
 7  ldn-b5-link.telia.net (80.91.249.178)  27.991 ms  28.014 ms  28.490 ms
 8  verio-129583-ldn-b5.telia.net (213.248.100.50)  28.468 ms  29.286 ms  31.702 ms
 9  ae-1.r23.londen03.uk.bb.gin.ntt.net (129.250.5.237)  30.871 ms  29.295 ms ae-1.r22.londen03.uk.bb.gin.ntt.net (129.250.5.233)  28.614 ms
10  ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85)  29.732 ms as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254)  108.909 ms ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85)  28.505 ms
11  ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26)  109.164 ms as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254)  104.860 ms ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26)  111.253 ms
12  as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9)  104.777 ms ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26)  109.973 ms as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9)  108.774 ms
13  as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9)  103.691 ms ae-3.r21.asbnva01.us.bb.gin.ntt.net (129.250.2.128)  104.958 ms as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9)  104.455 ms
14  as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167)  197.595 ms ae-3.r21.asbnva01.us.bb.gin.ntt.net (129.250.2.128)  105.027 ms  106.565 ms
15  * as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167)  179.946 ms *
16  * te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86)  176.374 ms *
17  * * te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86)  189.724 ms
18  * * *
19  * * *
20  * * *
^C

-ホップ14以降でpingを試行しています。ご覧のとおり、最後のpingでは20%のパケット損失があります。

$ ping -s 1492 as-3.r20.snjsca04.us.bb.gin.ntt.net
PING as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167): 1492 data bytes
1500 bytes from 129.250.2.167: icmp_seq=0 ttl=55 time=214.555 ms
1500 bytes from 129.250.2.167: icmp_seq=1 ttl=55 time=215.339 ms
1500 bytes from 129.250.2.167: icmp_seq=2 ttl=55 time=221.211 ms
1500 bytes from 129.250.2.167: icmp_seq=3 ttl=55 time=224.296 ms
^C
--- as-3.r20.snjsca04.us.bb.gin.ntt.net ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 214.555/218.850/224.296/4.062 ms

$ ping -s 1492 as-3.r20.snjsca04.us.bb.gin.ntt.net
PING as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167): 1492 data bytes
1500 bytes from 129.250.2.167: icmp_seq=0 ttl=55 time=299.852 ms
1500 bytes from 129.250.2.167: icmp_seq=1 ttl=55 time=326.598 ms
1500 bytes from 129.250.2.167: icmp_seq=2 ttl=55 time=243.278 ms
1500 bytes from 129.250.2.167: icmp_seq=3 ttl=55 time=214.610 ms
1500 bytes from 129.250.2.167: icmp_seq=4 ttl=55 time=232.900 ms
^C
--- as-3.r20.snjsca04.us.bb.gin.ntt.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 214.610/263.448/326.598/42.517 ms

$ ping -s 1492 te-5-3.r02.snjsca04.us.ce.gin.ntt.net
PING te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86): 1492 data bytes
1500 bytes from 128.241.219.86: icmp_seq=0 ttl=245 time=349.851 ms
1500 bytes from 128.241.219.86: icmp_seq=1 ttl=245 time=270.748 ms
1500 bytes from 128.241.219.86: icmp_seq=2 ttl=245 time=334.406 ms
1500 bytes from 128.241.219.86: icmp_seq=3 ttl=245 time=220.046 ms
^C
--- te-5-3.r02.snjsca04.us.ce.gin.ntt.net ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 220.046/293.763/349.851/51.869 ms

$ ping -s 1492 te-5-3.r02.snjsca04.us.ce.gin.ntt.net
PING te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86): 1492 data bytes
1500 bytes from 128.241.219.86: icmp_seq=0 ttl=245 time=472.908 ms
1500 bytes from 128.241.219.86: icmp_seq=1 ttl=245 time=228.290 ms
1500 bytes from 128.241.219.86: icmp_seq=2 ttl=245 time=231.048 ms
1500 bytes from 128.241.219.86: icmp_seq=3 ttl=245 time=229.906 ms
^C
--- te-5-3.r02.snjsca04.us.ce.gin.ntt.net ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 228.290/290.538/472.908/105.296 ms
5
John Topley

これはMTUの問題のように聞こえます。

あなたとそれらのサイトの間には、通常の1500バイトのMTUをサポートしていない何かがある可能性があり、その上に、「パスMTUディスカバリー」に使用されるICMPパケットをブロックしているファイアウォールがある可能性があります。通常のMTUは使用できません。

Tracerouteを試してから、ホップごとに大きなpingパケット(1492バイト)を送信して、それらのホップのいずれかがパケットの返送を拒否するかどうかを確認します。

編集-tcpdumpビットがパケットで送信されるため、SYN出力はまだTCPの「スリーウェイハンドシェイク」を開始しようとしていることを示しています。ただし、Adobeから返送されるパケットは、切り捨てられているか、形式が正しくないように見えます。パケットにペイロードがあってはならず、遠端のSYN応答だけであるため、これはかなり奇妙です。詳細を知るには、最初の4個程度のパケットの完全なダンプ(-Xオプションを含む)を確認する必要があります。

EDIT2-詳細なtcpdumpに基づいて、ルーターが一部のサイトからのTCP応答を破損していると思います。これをテストする最良の方法は、別のブランドのルーターを借りることです。

7
Alnitak

コンピュータの1つをインターネット接続に直接接続し、ISPからすべてのネットワーク設定を取得できるようにします。サイトにアクセスできない場合はISPの問題であり、アクセスできる場合はルーターの問題であり、そこからアクセスできます。

5
Jared

私は今問題を修正しました、そして結局修正はおいしく簡単でした。 ISP(PlusNet)でサポートコールを記録したところ、 フォーラム投稿 へのリンクが送信され、この問題はルーターのファームウェアのバグであることが説明されました。修正は、ルーターのインターネット接続MTUを1500(デフォルトは1400)に設定して、ルーターのLAN側のMTUと一致させることでした。

ヘルプとアドバイスを提供してくれたすべての人に感謝します。 Alnitakの答えは、彼/彼女が私に固執し、より多くのアドバイスや試してみることがあり続けたという理由だけで受け入れるつもりです。

3
John Topley

traceroute を試して、パケットがどこまで到達しているかを確認できます。彼らがあなたのルーターで止まっているなら、それはおそらくそこで問題です。さらに進んだ場合は、ISPに連絡することをお勧めします。

もう一度質問を読むと、サーバーに正常にpingを実行できるため、tracerouteで異常が発生しない可能性があります...

3
lc.

この問題の基本的な症状は、PATHMTUの問題に関連しているように聞こえるという考えに私は間違いなく同意します。他の可能性もありますが、そこから始めるのが最も可能性が高い場所です。

あなたが言及したサイトの卓越性とおそらくこれが発生している長期間を考えると、それがISPのネットワーク内の問題である可能性は低いようです......質問に示されているtracerouteの結果を考えると、パスの深さと合計遅延は、ISPではあまりよくわかりません。一般的に言って、まともなISPであれば、120ミリ秒未満で(米国内の)主要な/著名なウェブプロパティにアクセスできるはずです...しかし、私は余談です。

他の人が述べているように、traceroutepingを使用して問題を診断することは非常に役立ちますが、与えられた明確なツールソリューションにはほど遠いです。さまざまな場所でのICMPブロッキング/フィルタリングの可能性/可能性。そして、このため、熟練したアナリストの手による場合を除いて、特定の問題とICMPをいじるファイアウォールの違いを区別するのはかなり困難です。

MTUの問題を除外する最善の方法は、問題が発生しているコンピューターの1つでイーサネットインターフェイスのMTUを減らすことから始めることです。あなたがMACコンピュータを持っていると言ったので ここでMACシステムのために にある手順を見てください。

プロセスが一度に100バイトのステップで説明しているように、インターフェイスのMTUを下げ始め、1400から500バイトまで機能をチェックする場合.....いずれかのステップで問題が突然解消された場合は、確かにパスMTUの問題があります。最小で500にドロップダウンしても解決しない場合は、notパスですMTUの問題があり、他の可能性の調査に進むことができます(MTUを開始位置に戻した後...おそらく1500バイトでした)。

3
Tall Jeff

プロキシサーバーを経由しているかどうかについては言及していません。あなたのISPが潜在的にあなたを透過的にプロキシしているかどうかを見るのは興味深いかもしれません。私は非常に悪いと思いますが、それは非常に一般的だと思います。たぶん、 http://tracetcp.sourceforge.net/usage_proxy.html を試して、機能していないホストへのtcpトレースを実行することができます。これは興味深いことです。

それまでの間、プロキシサーバーを経由すると、サイトにアクセスできるようになり、少なくとも回避策があります。

この問題についてISPに連絡してみましたか?

私にとって、tracerouteとpingの結果は完全に正常です。最後に応答がないのは正常です。つまり、ICMP最大ホップ到達応答を送信している最後のHOPです。 tracepathは、mtuの問題を診断するために使用できるユーティリティです。

2

これがPathMTUDiscoveryの失敗に聞こえることに同意します。

私にとって(Linux上で)この問題の解決策は、カーネルで高度なルーターのサポートを有効にし、カーネル構成のnetfilter/corenetfilterセクションでTCPMSSターゲットのサポートを有効にすることでした。次に、最大セグメントサイズを強制的に下げるようにiptablesに指示します。

iptables -t nat -A PREROUTING -p tcp --tcp-flags SYN、RST SYN -j TCPMSS --clamp-mss-to-pmtu

別の方法は、非常に小さいmtuを選択すること(そしておそらくそこから上向きに動作すること)であり、それ自体に問題が生じる可能性がありますが、これらのサイトに到達できるようにする必要があります。

1
dotplus

同様のTCP接続要求パケットをローカルマシンからwww.Adobe.comに送信し(唯一の違いは送信元IPアドレスです)、取得した応答パケットを次のパケットと比較しました。最新のtcpdump。

IP/TCPヘッダーに3つの違いがあります。

  • iPの「DifferentiatedServices」フィールドは、あなたの場合は0x80に設定され、私の場合は0x00に設定されています-これはPlusNetの トラフィックの優先順位付け が原因であると確信しています。
  • オフセット0x20の4バイトは「0000 5012「あなたの場合と」5012 0000"私の場合-これらはTCPヘッダーのデータオフセット、フラグ、ウィンドウサイズフィールドです。あなたの場合、何かがこれらの2バイトの単語を交換しているようです。そしてこれは間違いなく何ですか無効なTCPパケットになります
  • 接続応答要求には、あなたの場合にTCP MSSオプション(値1460)が追加されていますが、私の場合はTCPオプションはありません)

私の推測では、ルーターはMSS TCPオプションを追加することで賢くしようとしますが、場合によってはTCPヘッダーを台無しにします。ルーターには「MSSクランプ」設定-その場合は、それらの設定を無効にしてみます。それ以外の場合は、PlusNetサポートに問い合わせることをお勧めします(tcpdump出力を表示します)。

1
cmeerw

特定のストリーミングオーディオ/ビデオリソースにアクセスするときにルーターがロックするという同様の問題がありました。 WMPネットワーク設定の更新 その特定の問題を解決しました。それがあなたのケースに関連するかもしれないかどうかわからない。

0
An̲̳̳drew