next up previous contents
Next: 動的ルーティング Up: 静的ルーティング Previous: 静的ルーティング

IP forwarding

多くのUnixと同じようにFreeBSDでもデフォルトでは routing がされません。 これは、カーネルの IP Forwading 機能がデフォルトでは設定されていない からです。もし、当該ホストが複数のインターフェースを持ち(仮想インターフェース を含む)、ルータにしたいならば IP Forwarding されるように設定しなければ なりません。FreeBSDでは、/etc/rc.conf に以下のように記述します。


gateway_enable="YES"       # Set to YES if this host will be a gateway

ちなみに、この設定をすると起動時に /etc/rc.network で以下のようにして IP Forwarding 機能がONになります。


        case ${gateway_enable} in
        [Yy][Ee][Ss])
                echo -n ' IP gateway=YES'
                sysctl -w net.inet.ip.forwarding=1 >/dev/null
                ;;
        esac

つまり、sysctl -w net.inet.ip.forwarding=1 を手で実行すれば、 再起動しなくても、IP Forwarding 機能はONになる訳です。

設定が完了したら必ずテストをするようにしましょう。テストには、普通 ping コマ ンドを使います。 ping では、相手との通信が出来る場合は、以下のようになります。


$ /sbin/ping other1
PING other1.summer00.wakhok.ac.jp (10.16.128.101): 56 data bytes
64 bytes from 10.16.128.101: icmp_seq=0 ttl=254 time=0.395 ms
64 bytes from 10.16.128.101: icmp_seq=1 ttl=254 time=0.284 ms
64 bytes from 10.16.128.101: icmp_seq=2 ttl=254 time=0.328 ms
64 bytes from 10.16.128.101: icmp_seq=3 ttl=254 time=0.285 ms
64 bytes from 10.16.128.101: icmp_seq=4 ttl=254 time=0.295 ms
64 bytes from 10.16.128.101: icmp_seq=5 ttl=254 time=0.294 ms
64 bytes from 10.16.128.101: icmp_seq=6 ttl=254 time=0.321 ms
^C
--- 10.16.128.101 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.284/0.315/0.395/0.036 ms

ping ではICMPを送り続けるので、終了する時には Ctrl+C を押してください。

ここで、packet loss が異常に多い場合は、ネットワークのトラフィックが 混雑しすぎているか、あるいは何らかのトラブルが考えられます。 まったく通信出来ない場合は、ケーブルトラブルか設定ミスでしょう。

複雑な経路をトレースするには traceroute というパブリックな コマンドがあります。Unix で実装されているtraceroute の仕組みは、 大体以下のようなものです。

FreeBSDでは標準で/usr/sbinに導入されています。


   $ /usr/local/bin/traceroute 202.11.96.17
traceroute to 202.11.96.17 (202.11.96.17), 30 hops max, 40 byte packets
 1  10.16.128.101 (10.16.128.101)  0.631 ms  0.496 ms  0.451
 2  202.11.96.17 (202.11.96.17)  0.738 ms  0.485 ms  0.072 ms

この場合、202.11.96.17 へのルーティングは、10.16.128.101 202.11.96.17 という経路を通っていることが分かります。この経路が、意図した通りかも 確かめておく必要があります。また、TCP/IPでは行きと帰りの経路が異なっていても 構わないのですが、自サイトのネットワークの中で、これが違っている場合は 設定ミスである場合が多いので、片方を調べるだけではなく、双方向で確かめる 必要があります。

ちなみに、traceroute は、UDPパケットを宛て先IPに向けて、TTL(Time To Live) を小さくして(最初は1に設定し、次々と一つづつ大きくしていきます)、 TTL が 0 になるとそれ以上ルーティングされずに ICMP TIME_EXCEEDEDが帰ってくる ことを使って(ルータはTTLを一つ減らし、0になるとルーティングをせずにICMPを 返します)、近い順にルータを探します。従って、ICMP TIME_EXCEEDED を返さない ルータは探索出来ません。

例えば、最近では traceroute をかけられたくないプロバイダーや、プライベート アドレスを経路上のルータに利用している場合に、traceroute に答えない ようにしている事があります。この場合、traceroute の表示にはそのルータ から返事がない旨が表示されます。勿論、この場合でも、TTLを増やして 次のルータにトライすることは可能です。

参考

ネットワーク上のパケットの状態を監視するには、tcpdump があります。 更には、簡単なGUIツールとして ethereal がFreeBSDのパッケージにあります。 これらのツールを使えば、2点間で実際にパケットが流れている のかということや、あるホストからパケットが流れているかということを 調べることができます。パケットの中を全て知る事が出来る訳ですから、 一般ユーザには使用出来ないようにしておかないといけません。また、ネットワークに 接続されたワークステーションからは、こうした packet snooping が可能な訳です から、セキュリティを重視する場合には物理的なセグメントの分割やスイッチの 多用などを考える必要があります。

なお、tcpdump や ethereal を使うには BPF(Berkeley Packet Filter)がカーネル 内で用意され、/dev/bpfN(N=0,1,2...)が用意されている必要があります。 デフォルトでは4つだけ用意されているので、もし4つ以上のツールを同時に使う場合や、 インターフェースを同時に監視する場合、更にはフィルタリングや低レベル パケットロギングなどを行う場合には、 デバイスファイルを必要数だけ確保しなければなりません。 作成には以下のようにします。


    # cd /dev
    # ./MAKEDEV bpf4
    # ./MAKEDEV bpf5
    ...

ちなみに、tcpdump は元は SunOS4.x にあった etherfind に端を発しています (作者が同じです)。SunOS5.x では、snoop というコマンドが用意されています。



Noriyo Kanayama