「なんだこのアホみたいなタイトルは」と分かっている人は思うかもしれませんが、道端を歩きながら、なぜかふと「デフォルトゲートウェイは同一セグメント内のホストじゃなきゃダメだよね？」と初歩的なことが気がかりになってしまい、明示的にそう言っているサイトも存在しなかったので後学のためにもまとめときます。

デフォルトゲートウェイには、同一セグメント内のホストを指定しなければなりません。

そのホストのMACアドレスを知っている必要があるからです。

(本当は順序が逆で、「同一セグメント内でない外のネットワークと通信するためにデフォルトゲートウェイが必要」なんですけどね…！)

似たような意味かつより具体的に、いくつか言い換えてみます。

• 「ARPでMACアドレスを解決できる相手」のIPアドレスをデフォルトゲートウェイの値として設定できます。
• 「リンク上」にあるホストのIPアドレスをデフォルトゲートウェイの値として設定できます。
• 「直接接続」しているホストのIPアドレスをデフォルトゲートウェイの値として設定できます。

この3つの文章はほとんど同じ意味です。

大前提

ゲートウェイの動きを理解する上での大前提は、

MACアドレスを知らないホストと通信することはできない

ということです。

ホストは、自分のMACアドレス宛ではないEthernetフレームは破棄してしまいます(ブロードキャストなどは除く)。たとえ宛先IPアドレスが確かに自分のものだったとしても、宛先MACアドレスが自分宛でなければ、宛先IPアドレスが自分のものかを確認することもせずそのフレームを捨ててしまいます。

デフォルトゲートウェイを設定すると何が起こるか

あなたがルーターやパソコンだとしましょう。

1. 今、デフォルトゲートウェイが 192.168.10.1 に設定されました。
2. ある外向きのIPパケットがあり、その宛先は 114.514.810.931(実在しません) でした。ルーティングテーブル上でこの宛先アドレスがマッチしたのはデフォルトルート(0.0.0.0/0)だけでした。つまり 114.514.810.931 は知らない宛先だったので、このパケットを、デフォルトゲートウェイである 192.168.10.1 さんにお願いして代わりに宛先まで届けてもらいたいです。
3. そこで、そのIPパケットをEthernetフレームに載せて、これをデフォルトゲートウェイである 192.168.10.1 さんに送ろうとおもいます。このEthernetフレームの宛先MACアドレスには 192.168.10.1 さんが持っているMACアドレスを書く必要があります。しかし、 192.168.10.1 さんのMACアドレスが分かりません。
4. 192.168.10.1 さんのMACアドレスを知りたいので、 192.168.10.1 さんのMACアドレスを調べるARP request (ブロードキャスト)パケットを送出します。
5. 192.168.10.1 さんからARP reply パケットが返ってきました:「私のMACアドレスは 11:45:14:36:43:64 です」
6. 192.168.10.1 さんのMACアドレスは 11:45:14:36:43:64 であることが分かったので、件のIPパケットを 192.168.10.1 さんに中継してもらう準備ができました。Ethernetフレームの宛先MACアドレスは 11:45:14:36:43:64 、そのフレームに載ってるIPパケットの宛先IPアドレスは 114.514.810.931 として、このEthernetフレームを送出します。
7. 11:45:14:36:43:64 ( 192.168.10.1 さん) がこのフレームを受け取りました。フレームの宛先MACアドレスが自分のMACアドレスと一致しているので、このフレームは自分宛てのフレームだということに気づきます。なので、192.168.10.1 さんはそのフレームに載っているIPパケットを取り出します。
8. 192.168.10.1 さんが取り出したIPパケットの宛先IPアドレスは自分のIPアドレス 192.168.10.1 ではなく他人のIPアドレス 114.514.810.931 でした。つまり、192.168.10.1 さんは 114.514.810.931 宛のIPパケットをバケツリレーすることを命じられたことになります。

同一セグメント内/直接接続/リンク上でなければいけない理由

上の、4つ目のステップで、デフォルトゲートウェイに設定したホスト 192.168.10.1 のMACアドレスを調べています。

しかしこのとき、ゲートウェイとして別のセグメントのホストのIPアドレスを設定してしまうと、ARPリプライが返ってこないのでMACアドレスが分かりません。

なので、もし 192.168.10.1 さんが別のセグメントのホストだった場合、ARPリクエストが届かないのでゲートウェイには設定できないのです。

別のセグメントからARPリプライが返ってこない理由は、宛先が FF:FF:FF:FF:FF:FF であるARPブロードキャストはセグメントを超えて外部に転送されないという決まりになっているからです。

何度ARPリクエストを送信してもゲートウェイのMACアドレスが分からず、送ろうとしていたパケットがいつまでたっても転送できないので、結局タイムアウトでパケットが消失します。

同じセグメント内のホストだけがこのARPリクエストを受け取り、返事をすることができるので、デフォルトゲートウェイは同一セグメントのホストでなければならないのです。

追記

どのサイトも長ったらしくて読みづらいなと思って自分で書いてみたら長ったらしくて読みづらくなりました。キレそう。

図やイラストを載せるだけで相当分かりやすさが変わると思うけど面倒くさいので文字で済ませました。許し亭ゆるして。