この演習の目的はNetworkの状況を把握し、その挙動に関して、更に深い理解を得ることです。
tcpdumpには、色々な利用法がありますが、今回は、その触りだけを紹介します。それだけでも、Networkの挙動に関する、様々な情報が得られます。
参考資料として、以下のURLを乗せておきましょう。
なお、tcpdumpは、単純に言えば「Networkの盗聴機」と同じようなtoolです。Network管理には、便利で、欠かせないと言って良いほど、強力なtoolですが、興味本位で、他の人の通信内容を覗き込む(1)ような使い方は厳禁ですので、心に銘記して置いてください。
tcpdumpの使い方を教わると、怖くてtelnetや、単純なpopなんか使えなくなってしまいます。Webだってもちょっと..
このためにあるのが、「暗号技術」です。telnetの代わりにssh, popの代わりにapop, webでもhttpでなくhttpsを使えば、ちょっと安心かもしれません。
一つのHub ( Switchも可だがHubが望ましい)に1台をLinux-PC ( tcpdumpを利用するため,以下では、Linux-Xとする)として、もう一台Host ( WindowsでもLinuxでもCISCOでも可だが、ここでは、Linuxとし、Linux-Yとする)として、二台接続する。
IP addressは、通信ができれば、なんでも構わないが、迷うのであれば、Network 192.168.1.0/24を利用し、一方( linux-X [tcpdump]側)は192.168.1.1、他方( Linux-Y側)は、192.168.1.2を利用すればよい。
(tcpdump) Linux-X Linux-Y [192.168.1.1] [192.168.1.2] | | >-------+-------------------------------+-----------------------< 192.168.1.0/24
Linux側で、次のようにしてtcpdumpを実行する。
[root@Linux-X /root]# tcpdump -n -i eth0
ここで、tcpdumpのオプションの詳細に関しては、Manpage of TCPDUMPを参照してもらうとして、ここでは、利用しているオプションに関してのみ説明する。
時間があったら、様々なオプション(2)を試してみよう。
TCP Dump中に現れるIP Addressを逆引き( Name Serverを参照)して、Host Nameに変更することをしない。
このNetworkには、Name Serverが設置されていないので、-nを付けず、標準的な振る舞いをさせると、存在しないName Serverに問い合わせをして、時間が無駄になるので、これを避けるためである。
これは、linuxのtracerouteコマンドや、pingコマンドの-nオプションと同じである。
どのInterfaceを通過するパケットをtcpdumpが監視するかを指定するオプション-iにInterface名であるeth0をつけている。
つまり、このコマンドを実行した結果eth0でやり取りされるパケットに関してのみ、tcpdumpが出力を行う。
これは、付けなくても、普通は、eth0を探してくれる(3)のだが、念のためにおこなっている。
tcpdumpの対象となるNetworkには、様々なパケットが流れている。tcpdumpを(オプションを付けずに.. )そのまま利用すると、大量の情報が出力されてしまう。
tcpdumpでは、オプションを上手に指定することにより、目的としているパケットのみを捕らえ、出力することが可能になっている。
もう一台のHost (Linux-Y)から、Linux PC (Linux-X)に対して、色々なNetworkコマンドを実行し、パケットを送ってみよう。
もし、もう一方のHost (Linux-Y)のOSもLinuxであれば、次のようなコマンド(4)を実行して、パケットを送ってみるとよい。
[root@Linux-Y /root]# ping -n 192.168.1.1
[root@Linux-Y /root]# traceroute -n 192.168.1.1
[root@Linux-Y /root]# telnet 192.168.1.1
[root@Linux-Y /root]# /etc/rc.d/init.d/routed start
このようなNetwork関係のコマンドを実行した結果、tcpdumpとして、どのような出力が得られるかを確認しましょう。
RIPのアナウンスは、ブロードキャストなので、他のコマンド( ping/traceroute等)と異なり、特に宛先を指定しなくても、パケットがLinux-Xに届くので、そのパケットを観測することができる。
なお、ブロードキャストなので、SwitchとHubの違いが出ない例であることにも注意しよう。
実験1のNetworkに対して、もう一台Host ( Linux-Z 192.168.1.3とするがもちろん、WindowsでもCISCOでも構わない)を追加する。ただし、接続機器は、Hubでなければならない。
(tcpdump) Linux-X Linux-Y Linux-Z [192.168.1.1] [192.168.1.2] [192.168.1.3] | | | >-------+-------------------------------+---------------+-------< (Hub)
tcpdumpを行うHost ( Linux-X )で、次のコマンドを実行する(6)。
[root@Linux-X /root]# ifconfig eth0 promisc
実験1と同様に、Linux-Xで、tcpdumpを実行し、今度は、Linux-YからLinux-Zへ、様々な通信コマンドを実行してみる。
実験1と実験2の差はどのようなものか?
詳しくは、ifconfigのマニュアルページを参照して欲しいのですが、これによって、このinterfaceは、promisc mode、すなわち、無差別受信状態に変わります。
一般に、unicastで投げられたフレームも、Hubを経由して、Interfaceに受信されますが、そのあて先が自分のMAC addressに該当しないかぎり、Interfaceは、そのフレームを破棄し、CPUに負担をかけない仕組みになっています(したがって、通常は、この状態)。
しかし、今回の応用( tcpdumpで、他のHost間の通信を監視する)では、この機能が働くと、他のHost間の通信を得ることができないので、このような特別な処置が必要になります。
実験2のNetworkに対して、Hubの代わりに、Switchをいれる。
(tcpdump) Linux-X Linux-Y Linux-Z [192.168.1.1] [192.168.1.2] [192.168.1.3] | | | >-------+-------------------------------+---------------+-------< (Switch)
実験2と全く同じ実験を行う。
実験2と実験3の差はどのようなものか?
残念ながら、この企画は、「企画倒れ」であることがわかったので、そのうち改定します。現在は、以下の実験はしなくても結構です。
実験4では、実験2, 3に対して、もうひとつHubを用意して、もとのNetworkに対し、そのHubをカスケード接続する。
更に、そのHubの先にHost (Linux-L)を一台、移動する。
(tcpdump) Linux-X Linux-Y [192.168.1.1] [192.168.1.2] | | >-------+---------------+---------------+-----------------------< | (Hub/Switch) | カスケード接続 ( クロスケーブルを使用 ) | >-------+---------------+-------+-------< Hub | | [192.168.1.3] | Linux-Z 共有ポート(カスケード用)
新規に追加したHubの、共有ポートとカスケードポートの二つにケーブル接続すると、そのHubでは、コリージョンが多発して、通信ができなくなる。これを、高負荷状態と解釈させた上で、次の実験を行う。
この結果どうなるか?