270 lines
12 KiB
Plaintext
270 lines
12 KiB
Plaintext
<!-- $Id: routing.sgml,v 1.4 1997/02/22 13:01:48 peter Exp $ -->
|
|
<!-- The FreeBSD Japanese Documentation Project -->
|
|
<!-- Original revision: 1.5 -->
|
|
|
|
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
|
|
|
<sect><heading>ゲートウェイとルート<label id="routing"></heading>
|
|
|
|
<p><em>原作: &a.gryphon;.<newline>6 October 1995.</em>
|
|
<p><em>訳: &a.yuki;.<newline>6 September 1996.</em>
|
|
|
|
ある計算機が他の計算機をみつけることができるようにするには, ある
|
|
計算機から他の計算機へ, どのようにたどり着くかを適切に記述するた
|
|
めの仕組みが必要です. この仕組みをルーティングと呼びます. 「ルー
|
|
ト(経路)」は <bf>destination (目的地) </bf>と <bf>gateway (ゲー
|
|
トウェイ) </bf>の 2つのアドレスの組で定義します. あなたが
|
|
<em>destination</em> へアクセスしようとした場合,
|
|
<em>gateway</em> を通って送られることをこのペアは示しています.
|
|
destination には個々のホスト, サブネット, 「デフォルト」の 3つの
|
|
タイプがあります. 「デフォルトルート」は他への経路が適用できない
|
|
場合に使われます. のちほどデフォルトルートについて少し述べること
|
|
するとして, ここでは, 個々のホスト, インタフェース (「リンク」と
|
|
も呼ばれます), イーサネットハードウェアアドレスという 3つのタイ
|
|
プのゲートウェイについて説明します.
|
|
|
|
<sect1><heading>例</heading>
|
|
|
|
<p>以下に示す <tt>netstat -r</tt> の出力の例を使って, ルーティン
|
|
グがいろいろと異なっている様子を説明することにします.
|
|
|
|
<tscreen><verb>
|
|
Destination Gateway Flags Refs Use Netif Expire
|
|
|
|
default outside-gw UGSc 37 418 ppp0
|
|
localhost localhost UH 0 181 lo0
|
|
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
|
10.20.30.255 link#1 UHLW 1 2421
|
|
foobar.com link#1 UC 0 0
|
|
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
|
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
|
host2.foobar.com link#1 UC 0 0
|
|
224 link#1 UC 0 0
|
|
</verb></tscreen>
|
|
|
|
最初の2行はデフォルトルート(次の節で詳しく説明します)と,
|
|
<tt>localhost</tt>への経路を示しています.
|
|
|
|
<tt>localhost</tt>のためのインタフェース (<tt>Netif</tt>の欄)
|
|
は<tt>lo0</tt>で, これはループバックデバイスとして知られています.
|
|
結局のところ戻るだけなので, この destinationへのすべてのトラフィ
|
|
ックが内部的に処理されるのであって, LAN を経由して送られるのでは
|
|
ありません.
|
|
|
|
次の行では``<tt>0:e0:...</tt>''というアドレスに注目しましょう.
|
|
これはイーサネットハードウェアアドレスです. FreeBSDは自動的に
|
|
ローカルなイーサネット上の任意のホスト (この例では<tt>test0</tt>)
|
|
を見つけ, イーサネットインタフェース<tt>ed0</tt>の所にそのホスト
|
|
への経路を直接つけ加えます. タイムアウト時間 (<tt>Expire</tt>の
|
|
欄) も経路のタイプと結びついており, 指定された時間が経過しても応
|
|
答がないときに使用します. この場合, 経路情報は自動的に削除されま
|
|
す. これらのホストは, RIP(Routing Information Protocol) という,
|
|
最短パスの判定に基づいてローカルホストへの経路を決定する仕組みを
|
|
利用することで認識されます.
|
|
|
|
更に, FreeBSDではローカルサブネット (<tt>10.20.30.255</tt>は
|
|
<tt>10.20.30</tt>というサブネットに対するブロードキャストアドレスで,
|
|
<tt>foobar.com</tt>はこのサブネットに結びつけられているドメイン名)
|
|
への経路情報も加えることができます. <tt>link#1</tt>というの
|
|
は, この計算機の最初のイーサネットカードのことをさします. これら
|
|
については, 何も追加インタフェースが指定されていないことに気づく
|
|
でしょう.
|
|
|
|
これらの2つのグループ(ローカルネットワークホストとローカルサブネット)
|
|
の両方とも, <tt>routed</tt>と呼ばれるデーモンによって自動的に
|
|
経路が設定されます.
|
|
<tt>routed</tt>を動かさなければ, 静的に定義した (つまり具体的に
|
|
設定した) 経路のみ存在することになります.
|
|
|
|
<tt>host1</tt> の行は私たちのホストのことで,
|
|
イーサネットアドレスで示されています.
|
|
送信側のホストの場合, FreeBSDはイーサネットインタフェースへ
|
|
送るのではなく, ループバックインタフェース
|
|
(<tt>lo0</tt>)を使います.
|
|
|
|
2つある<tt>host2</tt>の行は, ifconfigのエイリアス (このようなこと
|
|
をする理由については ethernetの章を参照してください) を使ったとき
|
|
にどのようになるかを示す例です. <tt>lo0</tt>の後にある<tt>=></tt>
|
|
は, インタフェースが (このアドレスがローカルなホストを参照しているので)
|
|
ループバックを使っているというだけでなく, エイリアスになっていることも
|
|
示しています. このような経路はエイリアスをサポートしている
|
|
ホストにのみ現れます. ローカルネットワーク上の他のすべてのホストでは
|
|
単に<tt>link#1</tt>となります.
|
|
|
|
最後の行(destinationが<tt>224</tt>のサブネット)はマルチキャスト
|
|
で扱うものですが, これは他の章で説明します.
|
|
|
|
他の欄については<tt>Flags</tt>について説明する必要があります.
|
|
それぞれの経路は欄に示されているように違った属性をもっています.
|
|
以下にいくつかのフラグとこれらが何を意味しているかを示します.
|
|
|
|
<descrip>
|
|
|
|
<tag/U/ <bf/Up:/ この経路はアクティブです.
|
|
|
|
<tag/H/ <bf/Host:/ 経路の destinationが単一のホストです.
|
|
|
|
<tag/G/ <bf/Gateway:/ この destinationへ送られると, どこへ送れ
|
|
ばよいかを明らかにして, そのリモートシステムへ送られます.
|
|
|
|
<tag/S/ <bf/Static:/ この経路はシステムによって自動的に生成
|
|
されたのではなく, 手動で作成されました.
|
|
|
|
<tag/C/ <bf/Clone:/ マシンに接続したときにこの経路に基づく
|
|
新しい経路が作られます. このタイプの経路は通常は
|
|
ローカルネットワークで使われます.
|
|
|
|
<tag/W/ <bf/WasCloned:/ ローカルエリアネットワーク(Clone)
|
|
の経路に基づいて自動的に生成された経路であることを示します.
|
|
|
|
<tag/L/ <bf/Link:/ イーサネットハードウェアへの参照を含む
|
|
経路です.
|
|
|
|
</descrip>
|
|
|
|
|
|
<sect1><heading>デフォルトルート</heading>
|
|
|
|
<p>ローカルシステムからリモートホストにコネクションを張る
|
|
必要がある場合, 既知のパスが存在するかどうかを確認するためにル
|
|
ーティングテーブルをチェッ
|
|
クします. 到達するためのパスを知っているサブネットの内部にリモ
|
|
ートホストがある場合 (Cloned routes), システムはインタフェース
|
|
から接続できるかどうかをチェックします.
|
|
|
|
知っているパスがすべて駄目だった場合でも, システムには
|
|
最後の切り札の <bf>デフォルト</bf>ルートがあります. このルートは
|
|
ゲートウェイルート (普通はシステムに 1つしかありません)
|
|
の特別なものです. そして, フラグフィールドは必ず ``<tt>c</tt>''
|
|
がマークされています. このゲートウェイは, LAN 内のホストにとっ
|
|
て, 外部 (PPPのリンクを経由する場合や, データラインに接続するハー
|
|
ドウェアデバイスなど) へ直接接続するマシンすべてのためのものです.
|
|
|
|
外部に対するゲートウェイとして機能するマシンでデフォルトルート
|
|
を設定する場合, デフォルトルートは
|
|
インターネットサービスプロバイダ(ISP)のサイトのゲートウェ
|
|
イマシンになるでしょう.
|
|
|
|
それではデフォルトルートの一例を見てみましょう.
|
|
一般的な構成を示します.
|
|
<tscreen><verb>
|
|
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
|
</verb></tscreen>
|
|
|
|
ホスト<tt>Local1</tt>とホスト<tt>Local2</tt>をPPPでISPのターミナルサー
|
|
バと接続されているあなたのサイトだとします. ISPはサイト内にロー
|
|
カルなネットワークを持っていて, そこにはまざまなものがあり, あな
|
|
たの接続するサーバやISPのインターネットへの接続点であるハード
|
|
ウェアデバイス(T1-GW)などがあります.
|
|
|
|
あなたのマシンのデフォルトルートはそれぞれ次のようになります.
|
|
|
|
<tscreen><verb>
|
|
host default gateway interface
|
|
---- --------------- ---------
|
|
Local2 Local1 ethernet
|
|
Local1 T1-GW PPP
|
|
</verb></tscreen>
|
|
|
|
「なぜ (あるいは、どうやって) Local1 の
|
|
デフォルトゲートウェイをISPのサーバでなく
|
|
T1-GWにセットするのか」という質問がよくあります.
|
|
|
|
コネクションのローカルの側については, PPPのインタフェースは
|
|
ISPのローカルネットワーク上のアドレスを用いているため,
|
|
ISPのローカルネットワーク上のすべてのマシンへの経路は
|
|
自動的に生成されています. つまり, あなたのマシンは, どのようにT1-GW
|
|
まで届くかという経路を既に知っていることになりますから,
|
|
ISPサーバに媒介的なトラフィックをかける必要はありません.
|
|
|
|
最後になりましたが, 一般的にローカルネットワークでは ``<tt>...1</tt>'
|
|
というアドレスをゲートウェイアドレスとして使います.
|
|
ですから (同じ例を用います), あなたのclass-Cのアドレス空間が
|
|
<tt>10.20.30</tt>で ISPが<tt>10.9.9</tt>を用いている場合,
|
|
デフォルトルートは次のようになります.
|
|
|
|
<tscreen><verb>
|
|
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
|
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>マルチホームホスト</heading>
|
|
|
|
<p>ここで扱うべき他のタイプの設定があります. それは2つの異なるネットワー
|
|
クにまたがるホストです. 技術的にはゲートウェイとして機能するマシン (上
|
|
の例では PPPコネクションを用いています) はマルチホームホストで
|
|
す. しかし実際にはこの言葉は, 2つのローカルエリアネットワーク上のサ
|
|
イトであるマシンを指す言葉としてのみ使われます.
|
|
|
|
2枚のイーサネットカードを持つマシンが, 別のサブネット
|
|
上にそれぞれアドレスを持っている場合があります.
|
|
あるいは, イーサネットカードを1枚持っているマシンで,
|
|
ifconfigのエイリアスを使っているかもしれません.
|
|
物理的に分かれている2つのイーサネットのネットワークが使われて
|
|
いるならば前者が用いられます. 後者は, 物理的には1つのネットワ
|
|
ークセグメントで, 論理的には分かれている 2つのサブネットとする
|
|
場合に用いられます.
|
|
|
|
どちらにしても, このマシンがお互いのサブネットへのゲートウェイ
|
|
(inbound route) として定義されていることが分かるように, おのお
|
|
ののサブネットでルーティングテーブルを設定します. このマシンが
|
|
2 つのサブネットの間のブリッジとして動作するという構成は, パケ
|
|
ットのフィルタリングを実装する必要がある場合や, 一方向または双
|
|
方向のファイアウォールを利用したセキュリティを構築する場合によ
|
|
く用いられます.
|
|
|
|
<sect1><heading>ルーティングの伝播</heading>
|
|
|
|
<p>すでに外部との経路をどのように定義したらよいかは説明しました.
|
|
しかし外部から私たちのマシンをどのようにして見
|
|
つけるのかについては説明していません.
|
|
|
|
ある特定のアドレス空間 (この例では class-C のサブネット) にお
|
|
けるすべてのトラフィックが, 到着したパケットを内部で転送するネ
|
|
ットワーク上の特定のホストに送られるようにルーティングテーブル
|
|
を設定することができるのは分かっています.
|
|
|
|
あなたのサイトにアドレス空間を割り当てる場合, あなたのサブネッ
|
|
トへのすべてのトラフィックがすべて PPPリンクを通じてサイトに送
|
|
ってくるようにサービスプロバイダはルーティングテーブルを設定し
|
|
ます. しかし, 国境の向こう側のサイトはどのようにしてあなたの
|
|
ISPへ送ることを知るのでしょうか?
|
|
|
|
割り当てられているすべてのアドレス空間の経路を維持する (分散し
|
|
ている DNS 情報とよく似た) システムがあり, そのインターネット
|
|
バックボーンへの接続点を定義しています. 「バックボーン」
|
|
とは国を越え, 世界中のインターネットのトラフィックを運ぶ主要
|
|
な信用できる幹線のことです. どのバックボーンマシンも, あるネット
|
|
ワークから特定のバックボーンのマシンへ向かうトラフィックと,
|
|
そのバックボーンのマシンからあなたのネットワークに届くサービス
|
|
プロバイダまでのチェーンのマスタテーブルのコピーを持っていま
|
|
す.
|
|
|
|
あなたのサイトが接続(プロバイダからみて内側にある
|
|
ことになります) したということを, プロバイダからバックボー
|
|
ンサイトへ通知することはプロバイダの仕事です. これが経
|
|
路の伝搬です.
|
|
|
|
<!--
|
|
<sect1><heading>Multicast Routing</heading>
|
|
-->
|
|
|
|
<sect1><heading>トラブルシューティング</heading>
|
|
|
|
<p>ルーティングの伝搬に問題が生じて, いくつかのサイトが
|
|
接続をおこなうことができなくなることがあります.
|
|
ルーティングがどこでおかしくなっているかを明らかにするのに
|
|
最も有効なコマンドはおそらく<tt>traceroute(8)</tt>コマンドでしょ
|
|
う. このコマンドは, あなたがリモートマシンに対して接続をおこなう
|
|
ことができない(例えば<tt>ping(8)</tt>に失敗するような場合)
|
|
場合も, 同じように有効です.
|
|
|
|
<tt>traceroute(8)</tt>コマンドは, 接続を試みているリモートホスト
|
|
を引数にして実行します. 試みているパスの経由する
|
|
ゲートウェイホストを表示し, 最終的には目的のホストに
|
|
たどり着くか, コネクションの欠如によって終ってしまうかのどちら
|
|
かになります.
|
|
|
|
より詳しい情報は, <tt>tracroute</tt>のマニュアルページをみてください.
|
|
|