長い間、自宅のWi-Fiネットワークで非常に奇妙な問題が発生していました。 BT Voyager 2100 ADSLモデム とiMacがあり、老朽化したPowerBookとそれにワイヤレスで接続するPCがあります。問題は、特定のWebサイトが常にタイムアウトするため、それらにアクセスできないことです。
これらのウェブサイトを何らかの方法で接続する明らかなものは何もありません。私が遭遇したいくつかの例は、www.Adobe.com、www.Microsoft.com、www.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
これはMTUの問題のように聞こえます。
あなたとそれらのサイトの間には、通常の1500バイトのMTUをサポートしていない何かがある可能性があり、その上に、「パスMTUディスカバリー」に使用されるICMPパケットをブロックしているファイアウォールがある可能性があります。通常のMTUは使用できません。
Tracerouteを試してから、ホップごとに大きなpingパケット(1492バイト)を送信して、それらのホップのいずれかがパケットの返送を拒否するかどうかを確認します。
編集-tcpdump
ビットがパケットで送信されるため、SYN
出力はまだTCPの「スリーウェイハンドシェイク」を開始しようとしていることを示しています。ただし、Adobeから返送されるパケットは、切り捨てられているか、形式が正しくないように見えます。パケットにペイロードがあってはならず、遠端のSYN応答だけであるため、これはかなり奇妙です。詳細を知るには、最初の4個程度のパケットの完全なダンプ(-Xオプションを含む)を確認する必要があります。
EDIT2-詳細なtcpdumpに基づいて、ルーターが一部のサイトからのTCP応答を破損していると思います。これをテストする最良の方法は、別のブランドのルーターを借りることです。
コンピュータの1つをインターネット接続に直接接続し、ISPからすべてのネットワーク設定を取得できるようにします。サイトにアクセスできない場合はISPの問題であり、アクセスできる場合はルーターの問題であり、そこからアクセスできます。
私は今問題を修正しました、そして結局修正はおいしく簡単でした。 ISP(PlusNet)でサポートコールを記録したところ、 フォーラム投稿 へのリンクが送信され、この問題はルーターのファームウェアのバグであることが説明されました。修正は、ルーターのインターネット接続MTUを1500(デフォルトは1400)に設定して、ルーターのLAN側のMTUと一致させることでした。
ヘルプとアドバイスを提供してくれたすべての人に感謝します。 Alnitakの答えは、彼/彼女が私に固執し、より多くのアドバイスや試してみることがあり続けたという理由だけで受け入れるつもりです。
traceroute を試して、パケットがどこまで到達しているかを確認できます。彼らがあなたのルーターで止まっているなら、それはおそらくそこで問題です。さらに進んだ場合は、ISPに連絡することをお勧めします。
もう一度質問を読むと、サーバーに正常にpingを実行できるため、tracerouteで異常が発生しない可能性があります...
この問題の基本的な症状は、PATHMTUの問題に関連しているように聞こえるという考えに私は間違いなく同意します。他の可能性もありますが、そこから始めるのが最も可能性が高い場所です。
あなたが言及したサイトの卓越性とおそらくこれが発生している長期間を考えると、それがISPのネットワーク内の問題である可能性は低いようです......質問に示されているtracerouteの結果を考えると、パスの深さと合計遅延は、ISPではあまりよくわかりません。一般的に言って、まともなISPであれば、120ミリ秒未満で(米国内の)主要な/著名なウェブプロパティにアクセスできるはずです...しかし、私は余談です。
他の人が述べているように、tracerouteとpingを使用して問題を診断することは非常に役立ちますが、与えられた明確なツールソリューションにはほど遠いです。さまざまな場所でのICMPブロッキング/フィルタリングの可能性/可能性。そして、このため、熟練したアナリストの手による場合を除いて、特定の問題とICMPをいじるファイアウォールの違いを区別するのはかなり困難です。
MTUの問題を除外する最善の方法は、問題が発生しているコンピューターの1つでイーサネットインターフェイスのMTUを減らすことから始めることです。あなたがMACコンピュータを持っていると言ったので ここでMACシステムのために にある手順を見てください。
プロセスが一度に100バイトのステップで説明しているように、インターフェイスのMTUを下げ始め、1400から500バイトまで機能をチェックする場合.....いずれかのステップで問題が突然解消された場合は、確かにパスMTUの問題があります。最小で500にドロップダウンしても解決しない場合は、notパスですMTUの問題があり、他の可能性の調査に進むことができます(MTUを開始位置に戻した後...おそらく1500バイトでした)。
プロキシサーバーを経由しているかどうかについては言及していません。あなたのISPが潜在的にあなたを透過的にプロキシしているかどうかを見るのは興味深いかもしれません。私は非常に悪いと思いますが、それは非常に一般的だと思います。たぶん、 http://tracetcp.sourceforge.net/usage_proxy.html を試して、機能していないホストへのtcpトレースを実行することができます。これは興味深いことです。
それまでの間、プロキシサーバーを経由すると、サイトにアクセスできるようになり、少なくとも回避策があります。
この問題についてISPに連絡してみましたか?
私にとって、tracerouteとpingの結果は完全に正常です。最後に応答がないのは正常です。つまり、ICMP最大ホップ到達応答を送信している最後のHOPです。 tracepathは、mtuの問題を診断するために使用できるユーティリティです。
これが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を選択すること(そしておそらくそこから上向きに動作すること)であり、それ自体に問題が生じる可能性がありますが、これらのサイトに到達できるようにする必要があります。
同様のTCP接続要求パケットをローカルマシンからwww.Adobe.comに送信し(唯一の違いは送信元IPアドレスです)、取得した応答パケットを次のパケットと比較しました。最新のtcpdump。
IP/TCPヘッダーに3つの違いがあります。
私の推測では、ルーターはMSS TCPオプションを追加することで賢くしようとしますが、場合によってはTCPヘッダーを台無しにします。ルーターには「MSSクランプ」設定-その場合は、それらの設定を無効にしてみます。それ以外の場合は、PlusNetサポートに問い合わせることをお勧めします(tcpdump出力を表示します)。
特定のストリーミングオーディオ/ビデオリソースにアクセスするときにルーターがロックするという同様の問題がありました。 WMPネットワーク設定の更新 その特定の問題を解決しました。それがあなたのケースに関連するかもしれないかどうかわからない。