Entries : Category [ network ]
network のトラブル
[PC]  [server]  [network]  [info]  [tips]  [command]  [security] 

10 December
2009

ネットワークトラブルの切り分け I

internet / LAN trouble

google で「インターネットが見られない」と検索
  google: インターネットが見られない
してみました。結果中の典型的なページ http://getnews.jp/archives/24069 をみてみました。今時、流石にこんな牧歌的なことはないとは思いますが....

さて、昨日まではできていたのに、さっきまではみられたのに、「web site が閲覧できない」「メールが突然受信できなくなった」などの「通信障碍」所謂「インターネットが見られない」症状ですが、その原因は多岐に亘ります。先ずは、思いつく限り下記にリストアップしてみました(全然網羅し切れていないと思いますが....)。

明日は、その「切り分け」について書き始めてみたいと思います。

■障碍の原因になりそうなことども
ネットワークケーブル (LAN cable) が抜けている
ネットワークケーブルが接続されている HUB の port の故障
HUB と router 間のネットワークケーブル断線
HUB の故障
router の故障

PC(端末)の network adapter (ether card / WiFi card) の故障
PC の network driver の不具合
PC の network 設定の不具合

internet 接続事業者 (isp / provider) の障碍
internet 接続事業者との契約が切れた
回線事業者 [Wikipedia] の障碍
回線事業者との契約が切れた

DHCP server の障碍
DNS server の障碍
proxy server の障碍
web server の障碍
mail server の障碍

virus に汚染された
firewall software (s/w) の設定ミス


Posted by unchor at 09:42 | Comments (0)
14 December
2009

ネットワークトラブルの切り分け II [case study 1]

internet / LAN trouble: 常に二通りのやり方で試してみる

■目的
下記の「障碍例」と「問題の起源」は現実的にはあん
まりあり得ないのかも知れませんが、ある「障碍」を
例にとって、その原因と問題の探索法を case study
してみようと思います。

今回の方針は「トラブルシュートの方針」に挙げたと
おりです。

■障碍例
ブラウザの home page に設定していた、例えば、
  http://www.nikkei.co.jp/
が閲覧できなかった。さっきまでは、昨日までは問題
なく閲覧できたのに。

■余談
先週重かった web site としては、
  http://www.venusfort.co.jp/index.html
  http://www.nihon-wendies.co.jp/index.html
がありましたみたいです。例えば、上記の site を閲
覧しようとして、(昨日までは問題なく閲覧できたの
に)閲覧できない。

真の原因は、ただ単に日本中から access が殺到して、
web server が応答しきれずに time out していただ
けなのですが、現象としては上記の「障碍例」と同様
に「web site が閲覧できない」となります。

■トラブルシュートの方針
基本方針として、常に「二通りのやり方で検証する」
「複数の方法(チャンネル、ルート)で確認する」を
実践します。

■検証例_1(自分独りでできること): 複数の web site を閲覧してみる

ブラウザで
  X: http://www.nikkei.co.jp/
  O: http://www.asahi.com/news/list.html
を閲覧してみる。

□結果例
X が閲覧不可 O が閲覧可能であった。

□確認できること
外部の web server X 自体が問題であり、自分の PC
/ network / provider には問題がないことが確認で
きます。

■検証例_2(自分独りでできること): 複数の service に access してみる

ブラウザで
  X: http://www.nikkei.co.jp/
  X: http://www.asahi.com/news/list.html
email s/w で
O: email を受信
してみる。序でに自分(若しくは、近場のひと)宛に
O: email を送信
してみる。

□結果例
ブラウザでは一切の web site を閲覧できない。しか
し、email の送受信は問題なく可能であった。

□確認できること
自分に近い firewall / proxy server の障碍の可能
性が高い。network 管理者に help するほうがいいか
もしれない。
もしかしたら、自分の PC の firewall s/w が悪さを
しているかも知れない。

■検証例_3(隣の人に訊く): 複数の端末から web site を閲覧してみる

ブラウザで同じ web site
  X わたくし: http://www.nikkei.co.jp/
  O 隣のひと: http://www.nikkei.co.jp/
を閲覧してみる。

□結果例
X わたくしが閲覧不可 O 隣のひとは閲覧可能であった。

□確認できること
どう考えても自分の PC のなにかがおかしい。

■用語
google: タイムアウト


Posted by unchor at 08:29 | Comments (0)
17 December
2009

ネットワークトラブルの切り分け II [case study 2]

internet / LAN trouble: コマンドを用いた Troubleshooting 1 (LAN)

■トラブルシュートの方針
今回の基本方針は、「近場から遠くに向けて辿ってみ
る」です。具体的には、"ping" command を用いて、
近場から遠くへと、その疎通性を確認してゆきます。

今回は、端末から internet への出口 "default gate
way" までを確認します。

関連する項目は「ネットワークトラブルの切り分け II
[case study 1]
」です。

■障碍例
上記「関連する項目」同様、ブラウザの home page
に設定していた、例えば、
  http://www.nikkei.co.jp/
が閲覧できなかった。さっきまでは、昨日までは問題
なく閲覧できたのに。

■近場_1: 隣の PC
□背景
社内 LAN の配線を把握されている場合は兎も角(な
かなかそうもゆかず....)、隣であるからといっても
必ずしも network 的に隣であるとは限りません。但
し、「一番確認し易い身近」という意味では、先ずの
確認対象としてよいのでは、と思います。

少なくも default gateway よりは近い筈です。

□事前準備
隣の PC の ip address を確認する。確認方法は、隣
の PC の command prompt で、"ipconfig" command
を発行する。

□検証方法
上記事前準備で判明した隣の PC まで "ping" する。

□結果
ping の結果、隣の PC までは届いている場合は、更
遠くでなにか(問題)が起こっていることが解りま
す。隣の PC で同様の障碍(上記「障碍例」参照)が
発生している場合、その確度は高まります。次の検証、
次項 "default gateway" 迄の検証に進みます。

隣の PC で同様の障碍が発生していない場合、問題は、
自らの PC である可能性が高まります。以前の項目
ネットワークトラブルの切り分け II [case study 1]
も参照。

一方隣の PC まで届いていない場合、これは須く自ら
の端末になにか問題が起こっている可能性が高くなっ
てきます。端末内部の問題か、若しくは「端末-HUB
間」が怪しくなってきます。HUB に空きの port (挿
し口)がある場合は、空いている別の port に LAN
cable を挿し替えて再検証することも、切り分けの一
助となります。

□判明しそうなこと
取り敢えず「隣」までは okay だった。では「次の遠
いところまでは?」を検証したい。

■近場_2: default gateway
□背景
default gateway は、大規模複雑な network ではな
い限り、大抵の場合は、internet への出口です。

小規模の network であれば、その具体的物理的な機
器は、「ブロードバンドルータ」であることが多いと
思います。尤も、「ブロードバンド」を冠することは
必須ではなく、要するに router がその役を担うこと
が多いと思います。

無線LAN 環境では、無線LAN を担う中心が「無線LAN
機能つきブロードバンドルータ」ですので、この親亀
がコケると、ぶら下がる全ての機器(子亀)がコケ
internet にでられなくなります。

□事前準備
当該端末の command prompt で、"ipconfig" command
を発行する。

□検証方法
上記事前準備で判明した default gateway まで "ping"
する。

□結果
ping の結果、default gateway までは届いている場
合は、更に遠くでなにか(問題)が起こっているこ
とが解ります。この場合、きっと隣の PC でも default
gateway まではパケットが届いていることと思います。

default gateway まで届いていない場合、前項「近場
_1」同様に「端末-HUB-router 間」が怪しくなってき
ます。

□判明しそうなこと
取り敢えず「router (default gateway)」までは okay
だった。では「次の遠いところまでは?」を検証した
い。

....次回以降に書いてみたいと思います

■用語
google: デフォルトゲートウェイ
google: router


Posted by unchor at 12:04 | Comments (0)
24 December
2009

ネットワークトラブルの切り分け II [case study 3]

internet / LAN trouble: server trouble 1 (dhcp server)

■overview
ネットワークトラブルの切り分け I で挙げた
  ネットワークケーブル (LAN cable) が抜けている
  ネットワークケーブルが接続されている HUB の port の故障
  HUB と router 間のネットワークケーブル断線
  HUB の故障
  router の故障
については、
  ネットワークトラブルの切り分け II [case study 1]
  ネットワークトラブルの切り分け II [case study 2]
辺りでなんとかなった、という前提(現場の trouble
はこんなに教科書的でないのは重々承知ですが、case
by case の事例は case study になかなか乗りづらい
ので、結果 omit 気味であり、それは恐縮です)
で、更なる事例研究です。

■目的
今回は、端末から router (default gateway) より、
もう少し先にあるなにかの trouble について、あり
そうなことを書いてみたいと思います。

具体的には、下記、各種機能を担う server の障碍に
起因する network trouble についてです。

先ずは、「ネットワークトラブルの切り分け I」で挙げた
  DHCP server の障碍
  DNS server の障碍
  proxy server の障碍
の典型例を挙げてゆきたいと思います。

■dhcp server
端末に ip address が明示的に設定されていない場合、
即ち、「ip address を自動的に取得する [google]」
という設定である場合、ip address は dhcp server
によって払い出され、各々の端末に割り当てられます。

このような場合 dhcp server に障碍が発生すると、
internet にでることのできる有効な ip address を
取得することができなくなります。

典型例としては、コマンドプロンプトから ipconfig
command を発行した結果として判明する端末の ip
address が
  169.254.XXX.XXX
などである場合、dhcp server から ip address を巧
く貰えておらず、その結果として、internet にでら
れない、という障碍となっている可能性が高いです。

上記の ip address は "link local address" と呼称
されるらしいです(下記「用語」参照)。

このような場合、コマンドプロンプトで
  nslookp fqdn
  ping fqdn
  ping ipaddress
などとしても、全て error となります。何故ならば
端末から発信されるパケットは、 router 迄も届いて
いないからです。

■troubleshooting
dhcp server は具体的な server がその機能を担って
いる場合もありますが、小規模な LAN では、ブロー
ドバンドルータがその機能を担っている場合もありま
す。前者であれば、server administrator に報告し
て対処願うことになると思います。後者であり、且つ、
当該ルータをリセットできるようでしたらば、それも
対処法の一つかも知れません。

また、端末側に問題がある場合もあります。レジュー
ムから復帰した場合など、端末側の何らかの原因で、
dhcp server と巧く遣り取りできないケースも考えら
れます。この場合、一旦 LAN cable を抜き、暫く
(数十秒?)してから再度挿し、状況を再確認する、
若しくは、端末再起動、で復帰する場合もあります。

■用語
google: dhcp server
google: プライベートアドレス
google: リンクローカルアドレス
Wikipedia: リンクローカルアドレス


Posted by unchor at 09:48 | Comments (0)
14 January
2010

ネットワークトラブルの切り分け II [case study 4]

internet / LAN trouble: server trouble 2 (dns server)

■overview
ネットワークトラブルの切り分けについて、
  ネットワークトラブルの切り分け II [case study 3]
では、比較的 LAN 寄りの DHCP server の障碍につい
て考察してみました。

■目的
今回も、前回同様、比較的近場の server trouble に
端を発するネットワークトラブルの事例について、あ
りそうなことを書いてみたいと思います。

前回は「ネットワークトラブルの切り分け I」で挙げ

  DHCP server の障碍
について書きましたので、今回は
  DNS server の障碍
の典型例を挙げてゆきたいと思います。

■dns server
DNS server が担う役割は、
  DNS server 登録内容: ip address / FQDN を調べる
の項、でも書きましたが、「名前解決」に尽きます。
名前解決とは、
  fqdn ==> ip address
  ip address ==> fqdn
の相互の変換です。前者を「正引き」後者を「逆引き」
とそれぞれ呼称します。具体的には、
  rescue.unchor.com
という fqdn を
  218.219.155.251
と ip address に変換(正引き)する役割を担ってい
るのが、"dns server" です(「逆引き」の例について
は省略)。

reference web site: http://www.atmarkit.co.jp/fnetwork/dnstips/005.html

■case study
dns server の障碍は、簡便な internet の access
に重大な支障を来すため、大抵の network の場合、
dns (cache) server は複数用意されており、client
PC には複数の dns server が設定されています。

余談ですが、当該 dns server が contents server
である場合、これら対象ドメインの名前解決に携わる
複数の dns server は、それぞれ
  primary (master) dns server
  secondary (slave) dns server
  tertiary (slave) dns server
などと呼称されます(secondary と tertiary は機能
的には同格ですが....)。

では、当該端末の名前解決の問い合わせ先として設定
されている dns server が無応答である、という障碍
の場合、具体的には、どのようになるのでしょうか。

その現象は例えば、"nslookup" command での応答が
time out する場合、などで知る、確認することがで
きます。即ち、fqdn が ip address に変換されず、
fqdn による internet 上の様々な resources の利用
ができなくなります。

例えば、apache official site (www.apache.org) の
ip address は
  192.87.106.226
ですが、dns (cache) server が無応答である場合、
この ip address を知ることができなくなり、その結
果、browser にて
  http://www.apache.org
としても web site に access することができません。

Becky! などの email client s/w では、送信 (SMTP)
server、受信 (pop3 / imap) server として、例えば、
  mail.nifty.com
などと設定されているかも知れませんが、これも、dns
server の障碍によって、ip address を得ることがで
きなくなり、その結果、 email の送受信ができなくな
ります。

■切り分け
当該端末に設定されている dns (cache) server の障
碍によって、fqdn から ip address という名前解決
ができなくとも、ip address base では internet と
の通信が、依然可能であることが、本障碍の大きな特
徴です。即ち、browser で
  http://www.apache.org
では apache official site に access できないが、
  http://192.87.106.226
では access できた、というような症状となります。

また、"ping" command による応答も、当然の如く対
象の host から正常に返ってきます。上記の例では、
  ×: ping www.apache.org
  ○: ping 192.87.106.226
という結果となります。

以前の項「ネットワークトラブルの切り分け II [case
study 1]
」では、方策として「常に二通りのやり方
で試してみる」を検証しました。今回のような場合で
は、隣の端末もきっと同一の dns server が設定され
ていることが想定されているため、その症状も同一と
なる可能性が高いです。

■対策
LAN / network の security policy で、internet 上
の dns (cache) server を用いることができる場合、
具体的には、外部 dns port との access が firewall
で遮断されていない場合、端末に設定されている dns
server を一時的に変更することで、問題が解消する
可能性があります。

internet 上に open (public) に公開されている dns
cache server としては、例えば、google のpublic
dns server [official site] があります。設定する
ip address は
  8.8.8.8
  8.8.4.4
です。

■用語
google: dns server
google: 名前解決
google: 正引き
google: 逆引き
google: primary dns server
google: dns cache server
google: dns contents server


Posted by unchor at 09:45 | Comments (0) | Trackbacks (0)
16 March
2010

b-mobile の "Doccica"

mobile access

■背景
弊社業務の一つに server 管理、があります。従いま
して、外出時の PC 携帯はほぼ必須です。

□2000 前後
未だ、PHS での接続がなくて、公衆電話の data port
にモジュラーケーブルを挿して internet に access
して server trouble 対応をしていた記憶があります。
従って、モジュラーケーブルの携帯が必須。

□2001-2008
ntt docomo から "P-in Comp@ct" がリリースされた
のはいつのことだったでしょうか。当時あの小ささで
購入を決断。問題は電波の届く範囲でしたが、地方の
出張でもそれなりに大きな駅などでは使えた記憶が。
しかし、無人の各駅停車しか停まらないような駅だと
流石に圏外。ということで、このときも、モジュラー
ケーブルは持ち歩いておりました。ntt docomo への
月額料金は ¥2,000 くらいでした。

phs ですので、高速移動通信はできず、特急などに乗
っている場合、停車駅でささっとメールを受信して..
..時に容量の大きい添付ファイルがあったりすると、
間に合わず、発車して暫くすると切れてしまう、とい
う感じで使っていたのを懐かしく思い出します。

□2008-2010
ntt docomo の phs service は 2008 年頭に打ち切ら
れましたので、このタイミングで willcom に乗り換
えました。"CH-S203C/TD" という機種で、接続先が三
箇所に限定される形態のものです。接続先は購入時に
電話番号を登録します。わたくしは、確か nifty と
biglobe のみを登録して運用していた記憶があります。
月額は ¥1,000 弱です。

時々伺う場所で、ntt docomo の phs では圏外だった
のが、willcom では接続できたのが嬉しかった記憶が
あります。

□2010-
先日携帯用に netbook を購入しました。しかし、net
book には Compact Flash slot がありません。従っ
て、willcom を使い続けるためには、なにかの手段を
講じなければなりません。

usb <--> CF card の変換ケーブルの購入も検討した
のですが、
  http://www.sun-denshi.co.jp/scc/products/mobile/vs32x/vs32x.htm
¥10,000 程度のコストがかかります。そしてあまり
汎用性がないので、購入を躊躇しました。

ということで、netbook の usb slot を base に移動
通信が可能な手段を research しました。usb であれ
ば、これまでに携帯していた notebook でも共用が可
能です。

■要件
常時接続であれば、emobile でもいいのですが、わた
くしの使用要件は下記の通りです。

・スピードは重視しません
 ssh で server と遣り取りできることが最大の要件。
従って、大容量の帯域は不要です。

・従量制
 1 sec. も使わない月があるので、できれば従量制
を希望。従量制でない場合、一番安い料金プランの月
額コストを重視します。

・対応エリア
 地方の小都市、など、日本全国を cover している
ことが必須。東京の繁華街のみ対応、では使えません。

■結果
ntt docomo の foma network を用いたネットワーク
接続を提供している標記 b-mobile となった次第です。

official web site: http://www.bmobile.ne.jp/personal/doccica/

当初の有効期限は、使用開始後 90日、延長は「¥300
で 30日」若しくは「¥1,000 で 60日と 100 min. 分
のチャージ時間」となります。月額 ¥300-¥500 程
度、ということで、これまでの移動通信に掛かる経費
のなかでも最低で済むようです。

接続は one touch ですし、phs よりは強力な電波で
すので、これまで、窓際まででて接続していたところ
でも、部屋の中央から接続することができました。

なかなか満足です


Posted by unchor at 09:29 | Comments (0) | Trackbacks (0)
[1]