ルーティングテーブル(AWSで言う「ルートテーブル」)について

 先ほどの記事「デフォルトゲートウェイについて」の続きになります。デフォルトルートを説明する際にも少し出てきましたが、ルーティングテーブルについて説明します。
 因みに、ルーティングテーブルはAWSで言うところの「ルートテーブル」に該当します。(以下、AWSの機能を指す場合は「ルートテーブル」、また一般的な機能を指す場合は「ルーティングテーブル」と表記します)

 一言でいうと、「他ネットワークに転送するための宛先リスト」です。「デフォルトルートについて」でも触れましたが、自ネットワーク内であれば直接当該機器と通信します。他ネットワークの機器と通信するためには、デフォルトゲートウェイに転送します。デフォルトゲートウェイが判断した次の機器に転送します。最終的に目的の機器に転送されます。

 ルーティングテーブルですが、ルータやL3スイッチなどのネットワーク機器は当然のことながら、PCやスマホ・タブレットなどのネットワークに接続されている機器は全て持っています。
 ルーティングテーブルには自ネットワークは直接通信すると端末を問わず明示的に記述されています。

 それ以外に関してはどのように記述されているかは、機器の性質によって変わってきます。
 LAN上にあるPCやスマホ・タブレットなどの場合、「自ネットワーク以外はデフォルトゲートウェイに全て任せる」という発想ですので、「自ネットワークかそうでないか」というたいへんシンプルな形になります。

 しかし、これがルータやL3スイッチになるとそう単純な話ではなくなります。デフォルトゲートウェイが受信したパケットを別のルータに転送しますが、ルータ同士が接続されているネットワークには複数のルータが接続されています。(例外的に1対1で接続されているケースもありますが、一旦ここでは置いておきます)
 となると、ルータ同士を接続しているネットワークでは、各ルータが複数の経路(ルート)が記述されたルーティングテーブルを持っています。各ルータはルーティングテーブルを参照して、目的の機器に向けて適切な経路を選択します。この繰り返しで送信先にパケットが届きます。

 ここからはAWSに特化したお話になります。そのため、AWSの説明時には「ルートテーブル」と表記します。

 VPCを作成した後、VPC内に1つ以上のサブネットを作成します。例として、10.0.0.0/16というネットワークのVPCを作成したとします。
 その中に10.0.0.0/24,10.0.1.0/24,10.0.2.0/24という3つのサブネットを作成したとします。仮にAWSではなく、一般的なネットワーク機器等の場合でのルーティングテーブルですと以下のようになります。

10.0.0.0/24 —> 機器A
10.0.1.0/24 —> 機器B
10.0.2.0/24 —> 機器C
0.0.0.0/0 —> 機器D

 各サブネット毎及びデフォルトルート(上記以外の送信先)に対して転送先を指定してやる必要があります。
 これに対して、AWSでのルートテーブルは以下のようになります。

10.0.0.0/16 —> local
0.0.0.0/0 —> [対応するIGWまたはNATゲートウェイのID]

 といったような形式で記述されます。一般的なネットワーク機器での設定のように、個別にサブネット毎の経路を指定する必要がありません。AWSでは同一VPC内に存在するサブネット間は自動的に相互通信可能になっています。そのため、VPCのIPアドレス範囲のみが記述されています。これはAWSが内部に「暗示的なルーター」(とAWSでは表現しています)機能を持ち合わせています。VPC内部でのルーティング機能は利用者からはブラックボックスと映るようになっています。
 特にVPC内でのルーティングには気を遣う必要はありません。注意すべきなのは「VPC外」に相当するデフォルトゲートウェイの設定です。0.0.0.0/0の右辺には、直接インターネットに出て行く設定であれば、IGW(Internet Gateway)を指定し、NATであればNATゲートウェイを指定します。
 AWS側の機能により、ルートテーブルの記述は「VPCの中か外か」だけを意識して行えば良いので、利用者にとって設定に関する負担が軽減されています。

  • このエントリーをはてなブックマークに追加

コメントをどうぞ