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

3.3.1 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.d/routing で以下のようにして IP Forwarding 機能がONになります。

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

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

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

$ /sbin/ping other1
PING pc01.tokyo01.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 というパブリックな コマンドがあります。

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 $\to$ 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 に答えない ようにしている事があります。この場合、traceroute の表示にはそのルータ から返事がない旨が表示されます。勿論、この場合でも、TTLを増やして 次のルータにトライすることは可能です。

参考

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

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



Noriyo Kanayama