新規
編集
添付| ループバックは戻ってきますか | ping 127.0.0.1 | ループバックが戻ってこないのは接続の問題というよりクライアント側の問題。ループバックはケーブルが差し込まれなくてもpingで戻ってくるはず。ネットワークカードの確認すると同時に、他のマシンでも同じサーバーに接続ができないかを確認してみる。 |
| リンクは立ちあがっていますか | LANケーブルの差し込み口のランプが点灯しているか | HUBにとマシンにケーブルを差し込むととりあえずLAN差込口の横にあるランプが点灯するはず。しなければLANケーブルがおかしいか、OSとの相性がわるい→他のLANケーブルで試してみる、このようなときのために絶対に接続できるはずの（テスタでもOKであり、他のマシンでも使用できていた）ケーブルを複数種類あつめておくとよいかも(todo)→どんな種類のケーブルがあるのか？ |
| IPアドレスは取得できていますか | ipconfig | IPアドレスがあたっている可能性→あたりそうにないIPアドレスを固定で設定してみる、固定で設定できるIPアドレスを確認しておく。DHCPが立ちあがっていない→DHCPサーバーにpingできるか確認してみる、IPアドレスを固定で設定してみる。IPアドレスが無効→ipconfig /renewもしくはIPアドレスを固定で設定してみる |
| EthernetアドレスとIPアドレスの関係は正しいか | arp | ちなみにarpのエントリは同じブロードキャストが届く範囲それともコリッジョンドメインの範囲？arpが設定されるべき範囲で通信ができない場合には１）arpのエントリがない ２）arpのエントリがあるが正しくないと考えられる。１）ならばarpのエントリをarp -sで追加してみる。２）ならば現在あるarpエントリを削除してみる、それだけでもだめならマシンのリブート、それでもだめならarp -sで追加してみる。 |
| TCPコネクションは立ち上がっているか | netstat | netstatで接続ステータスを確認することで3wayハンドシェークのどの段階で失敗しているかがわかる。可能であればお互いのマシンをリブートしてみて、やはり同じ接続ステータスで失敗するか確認する→同じステータスで落ちるというのは考えにくいがお互いのマシンの相性が悪いのかもしれない→この場合には別のマシンならばどうか比較してみるとよい。マシンの相性が悪そうとわかれば、同じ問題が報告されている可能性がある。別のマシンでもおかしいとなれば、クライアントとよりもサーバーに問題がありそうな気がする。というか、とまっているときにどちらが次のステータスを返さないといけないかによる。最後にリプライを出しているマシンからのリプライがおかしいのか、それとも受け取ったけど出さないマシンがおかしいのか |
| DHCPは有効ですか | ipconfig /renew | ipconfig /renewでIPアドレスを取得しなおす。このときにIPアドレスが取得されないならば、1)DHCPサーバにアクセスできないか、2)立ちあがっていない、3)DHCPサーバの設定の可能性がある。DHCPサーバーとルータはおなじ機器であることがおおいために、DHCPが正常に動いていないとLANの外にでられない（例えばインターネットに接続できない）ことがある。 |
| DHCPサーバーにアクセスできない→接続状況の確認 | ||
| DHCPサーバーが正常に起動していない→DHCPサーバーの再起動。ただしルータである場合には、外から確認しても正常に起動しているのか確認しにくい（すべてのランプが正常でもおかしくなっていることがある）ので、とりあえず再起動してしまうとよいかも→そのときにバックアップのネットワークがあるといいかも。 | ||
| DHCPサーバーの設定 | ||
| 自分にpingはとびますか | ping ipconfigで取得できたアドレス | 基本的にはループバックがおかしいときと同じ対応。ただしネットワークカードの確認以外に、正しくIPアドレスが設定されているかをipconfigで確認する。ipconfigでIPアドレスが設定されているのを確認できているのにpingが飛ばないということはありうるのか？→ありうる。Firewallが横取りしている可能性がある。どうやったら横取りされているかを確認できるのか？→etherrealでプロミスキャスモードで確認できる、もしくはループバックインタフェースを監視する(todo) |
| ゲートウェイにpingは飛びますか | ipconfigで取得できたゲートウェイのアドレス | ゲートウェイのリセット、ゲートウェイへ直にクライアントをつなげてみる。これでつながらないようならゲートウェイの設定、クライアントの設定、使っているケーブルのいづれかがおかしい。ゲートウェイの設定についてはまずゲートウェイから外に出られるかを確認する。クライアントについては別のPCではどうか確認する。またゲートウェイへ差し込まれているケーブルを取り替えてみる。これらの対応をしてもよくわからない場合ってあるのか？ |
| 名前解決はできているか | nslookup | 名前解決の設定 |
| 別々の経路だと安定性が変わる | tracert | 異なった経路で社内ネットワークアクセスする可能性は１）無線LAN、２）emobile経由、３）社外からのVPN経由がある。これらについてアクセスが失敗する可能性とその原因についてかんがえてみること。ネットワークはクライアントと接続先が同じであっても、つながり方が違うということは考えられる。つながり方の確認はtracertです。図にしてみるとよいアイデアが浮かぶかもしれません。 |
| すべての設定を確認してもまだおかしい | キャッシュ | サーバー、ルータ、クライアントのいづれかにOSI階層のいづれかのキャッシュが残っている可能性がある。どのようなキャッシュがあるのか、キャッシュを避けるための方法、キャッシュをクリアする方法を確認する(todo) |
=アクセスできるサーバーとアクセスできないサーバーがあった場合
ネットワーク構成を確認してどこにそのサーバーがあるかを確認する 別のサブネットに属している or 別のインターネットに属している
=おかしなサーバーもしくはルータを発見した場合
whoisコマンドで誰のものかを確認する
=単純なネットワーク構成、ホストの設定、データリンクすべてがつながっているのにつながらない場合
ファイアーウォールが仕込まれている
=pingが片方向は飛ぶが逆方向は飛ばない場合
ファイアーウォールが仕込まれている
=ネットワークの問題がどこにあるか切り分けできない場合
なるべく単純なネットワーク構成でテストをするように心がける
=同じLANにあるマシンの間で、特定のマシンからLANもしくはインターネットにアクセスできるが、別のマシンではアクセスできない
サブネットが違っている可能性がある。 サブネットが違っていてもアプリケーションによっては使える可能性があることを覚えておく。 同じネットワークに属しているかは 自分のIPアドレス && 自分のサブネットマスク = 相手のIPアドレス && 自分のサブネットマスク になるかで確認する。
=ネットワークアドレスが重複していることを確認する
割り振ったIPアドレスに紐づいているMACアドレスを確認する （物理的にPCを見ること もしくは ipconfig /all）---(1) arp -sでいったんarpエントリをすべてクリアする ping IPアドレス arp -aでarpエントリを確認する。 上記のMACアドレスが(1)のIPアドレスと異なる場合には、IPアドレスが重複している ただしMACアドレスまでわかっても物理的にどのマシンであるかを見つけるのは難しい。 MACアドレスのパケットをみて、ユーザ名とかを拾い出す アクセスしているファイルサーバーからの絞込み
