6-2. 経路制御の仕組み '96〜 (1) 経路制御とは * 概要 インタ−ネットの世界での経路情報というのは、道標べと同じである。どこどこへはとも かくこの入り口を行くこと。しばらく歩いていくとまた標識があり、どこどこへはこちら へと導かれる。出発点から見た経路情報は、どこどこは、この入り口を行くことという案 内である。ある町に行くのにバスを乗り継いでいくとしよう。どこそこ方面はこのバスと いう案内でバスに乗っていく。終点に着いたらバス停の案内を見て、またどこそこ方面の バスはこれかと乗り継いでいくのである。結果その町に到着するという按配である。最初 のバス停で、すべての乗り継ぎのバスが分かるのではない。もしそのような情報が分かる ようにするためには、バス停の案内板にはびっちり細かい字で一杯にしなければならなく なるだろう。 コンピュ−タのネットワ−クで上のことを考えてみよう。バス停は先ず自ホストが出発点 で、次のバス停は異なるネットワ−クとの間にあるゲ−トウェイにあたる。ゲ−トウェイ はホストまたはル−タである。ネットワ−クが５本あるとしよう。すると自ホストのバス 停の案内板には、自ホストのネットワ−クを含めて５個の経路情報が書かれることになる だろう。社内のネットワ−クはこれでいい。しかし、インタ−ネットに接続するとなると、 ネットワ−クの数は無数にあるわけだ。この経路情報を全て保持することなんて不可能だ し、ナンセンスでもある。こういう場合、どういう仕組みかよく分からないが、経路情報 を持っているプロバイダのル−タに、後はお任せ−としてしまうのである。 お任せするのをデフォルト経路という。このように TCP/IP ネットワ−クの世界では、小 規模なネットワ−クから、インタ−ネットのような大規模ネットワ−クでも対応できるよ うに設計されている。社内などの小規模ネットワ−クでは、経路情報を手動で設定しても 知れている。静的経路制御といい、"スタティック・ル−ティング" という。 手動でなく て自動で経路情報を作成するやり方もある。 こちらは動的経路制御といい、"ダイナミッ ク・ル−ティング" という。社内ネットワ−クの経路制御を簡単にするには、動的経路制 御を内部ネットワ−クで使い、インタ−ネットへはデフォルト経路を設定することである。 ともかく TCP/IP ネットワ−クの経路制御は、全体を知らなくても通信ができる巧妙な仕 組みになっているといえよう。面白い！。 [ ダイナミック・ル−ティング：動的経路制御 ] RIP( Routing Information Protocol ) というプロトコルを用いた routed デ−モンを使 うのが一般的である。routed をゲ−トウェイで稼働させると、 ２本のネットワ−クの経 路情報を獲得する。２本以上もあるがとりあえず２本ということで。幾つものネットワ− クがある場合、隣接する routed 同士で情報を交換しあい、最終的に全経路の情報をそれ ぞれのゲ−トウェイが獲得することになる。そしてただのホストでも routed を稼働させ ると、隣接する routed からその情報をもらうことができるのである。経路情報はル−テ ィング・テ−ブルとも呼ばれる。 A B C D | G1 | | | G1, G2, G3 それぞれで routed が稼働しているとする。 |―□―| G2 | | G1 は G2 の routed とやりとりする。G3 とはやりとり | |―□―| G3 | しない。G2 は G3 とやりとりし、 G2 は D の経路情報 ■―| | |―□―| を獲得し、 G1 は G2 から C と D の経路情報を獲得す host| | | ることになる。結果 A,B,C,D 全ての情報を獲得する。 | routed デ−モンは一定時間毎に、隣接するデ−モン同士で、 自分の持っている経路情報 を交換しあう。具体的には３０秒毎にル−ティング情報をブロ−ドキャストする。上記の 図で、１つのゲ−トウェイの routed が全部の経路を持つには１分かかることになる。ネ ットワ−ク A にある host はどうだろう。routed で経路情報を獲得するだけでいい。特 に自分から情報を出す必要はない。hostA の routed にできたル−ティング・テ−ブルは、 ネットワ−ク B,C,D への経路は G1 を通っていくのだよ、 先ずは G1 へ行きなさいとい う情報である。アクセス先のホストが D にあるとすれば、G1 へ着いたら G2 へ。それか ら G3 へとパケットは飛んでいくのである。 routed の欠点は、定期的にブロ−ドキャストを出すことでもある。 ネットワ−クの構成 をほとんど変えないような場合、routed はやや無駄なきらいがある。ＩＳＤＮで routed を使うと、ネットワ−クが常時つながった状態になり、ＩＳＤＮを使う意味がなくなって しまうという話もよくある。routed の他、動的経路制御をするデ−モンには gated など 幾つもある。経路制御プロトコルにも、RIP の他に色々ある。特定のメ−カのル−タだけ に実装されているプロトコルや、ＥＷＳでしか使えないプログラムなどもあり、注意が必 要である。一般的には routed さえあれば十分だが、 場合によっては gated を使えると 便利かも知れない。 [ スタティック・ル−ティング：静的経路制御 ] ネットワ−クを変更するたびに手動で設定する必要がある。ネットワ−クがシンプルな場 合は、経路制御の勉強も兼ねて、静的経路制御でやってみよう。 設定には route コマン ドを使う。自ホストの属するネットワ−ク以外にネットワ−クが３本あれば、route コマ ンドを３つ使って設定することになる。これで３本のネットワ−クにぶら下がっているホ ストと通信できるようになる。ネットワ−ク単位でなく、あるネットワ−クの特定のホス トへの経路設定も route ではできる。しかしあまり意味があるとも思えないので、 通常 はネットワ−クへの経路設定でいいだろう。 静的経路にはデフォルト経路というのがある。個々のホストが全てのネットワ−クの経路 情報を持つ必要はない。経路情報を持っているゲ−トウェイ、またはただのホストにパケ ットをとりあえず送って、後はお任せするのである。インタ−ネットなんてのは、無数に ネットワ−クがあるわけで、それをいちいち route なんかで設定できる訳がない。 イン タ−ネットの全ての経路はプロバイダ側のル−タが持っていることになっている。それで 社内のネットワ−クでない所へのパケットは、全部外だということで、デフォルト経路を インタ−ネット接続のル−タにふるわけである。 * 経路情報のモデル ------------ d ネットワ−ク b にあるホストが、ネットワ−ク d にあるホス | トにアクセスできるようにするためのモデル。 ------- Gc' |hostC| a や b は 192.9.200 等というネットワ−ク。 ------- Gc Ga や Gb はホストＩＰアドレスを示す。 | --------------- c | 行き先 Gatewy ------- Gb' --------------- hostB の経路情報 |hostB| |c Gb' ------- Gb |d Gc | ---------------- b 行き先 Gatewy | --------------- hostA の経路情報 ------- Ga |b Ga |hostA| |c Gb ------- |d Gb [ 上記例の完全な経路情報 ] コンピュ−タのネットワ−クは、一方的なアクセスではない。こちらからアクセスすれば 相手側から何らかの反応が返ってくる。上記の経路情報では返って来る標識がないことに なる。hostB と hostC にもちゃんと経路情報を設定しなければならない。 行き先 Gatewy 行き先 Gatewy ---------------- ---------------- hostB |c Gb' hostC |d Gc' |d Gc |c Gc |b Gb |b Gb' * 冗長経路ということ 経路Ｂ -------- -------- routed -q ---------------|routed|---|routed|------ routed -q hostA□ | -------- -------- | □ hostB ｜ --------Ａ --------Ｘ -------- ｜ ---------|routed|---------|routed|------------|routed|----------- -------- 経路Ａ -------- -------- この話を書いておかなければ、インタ−ネットではない。ケ−ブルが核攻撃を受けても他 のケ−ブルで迂回して通信できるように研究されたネットワ−クが、インタ−ネットの前 身だった。上の図では経路ＡとＢがある。通常は経路Ａの方を通ることになる。hostA が hostB にパケットを送る際、途中通過するゲ−トウェイの数が少ない経路を選択する。ゲ −トウェイの数はホップ数とかメトリックという。経路Ａのホップ数は３、経路Ｂは４で ある。経路Ａにあるゲ−トウェイ-Ｘが故障したとすると、ゲ−トウェイ-Ａの routed が 持つ経路情報は、経路Ｂだけになり、パケットは経路Ｂを通っていくことになる。ただし 実際のインタ−ネットでは、routed の RIP プロトコルによる動的経路制御をしているの ではない、BGP-4 というもっと賢いプロトコルを使っている。 * 経路制御プロトコルいろいろ CIDR の所でも述べたが、じつにたくさんの経路制御用のプロトコルがある。 社内で使う のは RIP 一本でいい。内部ネットの設計ではネットワ−クアドレスには、 プライベ−ト ＩＰアドレスを使うのが一般的になった。もはやサブネットがどうのこうの考える必要は ない。それに RIP が Distance Vector 型のアルゴリズムであるとか、雑誌などに書いて あるがそんなことはどうでもいい。万が一サブネットが必要になった場合、RIP バ−ジョ ン２対応の routed、あるかどうか知らんが。または gated のバ−ジョン３を使う。OSPF というプロトコルは VLSM といって、可変長サブネットマスクに対応している。 OSPF は gated バ−ジョン３が対応している。ちょっとここでプロトコルを列挙しておこう。 RIP, HELLOW, OSPF, EGP, BGP, RSVP(帯域制御) PIM ( Protocol-Independent Multicast, Cisco &3Com ) DVMRP( Distance Vector Multicast Routing Protocol ) MOSPF( Proteon-OSPF ), IGRP( Cisco ), BRSA( 3com ) 今後 RIP 以外で関係するとすれば、PIM や DVMRP といったＩＰマルチキャスト・ル−テ ィングかも知れない。マルチキャストはビデオ・デ−タなど量が非常に多いパケットを扱 う。これに関連してイ−サネットの帯域制御をする RSVP も必要になってくるかも知れな い。基本的には HTTP, TELNET, FTP, SMTP などのパケットは RIP 制御でいい。HELLOWか ら BGP なんていうのは１次プロバイダぐらいでの話である。 ところでＵＮＩＸでは RIP は routed がサポ−トする。gated v2 は RIP, HELLO, EGP, BGP をサポ−ト。v3 はOSPF もサポ−トしている。つまり gated は単純に routed の代わりにもなる。賢い routedと しても使うことができる。どんなことができるのか、知っておいても損ではない。 (2) 経路制御コマンド * 経路情報をみる $ /usr/ucb/netstat -rn Routing tables Destination Gateway Flags Hops Ref Use Interface 192.9.201 192.9.200.1 USG 1 0 0 dr0 192.9.200 192.9.200.3 U 0 0 0 dr0 127 127.0.0.1 U 0 0 0 lo0 ※Flags の記号の意味。 U(Up) 動作中、G(Gateway) 送り先がゲ−トウェイ、H(Host) 送 り先がホスト、D(Dynamic) 経路情報はダイナミックに作られた。 $ /usr/ucb/netstat -r Routing tables Destination Gateway Flags Hops Ref Use Interface 192.10.10 node_abcd U 0 0 0 dr0 192.10.20 node_abcd U 0 0 0 eth0 127 localhost U 0 0 0 lo0 オプションで -r のままだとＩＰアドレスを、そのマシンの /etc/hosts を見てホスト名 にして表示してくれる。ホスト名の対応がない場合は、ＩＰアドレスのままとなる。上の 例ではインタ−フェ−スが２つあり、 ２個のＩＰアドレスのホスト名は node_abcd と見 る。Hops はホップ数であり、 192.10.10 と 20 はマシンに直接つながっているネットワ −クなので、ホップ数は０になっている。 * 静的経路を設定する $ /etc/route add net 192.9.201.0 192.9.200.1 1 add net 192.9.201: gateway 192.9.200.1 << 正常な場合の反応。加えた とか削除したとかでる。 $ /etc/route delete net 192.9.201 192.9.200.1 1 delete net 192.9.201: gateway 192.9.200.1 $ /etc/route add host 192.9.201.5 192.9.200.1 1 << ホストの経路を設定する。 ・add, delete : 経路を追加する場合は add、消す場合は delete とする。 ・net,host : ネットワ−クを指定する場合は net。特定のホストを指定する場合は host とする。ホスト指定は普通あまり必要ない。 ・192.9.201 : 通信したいホストがあるネットワ−クの番号。hostを指定した場合は 192.9.201.2 とかなる。 ・192.9.200.1 : ゲ−トウェイの自分側の、ホストのＩＰアドレス。 ・1 : metric ともホップ数ともいう。ゲ−トウェイの数。 * 動的経路を設定する routed デ−モンは主にゲ−トウェイのホストで稼働させる。 隣接する他のゲ−トウェイ の routed と経路情報のやり取りを行う。 ゲ−トウェイでないただのホストでも routed を経路情報を受けるのみで使うこともできる。 この場合 routed -q というオプションを 付けておく。 また routed は起動時に /etc/gateways ファイルを見るようになっている。 これにより静的経路を付加できる。/etc/gateways を使う場合は、 active 指定はせずに passive 指定して、設定した経路は消えないようにした方がいいだろう。静的経路は例え ば Apollo では /etc/rc.local でも追加できる。 しかし、何らかの都合で route -f と やり経路情報をクリアした場合、/etc/rc.local での設定は消えてしまう。 /etc/rc.local << 以下 Apollo の起動スクリプトでの記述。 ------------------------------------------------------- |if [ -f /etc/routed -a -f /etc/daemons/routed ]; then | /etc/routed -f << これを設定するだけ。-f は Apollo 特有で、経路情報 |fi をフラッシュする。他ＥＷＳにも同じ機能があるかも。 | |# if [ -f /etc/route ]; then 静的経路の指定 |# /etc/route add |# fi /etc/gateway ------------------------------------------------------- |net 192.9.201.0 gateway 192.9.201.1 metric 1 passive << ネットワ−クへの |net 192.9.202.0 gateway 192.9.201.1 metric 2 active 経路。 |host 192.9.203.1 gateway 129.9.201.1 metric 3 passive << ホストへの経路。 ↑ ↑ ホストまたはネットワ−ク ゲ−トウェイ * コマンドの使い方 $ /etc/routed << 手動で動的経路制御デ−モン routed を起動させる。 経路 情報の発信と受信をする。 $ /etc/route -f << 経路情報を自インタ−フェ−ス分だけにする。routed での 静的経路と、獲得した動的経路の情報は消される。 $ /etc/routed -q << 経路情報を受けるだけ。ただのホストなどで使う。-s だと 経路情報を発信するだけ？（未確認）。 $ /etc/routed -t << routed の動作を画面に出す。動的経路制御は有効である。 REQUEST to 192.9.200.255.0: dst 0.0.0.0 metric 16 REQUEST to 192.10.10.255.0: dst 0.0.0.0 metric 16 RESPONSE to 192.9.200.255.0: dst 192.9.200.0 metric 1 dst 192.10.10.0 metric 1 最初はダ−と経路情報を獲得し、自分も出す。その後は３０秒毎に情報を出す。注意深く みると、それぞれの routed が送ってくる経路情報が分かる。デバッグに使える。表示を 止めるのは Apollo では Ctrl+Q を押す。INDY IRIX 5.3 でも %routed -t をやってみた。 表示は少し違っていた、止めるのは Ctrl+C とやる。 * 経路の確認 ＵＮＩＸには traceroute というコマンドがあり、相手ホストまでのゲ−トウェイ経路を 調べることができる。但し行きの経路しか出ないので、戻りの経路も知りたければ相手ホ ストからも traceroute をやることになる。社内ネットワ−クではそう使う必要もないと 思うが、インタ−ネットのＷＷＷサ−バなどのホストへのアクセスで、経路がどうなって いるのか知りたい場合などにやってみるとよい。 hostD □ Windows 95/98 にはＤＯＳモ− ｜.2 ドに、tracert.exe という同等 ---------------------------------- 192.9.202 のコマンドがある。その後出て ｜.1 きた Windows 2000 にもあった。 hostC □ ｜.2 ------------------------------- 192.9.201 ｜.1 INDY ホスト名なし□ hostA □ ここから hostD に traceroute コマンドを打った。 ｜.2 ｜.1 ------------------------- 192.9.200 hostA % traceroute 192.9.202.2 traceroute to 192.9.202.2 (192.9.202.2), 30 hops max, 40 byte packets 1 192.9.200.2 (192.9.200.2) 2 ms 2 ms 2 ms 2 hostC (192.9.201.2) 2 ms 2 ms 2 ms 3 hostD (192.9.202.2) 8 ms 6 ms 7 ms 時が経ってパソコンは Windows 2000 でのこと、 tracert の他に同等の機能で pathping というのも入っている。各通過点でのパケットの遅延時間と喪失率が出て来る。途中で遅 延時間が大きくても到達点での遅延時間が小さければ、ネットワ−ク的には問題はないと いうこと。LinkProof をかましたネットワ−クで、遅延時間がこのように異なる場合が実 際あって業者におかしいんじゃないかと問い合わせたことがある。もう一つWindows 2000 の ping に経路情報を出すオプションがある。> ping -r 9 xxx とやる。このオプション、 いつまであるか分からないという噂もあったり。この ping.exe をどこかにコピ−してた 方がよさそうである。どうも traceroute or tracert、pathping、ping -r 9 はおかしい。 traceroute で出て来ないル−トも ping -r 9 だと出て来る場合がある。IP-VPN網を介す るネットワ−クで、どこを通っているのだとやっていた際に出た現象である。 ping -r 9 も、何かすると反応せずに Request timed out. になってしまうし。 * 静的経路の設定例 □ hostD hostA から hostDにアクセスできるように ｜.2 する。下は hostAの最初の経路情報である。 ---------------------------- 192.9.202 hostA 以外はちゃんと経路情報の設定はな ｜.1 されているものとする。 hostC ■ ｜.2 例えば hostBの静的経路は次のようである。 ------------------------ 192.9.201 %route add net 192.9.202 192.9.201.2 1 ｜.1 hostB ■ □ hostA ｜.2 ｜.1 -------------------- 192.9.200 % netstat -rn << ＩＰアドレスで表示する。hostA での設定。 Destination Gateway Flags MTU RTT RTTvar Use Interface 127.0.0.1 127.0.0.1 UH 0 0 0 1402 lo0 192.9.200.1 127.0.0.1 UH 0 0 0 118 lo0 192.9.200 192.9.200.1 U 0 0 0 170 ec0 [ 途中経路は hostB の経路情報にお任せする場合 ] % route add net 192.9.202 192.9.200.2 2 % netstat -r Destination Gateway Flags Interface 192.9.200 hostA U ec0 192.9.202 192.9.200.2 UG ec0 注．自ホストに隣接するゲ−トウェイのインタ−フェ−ス 192.9.200.2 を gateway とし て指定すること。% route add net 192.9.202 192.9.201.2 2 というのはダメである。 [ デフォルト経路を使う場合 ] メトリック ↓ % route add net 0.0.0.0 192.9.200.2 1 注．この場合 192.9.200.2 を指定すること。メトリックは 1 を指定すること。hostB の 向こう側インタ−フェ−スの 192.9.201.1 は指定しないこと。手前側を指定する。 % netstat -rn Destination Gateway Flags .. Interface default 192.9.200.2 UG .. ec0 << 注目。 192.9.200 192.9.200.1 U .. ec0 (3) 経路制御いろいろ * routed の /etc/gateways を詳しく調べる [ 基本的な性質 ] ちょっとした実験をやってみた。ゲ−トウェイのホストＡはインタ−フェ−スを２つもっ ている。ホストのＢは実際には存在してない。 これでＡから /etc/gateways ファイルで、 192.10.40 への経路を active モ−ドで設定してみた。routed を起動した直後は、 この 経路情報は netstat で確認できる。 しかし３分程経つと経路テ−ブルから消えてしまう。 passive モ−ドだと消えないわけだ。 他、注意点は 192.10.40 への経路を設定したのが、 になっていることである。 ------------------- 192.10.40 ｜.2 Ｂ □ ｜.2 ------------------- 192.10.30 ｜.1 Ａ ■ routed ｜.1 ------------------- 192.10.20 /etc/gateways ---------------------------------------------------- |net 192.10.40.0 gateway 192.10.30.2 metric 1 active |#net 0.0.0.0 gateway 192.10.30.2 metric 1 active 注．active を passive にすると gateways の経路情報を routed は送らない。何も記入 しないと、active とみなすようである。Apollo で確認した話。 $ /usr/ucb/netstat -rn Destination Gateway Flags Hops Ref Use Interface 192.10.30.2 UG 1 0 0 dr0 192.10.30 192.10.30.1 U 0 0 0 dr0 192.10.20 192.10.20.1 U 0 0 0 eth0 $ /etc/routed -d /nix/katou/ddd action dst 0.0.0.0, router 192.10.30.2, metric 1, flags UP|GATEWAY state REMOTE|CHANGED action dst 192.10.30.0, router 192.10.30.1, metric 0, flags UP state INTERFACE|CHANGED action dst 192.10.20.0, router 192.10.20.1, metric 0, flags UP state INTERFACE|CHANGED | *** Packet history for interface dr0 *** Output trace: この間は 192.10.30 へブロ−ドキャス Fri Sep 24 16:07:17 1999: metric=0 トを送り、返事してくれ−とやっている。 REQUEST to 192.10.30.255.0: しかし実際Ｂホストはないから、あきら | めて 0.0.0.0 への経路は metric 16 と Fri Sep 24 16:09:26 1999: metric=0 して、無効にしている。 Input: no packets. action dst 0.0.0.0, router 192.10.30.2, metric 16, flags UP|GATEWAY state REMOTE [ これはどうなるか ] ホストＧを加えて、Ａから経路情報をもらうようにする。Ｂの先は例えばインタ−ネット で、Ａはデフォルト経路をＢにしてある。マシンＡが止まったり、Ｂが故障したりすると、 Ａの gateways でのデフォルト経路はなくなって、その情報はＧにも波及することになる。 もしＡ'というのがあって、同じく gateways で 0.0.0.0 経路を metric 2 で設定したら どうなるか。ひょっとするとＡがこけて、 しばらくしたらＧからのデフォルト経路はＡ' 経由になるのでないか。 これは冗長経路の話になる。残念ながらこれは未確認である。 ： Ｂ □ ｜.2 ---------------------- 192.10.30 ｜.1 ： Ａ■ routed ■Ａ' ｜.1 ： ---------------------- 192.10.20 ｜.5 Ｇ ■ routed -q Ａ /etc/gateways ------------------------------------------------ |net 0.0.0.0 gateway 192.10.30.2 metric 1 active << metric を 2 にすると Hops は 3 になる。 Ｇ $ /usr/ucb/netstat -rn Destination Gateway Flags Hops Ref Use Interface 192.10.30 192.10.20.1 UG 1 0 0 eth0 << これ余分な気が 192.10.20.1 UG 2 0 0 eth0 せんでもない。 192.10.20 192.10.20.5 U 0 0 0 eth0 * ル−タによる冗長経路 ちょうど上のような構成の場合、ル−タを使えばメ−カ独自の専用のプロトコルで、冗長 経路を作ることができる。 Cisco のル−タには HSRP( Hot Standby Routing Protocol ) というのがある。ル−タのインタ−フェ−スには、一応ちゃんとＩＰアドレスを付け、仮 想のＩＰアドレスも振る。他のホストからは、その仮想ＩＰアドレスが見えることになる。 そのように２個、Cisco のル−タを設置し、インタ−フェ−スにプライオリィティを付け る。他のホストではこの仮想ＩＰアドレスをデフォルト経路として指定する。レイヤ３ス イッチの Accelar 1000 シリ−ズも同様な機能をサポ−トしているようで、こちらはVRRP ( Virtual Router Redundancy Protocol )という。HSRP はメ−カ独自、VRRP は一般的な プロトコルである。Summit には ESRP( Extreme Standby Router Protocol ) というのが ある。経路制御の OSPFでもネットワ−クの冗長化はできるが VRRP 等の方が簡単である。 下の図はレイヤ３スイッチ(Ｌ３)２台を使って VRRP を構成したものである。バ−チャル ＬＡＮ切ってプライオリティを設定してある。PC1 とPC2 間のパケットは L3-1 の方を通 常は通ることになる。装置はレイヤ３スイッチでなくてもル−タならばバ−チャルＬＡＮ は関係なく、インタ−フェ−スにＩＰアドレスを振ればいいだけである。当初は VRRP と OSPF をごちゃまぜに考えていた。別物である。図ではパソコンにはデフォルト経路をA.2 とかしているが静的経路のゲ−トウェイと見ても同じである。 PC1△A.9 デフォルト ｜ 経路は A.2 注、ここではＬ３を２台使用したがひょっと ------ してＬ３は１台でも VRRP ができるのでない 優先値 --------|HUB |------- 優先値 か。Ｌ３はル−タの集まったもので、ポ−ト (20) ｜ ------ ｜ (10) １つだけでもル−タとして機能するのだから。 vlan2｜A.1 A.2 A.3｜vlan2 ----■----- □ ----■---- | | | | | L3-1 | | L3-2 | ----■----- □ ----■---- vlan1｜B.1 B.2 B.3｜vlan1 (20) ｜ ------ ｜ (10) --------|HUB |------- ------ 仮想ＩＰ ｜ デフォルト A.2, B.2 PC2△B.9 経路は B.2 * デフォルト経路の動的設定 IRDP( ICMP Router Discovery Protocol )というプロトコルが、ネットワ−クの冗長構成 をする際に有効に使えるかも知れない。インタ−ネットへの接続回線が２本あって１つの ル−タＡが稼働、もう１つのル−タＢがスタンバイしているような場合。ル−タＡ側に何 かトラブルがあってル−タＢに切り換えたい。内部の一般コンピュ−タのデフォルト経路 は、先に稼働していたル−タＡに向いている。これをル−タＢに振り換えたいわけである。 このような場面でこの IRDP がうまく働くようである。 デ−モンとしては rdisc という。 このデ−モンは動的にデフォルト経路を管理する働きをするもので、オプションの指定に より、クライアントとサ−バとになる。サ−バになった rdisc は、 ある時間間隔でデフ ォルト経路をクライアントにアナウンスするのである。Windows のＯＳには、rdisc 相当 の機能はないようだが。「UNIX MAGAZINE」1998/05, P.55〜58, "DAEMONS&DRAGONS IRDP" を詳しくは見られたい。rdisc の記事は、小生が知る限りこの記事しかなかった。 [ INDY IRIX 5.3 の man での表示 ] rdisc - Internet router discovery daemon マルチキャストを使ってアナウンスする。 /usr/etc/rdisc [ -sfa ] Solaris 2.6 にもこのデ−モンはあった。 /usr/etc/rdisc -r [ -p preference ] [ -T interval ] * パケットの経路の特殊なケ−ス `22/12 ■ WWW -------- Ｂ WWW ■ B.x 正式なパ ↓｜ ↑ ｜ 正式なパブ ｜ ブリック -------○------- WWW □ リックＩＰ -----------○--- ＩＰのサ | ↓ | ■ ↑： | | イト | ←△経路Ａ | ↑｜ ↓ ： |インタ−ネット| | ↓ | ---○------○--- -------○------- ---●------○--- | ↓ ↑ | ： ↓：P Q：↑ | △ → | ： ： ： | 経路Ｂ | □ 勝手なパブ □ ■ Router ---○----------- ｜ リックＩＰ ｜ ｜ ↑： ---------------- Ｂ ---------------- Ａ ： ホストB.1 以外の ｜B.1 ｜B.2 ↓ A.1｜ ↑ □ B.x は、外へ行く □ □ → □ → ｜ と設定したら Default Route ---------------- Ｂ B.1 から B.x にはアクセスで ↑ ｜B.1 勝手なパブ きない。 ロ−カルのＢセグメ ＡはパブリックＩＰ ← □ リックＩＰ ントにしかアクセスできない。 [ パタ−ン１ ] [ パタ−ン２ ] [ パタ−ン３ ] △経路何某というのは、インタ−ネットの中でのル−ティング経路を示す。△はインタ− ネットでのル−タのつもりである。△経路ＡというのはパブリックＩＰのネットＡであり、 例えば 202.241.128.0 というＩＰアドレスのネットワ−クを示す。 ●ル−タはインタ− ネットからネットワ−クＡ 202.241.128.0 へ通ずるただ一つのル−タである。■ Router のＷＡＮ側には、 Ａとは別な 202.241.129.2 というようなパブリックＩＰがプロバイダ から割り振られ、これへの経路があることになる。 パタ−ン１は、最初プロバイダ P と接続し、後からプロバイダ Q と接続したような場合 である。P は専用線 128 Kbps、Q は ADSL 1.5 Mbps という具合である。プロバイダ Pか らは、パブリックＩＰアドレスのＡを付与されていたとする。Q ではパブリックＩＰアド レスをＷＡＮ用に１個だけ。インタ−ネットにおけるＡへのル−ティングは、ル−タ●を 通って入って来る。A.1 でのデフォルトル−トをル−タ■にすると、パケットは上記のよ うにぐるっと回って来る。 * 静的経路にネットマスクを含める `23/11 昔のＵＮＩＸマシンは静的経路の設定に際してネットマスクは指定することができなかっ た。Apollo も INDY IRIX 5.3 もできなかった。Solaris 2.6 でもだめかと思っていたが、 # man route を見たら -netmask の記述があったので、やってみたらできた。普通、社内 のネットワ−クでネットマスク指定をすることはないだろう。たいがいクラスＣのネット ワ−クを使うはずで、route コマンドは暗黙にクラスＣのネットマスクにするからである。 参考、Solaris 2.6 の man route マニュアルに書かれていた事。The optional -netmask qualifier is intended to manually add subnet routes with netmasks different from that of the implied network interface. The implicit ... ある大手取り引き先がフレッツ・オフィスのネットワ−クを今後使うということで、ネッ トマスクを含めた静的経路を設定する必要がでてきた。実は先に、ネットマスク指定せず に静的経路を設定したところ ping も通らなかった。仕方なく 192.168.50.114 ホストを 指定した静的経路を設定した。ネットマスクは指定しなくても、通信できるような気がす るのだが。BB-Router のアライドテレシスの AR230E の癖なのかも知れない。あるいは厳 密な処理をするということで、ネットマスクもちゃんと入れないといけないということか。 BB-Router の取り引き先側のＩＰアドレスを便宜的に 192.168.50.113 と書いてはみたが、 向こう側はどうなっているか分からない。 hostG# route add net 192.168.50.112 -netmask 255.255.255.240 202.241.128.9 1 add net 192.168.50.112: gateway 202.241.128.9 hostG# netstat -rnv << オプション v を追加指定するとネットマスクまで出て来る。 IRE Table: Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd -------------- --------------- ------------- ----- ----- --- --- --- ----- ----- 202.241.128.3 255.255.255.255 192.168.2.1 1500* 0 0 UGH 1826 0 202.241.128.4 255.255.255.255 192.168.2.4 1500* 0 0 UGH 3127 0 192.168.50.112 255.255.255.240 202.241.128.9 1500* 0 0 UGH 70 0 202.241.128.0 255.255.255.0 202.241.128.2 hme0 1500* 0 2 U 617 0 192.168.2.0 255.255.255.0 192.168.2.2 hme2 1500* 0 2 U 1142 0 192.168.1.0 255.255.255.0 192.168.1.2 hme1 1500* 0 2 U 3889 0 default 0.0.0.0 202.241.128.1 1500* 0 0 UG 14811 0 | △取り引き先ＷＷＷ インタ−ネット ｜.114 ： 仮想ＩＰ ------------------ network 192.168.50.112 ： アドレス ｜.113 netmask 255.255.255.240 ■Router □WWW' □Web' ■BB-Router このネットワ−クの有効ホ ｜.1 ｜.3 ｜.4 ｜.9 ストＩＰアドレス113〜126 ------------------------------------- 202.241.128.0 .2|hme0 ------- □WWW □Web WWW ホストは Mail-Relay, |hostG|hme2 ｜.1 ｜.4 WWW, DNSサ−バ。 | |------------------------ 192.168.2.0 -------.2 □Mail-Store Webホストは Web-Mailサ− .2|hme1 ｜.1 バ、Cobalt Qube3。 ------------------------------------- 192.168.1.0 (4) gated をちょっと試してみる * Apollo に入っていた gated 何と、Apollo には gated もソ−スコ−ドで入っているのだ。rfc/ には RFC ドキュメン トも入っている。src/ にソ−スがあるので /bin/make とやればすぐに gated はできる。 conf/ には gated.conf の簡単な設定サンプルもある。 $ wd /domain_examples/tcp/gated2/ $ /bin/ls -F Acknowledgements Licensing man/ Changes README rfc/ Copyright aux/ src/ Installation conf/ $ wd conf; ld gated.conf.bgp-simple gated.conf.egp-simple1 gated.conf.egp-simple2 gated.conf.rip-simple gated.conf.rip-simple << これを /etc/gated.conf としてコピ−。 -------------------------------------------------- |# Config file gated-alpha on risci |traceoptions internal external route rip update ; |rip yes ; |snmp no ; $ wd src << make してコンパイルする。gated に -t を付けてデバッグ・モ−ド $ gated -t で実行してみた。gated.conf に間違いがあるとストップする。 Sep 22 17:06:29 Tracing flags enabled: general internal external route Sep 22 .. Start gated[1777] version 2.0.1.4 built Thu Nov 29 11:35:03 EST 1990 Sep 22 17:06:29 Sep 22 .. init_if: interface name dr0 address 192.10.10.5 Sep 22 .. init_if: interface dr0: up addr 192.10.10.5 metric 0 index 1 preference 0 Sep 22 .. init_if: interface dr0: broadaddr 192.10.10.255 Sep 22 .. init_if: interface dr0: net 192.10.10.0 netmask 255.255.255.0 Sep 22 .. init_if: interface dr0: subnet 192.10.10.0 subnetmask 255.255.255.0 Sep 22 .. init_if: interface dr0: flags | Sep 22 .. parse: /etc/gated.conf:7 syntax error at '}' Sep 22 .. parse_parse: 2 parse errors << gated.conf をちょっといじったとこ Sep 22 .. Exit gated[1777] version 2.0.1.4 ろ、エラ−で gated がストップした。 % gated -t << INDY IRIX 5.3 でやってみた。バ−ジョンは Apolloよりも古かった。 Tracing flags enabled: general internal external route egp Start gated[11311] version 1.9.1.3 at Fri Sep 17 15:44:03 1999 init_options: Reading configuration protocol options: RIP options: yes HELLO options: yes /etc/gateways ファイルは最初から入っていた。 EGP options: no | * gated の簡単な使い方 参考資料としては、「UNIX MAGAZINE」'93/04, P.47〜 "UNIX Communication Notes,経路 制御の仕組み(4)" しか知らない。 routed の問題点と gated の設定方法が詳しく紹介さ れている。インタ−ネットでも探してみたが、めぼしいのはなかった。gated のサイトは http://www.gated.org/ であり、'99/09 時点のバ−ジョンは 3.5 になっている。以下は Apollo に入っていた gated で routed の代わりをさせる設定である。試す時は現在の経 路情報を $ route -f でクリアしておこう。そして $ gated -t でデバッグモ−ドで起動 し、$ netstat -rn で経路情報がどうなったか確認する。Apollo の gated ではデバッグ モ−ド中に、Ctrl+Q を押すと /usr/tmp/gated_dump に詳細な情報が記録される。 % routed ＝ % gated /etc/gated.conf ------------------ |rip yes; % routed ＝ % gated /etc/gated.conf % route add net ------------------ 0.0.0.0 192.168.10.1 |rip yes; |HELLO no; 指定しなくてもデフォルトは no。 |EGP no; 大文字でもいい。 |static { | default gateway 192.168.10.1; |}; 上記の簡単な使い方の他、gated は RIP のまま賢い使い方ができる。 同じネットワ−ク にいくつかのゲ−トウェイがある場合、やりとりする RIP 情報を選択したり、 ゲ−トウ ェイに優先順位を付けたりすることが可能である。routed 同士では、 ともかく来た RIP 情報は受けるしかない。gated の優先順位の設定では複数の経路がある場合に、プライマ リとセカンダリ経路というようにできる。これは具体的には preference という値で、ゲ −トウェイに重み付けするのである。preference は gated 特有で、 routed のメトリッ クみたいなものである。gated では先ず preference 値を評価し、次にメトリック数を評 価するようになっている。 * 高度な経路制御が必要になった時に `22/12 ＷＡＮの IP-VPN による広域ＬＡＮ形態の普及などにより、その回線冗長化として、複数 のプロバイダへ接続する企業が大手をはじめとして出てきた。その場合にプロバイダ間で 経路制御するのが BGP-4 というプロトコルである。 これは、従来プロバイダ専用の経路 制御プロトコルでユ−ザには関係がなかった。それが、このようにユ−ザで実際使える場 面が出てきたのである。小規模なロ−カルエリア・ネットワ−クでは、経路制御はデフォ ルトル−トとスタティックル−トさえ設定すれば済んでいた。しかし今後は、ネットワ− ク装置やＷＡＮ回線の低価格により、内外でのより安定したネットワ−ク構築、かつセキ ュアなネットワ−ク構築が求められてくると思われる。関係するキ−ワ−ドを元に雑誌な どの記事を拾ってみた。また、参考にする時が来たら読み返してみたい。 「ＣＴＣテクインフォ」'97/07,VOL.20 の P.17〜。Cisco ル−タの HSRP の設定が掲載。 > この雑誌はＣＴＣと保守契約を結んでいると送られてくる 「ＣＴＣテクインフォ」 2002/03, VOL.36, P.23〜26。 > "CISCO ワンポイントレッスン第２７回、ポリシ−ル−ティングを設定しよう"。アプリ ケ−ションによって経路を変える。発信元ＩＰアドレスによって経路を変える。 「iij.news」 IIJ のパンフレット。経路制御の話がところどころに書かれている。 > http://www.iij.ad.jp/iijnews にも PDF でバックナンバ−がある。 「UNIX MAGAZINE」 2001/07, P.102〜103。Summitの記事、複数の経路プロトコルを使って、 > ネットワ−クに障害が起きた際に、代替経路を自動で設定できるという話がある。 「Software Design」 2002/08, P.18〜73。"特集：目で見て覚える TCP/IP ル−ティング"。 > ポリシ−ル−ティング, OSPF, BGP の話。ネットワ−クのシミュレ−ションをするフリ −ソフト NS。Zebra という経路制御のフリ−ソフト BGP-4, RIPv1/v2, IPv6 等対応。 他、「日経バイト」2001/11, P.128〜 にマルチキャスト, OSPF, BGP-4, gated の記事が あった。「UNIX MAGAZINE」2001/09、Summit の連載記事に OSPF を設定する話があった。 * こんなソフトもみっけ 最近 iproute2 なるフリ−ソフトを知った。これを使うとサ−バからデフォルトゲ−トウ ェイを複数設定ができる。プロバイダを複数使っての回線冗長化ができる。Linux での実 装、ポリシ−ベ−スル−ティングという？。参考記事は"複数のプロバイダ利用について"、 http://www.multi.ne.jp/staff_note/2008/10/000516.html。2011年のいつだったか。 (5) 経路制御の実際のお話し * こんな経路制御はどうですか `26/01 --------------------- d.1 はマシン P3 でデフォルト経路を 192.9.1.1にする意 | d.1 ← ｜.6 味。s.3C はマシン P1 で 192.9.3.0 へのスタティック経 | Qube3 □ P3 路を 192.9.2.3 経由で設定する意味。 | ｜.5 | ---------------------------------- C (192.9.3.0) | ｜.4 P1,P2 は Apollo。 | □ P2 P3 は Cobalt Qube3。 | s.3C d.2↓｜.3 | ---------------------------------- B (192.9.2.0) Apollo Domain Ring | ↑ ｜.2 | □ P1 □ PC | d.6 ← ｜.1 ｜.9 ------------------------------------------ A (192.9.1.0) P1 から P3.5 への traceroute は、2 -> 3 -> 4 -> 5 -> 6 -> 1 の経路を辿り、左周り で一周回って来る。1 または 6 のケ−ブルを抜くと、P1 から P3.5 への ping が反応し なくなる。PC の Sniffer Basic でパケットの様子を見ると、 6 と 1 の間でパケットが 流れているのが見える。P3 から P2.3 への traceroute は、6 -> 1 -> 2 -> 3 の経路を 辿る。残念ながら Apollo に入れた traceroute のプログラムのせいか、 Apollo のネッ トワ−ク・インタ−フェ−スのせいか、トレ−スの様子が出て来ないところがある。これ はある広域ネットワ−クの冗長化を検討していて、こんなネットワ−クがでてきた。デフ ォルト経路とスタティック経路をうまく使って、手動で経路を右回りにしたり左回りにし たりして冗長化を計る。その通常の経路設定がこれで、果たして個々のマシンが通信でき るのか机上で検討してみた。P1 から P3 ヘの通信は、普通なら P3からネットワ−クB に 戻るスタティック経路を設定する。実際幾つかのマシンで動作を検証した訳である。 P1$ traceroute 192.9.3.5 traceroute to 192.9.3.5 (192.9.3.5), 30 hops max, 38 byte packets 1 192.9.2.3 (192.9.2.3) 9 ms 16 ms 5 ms 2 * * * 3 * 192.9.3.5 (192.9.3.5) 5 ms 12 ms 実際このようなネットワ−クをテストで作り、アクセスできるかやってみた。そしたらで きんかった。P3に相当する箇所には Cobalt Qube3 をとりあえず配置した。それで実際に 確認してから Yamaha なりの今時のル−タを買って設置しようと思った。どうも Qube3が ゲ−トウェイとして、パケットを転送しないようなのだ。Qube3 の設定では、ル−タとし て機能させるには "IPパケット転送のみ" を選択すればいいはずなのだが、できない。そ れで "IPパケット転送とマスカレ−ド" にするとできる。しかし、これはマスカレ−ドの 機能で反対側につながっているパソコンなどのＩＰアドレスを、自分側のインタ−フェ− スが代理で返事しているのである。一見これでＯＫかと錯覚してしまう。しかしル−タと してパケットを通している訳ではないこと、パケットが一周してきている訳ではないこと、 それは認識しておかないといけない。上記の経路設定は理論的にはできるはずである。ち ゃんとしたロ−カル・ル−タにすれば、パケットは一周して来るはずである。`27/08,12 * 続こんな経路制御はどうですか `28/12 | ↑社内ネットへ Qube3 をIPパケット転送のみ。 Server□↑d | .2｜ | R( Cobalt Qube3 ) PC から B.2 は ping OK。 --------------- C PC から C.1 は ping OK。 WAN｜.1 PC から C.2 は ping NG。 Qube3 R□↓d.B1 PC□↓d.D1 LAN｜.2 ｜ Qube3 をIPパケット転送とマ 社内 --------------- B -------------- D スカレ−ド にすると、PC か ネッ ｜.1 ｜.1 ら C.2 も OKになる。これは トへ d.A↓□↑s.C d.A↓□ 結局 Qube3は部門用ファイア ：d ： ： ウォ−ルのような設置になっ ：↑ ： ： ている。 □ ← □↑s.C ← □↑s.D ｜.1 d.A1｜ s.B d.A1｜ Serverの default経路は他を =============================================== A 向いている、静的経路もなし。 セグメントＡはＷＡＮの IP-VPN である。社内ネットへは、本社に向いている。拠点Ｂが あり、拠点Ｄが追加された。Router Ｒの Qube3 は、セグメントＢとＣのバックアップ経 路として当初設置した。Ｃから社内ネットにつながらない場合に、ＢとＡを経由する。Ｂ がＡの経路が閉ざされた場合にＣを通って本社へ行けるようにした。実際に経路の切り替 えはル−タでの幾らかの経路変更は必要だが。新しくセグメントＤができ、人事異動もあ ったりして、ＤからＣのサ−バにアクセスしたいという要求が起こった。Ｃには Linuxで ＮＦＳのサ−バもあれば、ただの Windows 2000でファイル共有のもあったりした。Linux はデフォルト経路の他に静的経路も設定することはできる。しかしただの Windowsパソコ ンは静的経路は設定できない。つまり Linuxやパソコンの経路設定はいじることなく、Ｄ からＣにアクセスできるようにしなければならなかった。 その解が Qube3 のＮＡＴ変換 を使うことであった。"ＩＰパケット転送とマスカレ−ド" の設定である。 これで問題はクリアしたかに見えた。PC から Server へ HTTP も Telnet も FTP もでき るようになった。もう一つやりたいことがあった、NFS である。NFS のパケットが通らな いのだ。Qube3 のＮＡＴ機能が怪しい。それで手元でまたまた実験ネットワ−クを作って 試してみた。やはりそうだった。いわゆるファイアウォ−ルのＮＡＴ越えの問題が発覚し たのだ。家庭用のブロ−ドバンド・ル−タのＮＡＴ機能ではよく問題になる話である。そ れならばちゃんとしたＮＡＴ機能を持つ装置にしようではないかと、NetScreen に変えて みることにした。しかしここでも少し問題が起きた。PC と Server 間でそもそも pingも 通らなくなってしまった。NetScreen のデフォルト経路 d.B1 をやめて、D への静的経路 を設定してみた。これで NetScreen から PC へ ping が通るようになった。 ちょっとこ んな経路設定は本当は使うべきではない。ＷＡＮネットワ−クを見直しすべきである。次 の見直しの際にシンプルなネットワ−クにするとしよう。 * Cobalt Qube3 のネットワ−ク `27/08 [システム]->[インタ−ネット]の{ＬＡＮ上のゲ−トウェイ}の{ＩＰ転送とマスカレ−ド} のとこ、"ＩＰパケット転送とマスカレ−ド"、"ＩＰパケット転送のみ"、 "ＩＰパケット を転送しない"。ロ−カル・ル−タとして働かせるには"ＩＰパケット転送のみ" を選ぶこ と、これで十分できそうな気がするが、実際やってみるとできなかった。Cobalt Qube3は ロ−カル・ル−タとしては機能しない。一体どういう製品だ、紛らわしい。Linux のファ イアウォ−ルのソフトが何か働いているのか。ともかくだいぶこれではまりました。 ----------------- .2◇ Apollo | | ｜192.168.2.0 | Cobalt Qube3 | .1｜ | | --------- 注.この Qube3 のことは忘れて | Π eth1 Ιeth0| | Qube3 | 下さい。テストする度に挙動が | .1□ □.1 | | | おかしい。一応、おかしいとい ----｜-----｜---- --------- う話があったということで終り。 HUB■ ｜Cross Cable .1｜ 192.168.2.0｜ ｜192.168.1.0 ｜192.168.1.0 ｜ ｜ .2△ Apollo◇.2 △PC .2 PC の Default Gateway 192.168.1.1 に設定。 Apollo の Default Gateway は 192.168.2.1、 静的経路は $/etc/route add net 192.168.1 192.168.2.1 1 ・Apollo から PC へは、Qube3 で [システム]->[インタ−ネット]で "IPパケット転送と マスカレ−ド" にしないとアクセスできない。Apollo から 192.168.1.1 へは "IPパケ ットを転送しない" 以外ならアクセスできる。これって本当か、今一度確認のこと。 ・いや PC から Apolloへのアクセスのことだ。PC 側はＬＡＮ、 Apollo 側がＷＡＮであ る。PC から 192.168.2.1 へは "IPパケットを転送しない" 以外ならばアクセスできる。 192.168.2.2 へは "IPパケット転送とマスカレ−ド" にしないとアクセスできない。 -------------------------------------------------------------------------------- 完全に勘違いしていた。[システム]->[インタ−ネット]の{ＬＡＮ上のゲ−トウェイ}とい うのは Qube3 のことではなく、別ＷＡＮ用ル−タなんかがあって、 それをＬＡＮ上のゲ −トウェイと言っている。 だから Qube3 をル−タとして設定する分には、[システム]-> [インタ−ネット] は関係ないのだ。 ２０１２年２月、ミニ・インタ−ネットを作るのに Qube3 を引っぱり出してきてようやく分かった。Qube3 ２つある内、１つはハ−ドディス クが限界みたいで RAID 1 の警告が主メニュ−の上の面玉が点滅している。テストが終わ るまで持ってくれ−！。ＤＮＳサ−バと外向けのメ−ルサ−バにしてテストしてます。 -------------------------------------------------------------------------------- * NetScreen-50 をル−タとして使う `27/08 Cisco Catalyst 3950 を手元でテストするのにロ−カルで使うル−タが必要になった。最 初に Cobalt Qube3 をル−タにしたのだが、ル−ティング機能がどうも働かなかった。そ の後 Qube3 をテストしたが、やはりおかしかった。ル−タとしては使えん。 192.168.1.1 Router■192.168.2.9 ＬＡＮ側ポ−ト or L3 ｜ ------------------------------｜------ | NetScreen □1 □2 □3 | ------------｜------------------------ Cross Cable｜Trust Untrust 192.168.2.1 ｜ ＷＡＮ側ポ−ト 192.168.1.2△PC Default Gateway 192.168.1.1 PC から NetScreen にアクセス http://192.168.1.1。 System -> [Admin] -> [Settings] _____ ________ ______ ____ _________ ____ /Admin\_/Settings\_/Syslog\_/SNMP\_/NS Global\_/ Web\________ ｜￣￣￣ ￣￣￣ ￣￣ ￣￣￣￣ ￣￣ ｜ System IP Address: [ 192.168.1.1 ] System -> [Interface] _________ ___________ _____ / Trusted \_/ Untrusted \_/ DMZ \__________________ Web UI, Telnet, SNMP に〆 ｜ ￣￣￣￣￣￣ ￣￣￣ Other Services 〆Ping ｜ ----------------------------------------------------------------------------- ｜ |Name | IP | Netmask |Gateway| Managed IP|BW|Mode |Link|Configure| ｜ |-----|-----------|-------------|-------|-----------|--|-----|----|---------| ｜ |trust|192.168.1.1|255.255.255.0|0.0.0.0|192.168.1.1| 0|Route| Up | Edit | ｜ ----------------------------------------------------------------------------- _________ ___________ _____ / Trusted \_/ Untrusted \_/ DMZ \__________________ Static IP ｜￣￣￣￣￣ ￣￣￣ Other Services 〆Ping ｜ ----------------------------------------------------------------------------- ｜ | Name | IP | Netmask | Gateway |Managed IP|BW|Link| Configure| ｜ |-------|-----------|-------------|-----------|----------|--|----|----------| ｜ |untrust|192.168.2.1|255.255.255.0|192.168.2.9| 0.0.0.0 | 0| Up | Edit | ｜ ----------------------------------------------------------------------------- Network -> [Policy] の [Incoming] と [Outgoing] は、Source も Destination も Any に、Service も Any、NAT は N/A にしたル−ルを１個ずつ作成する。 * NetScreen とプロキシについて `27/12 □INDY □プロキシサ−バ NetScreen は経路設定は何もしてない。 ｜.6 ｜.5 ------------------------ 192.168.1.0 PC から http://192.168.2.1 はダメ。 ｜.2 PC から http://192.168.1.3 はＯＫ。 WAN ----------- NAT 管理用ＩＰ |NetScreen| 192.168.1.3 192.168.1.2 へはどこからも ping さえダメ。 LAN ----------- ｜.1 ------------------------ 192.168.2.0 ｜.2 PC □ブラウザの設定 Proxy 192.168.1.5 デフォルトル−ト 192.168.2.1 PC から INDY へ ping, ftp, telnet などは NetScreen の NATが効いて 192.168.1.2 か らの発信になる。PC から INDY に telnetで入って % tcpdump -n not port telnet を打 ち、PC から INDY に ftp して様子をみる。 * DHCP でパソコンの経路を使い分ける `2h/10/m こんなのも経路制御のやり方になる。あまり勧められる方法ではない。もしこれをやる場 合は Router2 のル−タに社内ネットワ−クをつなぐのではなく、 ル−タの下にＵＴＭを 設けそれなりのセキュリティ対策を講じる必要がある。いや必要ではなく講じなければな らない。まさにこれは頭隠して尻隠さずで、セキュリティ対策の抜け道になってしまう。 本社インタ−ネット ： □Router1 ｜ ----------------- 拠点インタ−ネット ｜ ： -------- ： | L3 | PC ：Router2 PC のデフォルト経路は 192.168.2.1 に設定。 -------- △ □DHCPサ−バ 社内ネットワ−クに向いている。そして本社 192.168.2.1｜ ｜ ｜.2 インタ−ネット回線を利用。 ------------------------------ Router2 では DHCP サ−バを動かす。PCにてDHCP 利用にするとデフォルト経路はRouter2 の 192.168.2.2 に向く。 インタ−ネットヘは拠点に設置したインタ−ネット回線を通る ことになる。小人数の国内や国外の拠点において、ＷＡＮを経由し本社インタ−ネットを 利用するのに遅い場合このような形態がある。