サブネットマスクを間違って設定したときのデフォルトゲートウェイとの通信

質問

サブネットマスクを間違って設定したときのデフォルトゲートウェイとの通信について教えてください。

ホストAのアドレス　　 ：192.168.1.200
デフォルトゲートウェイ：192.168.1.1

であったとき、ホストAのサブネットマスクを255.255.255.0とすれば通信できると思いますが、
間違って255.255.255.128と設定したときに別のネットワークとホストAが通信できるのか（デフォルトゲートウェイが中継するのか）を知りたいと思っています。

デフォルトゲートウェイ側のサブネットマスクは255.255.255.0だとし、デフォルトゲートウェイ側からはホストAは同じネットワークである場合です。

つまりホストAから違うネットワークへパケットを送る場合、
ホストA　→　デフォルトゲートウェイ　…　送れるか（私には）わからない。そもそもパケットが出るのか。
デフォルトゲートウェイ　→　ホストA　…　同じネットワークなため応答は問題ない（はず）。

arpテーブルにデフォルトゲートウェイのMACアドレスが登録されているかいないかによっても違うのでしょうか。

私もテストしてみたのですが、通信前からデフォルトゲートウェイのMACアドレスがarpテーブルにあり、ルータやOSの方で何か特殊なことをしているかもしれない（そもそもこれが特殊なことなのかどんなOSやルータでもそうなのかもわからない）と思い実験にならなかったため、質問させていただきました。
ちなみに、以上のような私の環境では、サブネットマスクを間違えてもインターネットにつながりました。

よろしくお願いします。

回答No.7

Toshi0230 · ベストアンサー

No.2の方がなかなかに予想外な結果を出してくれましたので、もう少し調べて見ました。（遊ぶとも言う）
どうもWindows (XP/Vista)は、経路情報が設定されている場合、nexthopがインタフェースのネットワーク内に有る／無しにかかわらず、arpを出してMACアドレスを求めるようです。これはdefault gatewayに限らず、routeコマンドで追加した場合でも同様でした（パケットキャプチャで確認）。
ちなみにLinux(CentOS5)の場合、そもそもdefault gatewayを異なるネットワークに設定することができなかったので、質問の条件がそもそも成り立たないです。
一般のルータ(Cisco等）については検証できないので不明。多分設定できないんじゃないかと思いますが、設定できたとしてもまともな動作は期待できないでしょうね。

ちなみにPC2台を以下のように設定して、
　PC-A : 192.168.1.26/26, gateway 192.168.1.254
　PC-B : 192.168.1.224/24, gateway 192.168.1.254

PC-A→PC-Bにpingを打った場合、パケットの到達経路は以下のようになりました。
PC-A → PC-B : PC-A → gateway → PC-B
PC-B → PC-A : PC-B → PC-A
なお、今回、gatewayは一般のブロードバンドルータですが、すべてのルータでこのような中継動作をするかどうかまでは何とも言えません。

余談ですが、defult gateway を自分自身にすると、すべてのIPに対してarpによりMACアドレスを求めるようになります。(Windowsの場合)

お礼

回答ありがとうございます。

Windowsの動作や到達経路まで教えて頂き、大変参考になりました。
Linuxでは設定自体ができないのですね。

ただひとつ疑問なのが、PC-BからPC-Aの経路です。
直接PC-Aに戻るのでしょうか。もちろんPC-Aからの通信を一度も行わずにPC-BからPingしたらPC-Aに直接行くと思うのですが。

送信元IPアドレスはgatewayを経由しても変わらず、MACアドレスのみgatewayのものに置き換わったと思いますが、そうするとPC-AのIPアドレスに対応するMACアドレスはgatewayのものであるとPC-Bは勘違いしてしまいそうな気がするのですが。

PC-A　　　　　　　　　　　gateway　　　　　　　　　　　　PC-B
送信元IP：PC-A　　　⇒　　送信元IP:PC-A　　　　⇒　　PC-AのIPに対応するMACはgatewayのMAC？
送信元MAC：PC-A　　　　　送信元MAC：gateway

APRキャッシュへの動的エントリの部分がわかっていないので間違っているのかもしれませんが、PC-B → PC-Aの場合もgatewayを経由するのではないでしょうか。
PC-Bの設定が、ARPキャッシュしないようになっていたりしなかったでしょうか。そもそも自分でARPしなかったものはARPキャッシュに入らないとかでしょうか？（ARPキャッシュの動作がわかっておりませんm(_ _)m）

よろしければなぜこういう動作になるのか、教えていただければと思います。
本来の質問は解決しましたので、回答がなければ締め切りたいと思います。

補足

お礼への補足です。

ARPキャッシュについてですが、自分でも少し調べてみました。
結局、私の言ったような動作ではなく、単純にARPで解決されたものだけARPテーブルに登録されるのではないでしょうか。たぶん。
たぶんというのは、私みたいな間違いをしている人がいなかったため、ネット上ではピンポイントで回答をみつけることができなかったため、確証がないためたぶんです。
でも、自分のPCのARPテーブルを見ても、閲覧したHPのIPアドレスがARPに登録されていないため、おそらくこの解釈であってるでしょう。
そうすれば、PC-BからPC-Aへ直接パケットが届くのが納得できます。
詳しい方の賛同があると心強いのですが…。

なくてもそのうち締め切ります。
回答くださった方々、ありがとうございました。

回答No.9

Toshi0230

> そうするとPC-AのIPアドレスに対応するMACアドレスはgatewayのものであるとPC-Bは勘違いしてしまいそうな気がするのですが。

その心配は無用です。
arpのパケット構造を見てもらえれば判りますが、宛先IPのMACアドレスを問い合わせる際、問い合わせ元のIPとMACアドレスがARPパケット内に含まれます。
このとき、arpリクエストを受けた側は、arpパケット内の問い合わせ元IPとMACアドレスをarpテーブルに登録します。
前回の回答で示したping試験の場合だと、PC-Bはpingのecho request を受信した状態では、arpテーブルに含まれるのはgatewayのIPとMACになります。PC-AのMACアドレスは判らないので、echo replyを返すときにarpで改めてMACアドレスを要求しています。

届いたパケットの送信元IPと送信元MACアドレスの組み合わせがarpテーブルのそれと異なるなんて状況はTCP/IPの通信では普通のことなので、そんなことでおかしくなったりはしません。

> 閲覧したHPのIPアドレスがARPに登録されていない

なにか勘違いがあるようですが、プロトコルの性格上、arpテーブルに登録されるのはPCが接続しているネットワークのIPだけです。他のネットワークへの通信の場合、arpテーブルにはそのネットワークへのgatewayのIPとMACアドレスが載ります。
mixiを見ようがg-mailでメールを書こうが、arpテーブルにはルータのIPとMACアドレスしか載りません。

お礼

回答ありがとうございます。

＞なにか勘違いがあるようですが、プロトコルの性格上、arpテーブルに登録されるのはPCが接続しているネットワークのIPだけです。他のネットワークへの通信の場合、arpテーブルにはそのネットワークへのgatewayのIPとMACアドレスが載ります。

この部分について、どうやら私の方で勘違いしていたようです(^^ゞ
前回のお礼を書いたあとに気づき、補足へ書いたのですが、ARPで解決されたアドレスのみをARPテーブルに保持するということですよね？（ARP要求された側も登録するようですが）

＞なにか勘違いがあるようですが、プロトコルの性格上、arpテーブルに登録されるのはPCが接続しているネットワークのIPだけです。

この部分の勘違いについても、同様な勘違いが原因です。
要は、ARPじゃないパケットが届いたときにもARPテーブルにキャッシュされると思っていました。
（勘違いの原因は、勘違いの動きでも理論的には通信できるからですね^^;）

長らくお付き合いいただきありがとうございました。

回答No.8

root139

No.2 です。
No.7さんの回答が興味深かったので、私の方でも、再度試してみたところ、(問題のPCからは別ネットワークに見える)別PCにも通信できました。

経路は↓でした。

自PC → ルータ(Default Gateway) → 別PC

先日はIPアドレス打ち間違えてたのかも・・・。ごめんなさい。

ちなみに我が家のルータは3～4千円のエントリーモデルですが、ちゃんと中継してくれました。
(^^;

お礼

回答ならびに訂正ありがとうございます。

同じネットワークアドレスでもルータが中継してくれるということですね。

了解です！

回答No.6

bunjii

>デフォルトゲートウェイだけ特別扱いでARP要求を送るのか等が知りたかったのです。
デフォルトゲートウェイの役割をご存じないのでしょうか？

ホストAのアドレス：192.168.1.200
ゲートウェイ　　 ：192.168.1.1

この例ではサブネットマスクを 255.255.255.0（クラスC）にしなければネットワークの整合性がとれません。
ここでデフォルトゲートウェイというのはホストAから見て他のネットワークへの出口にあたるルーター（ゲートウェイ）を指定します。
ホストAにTCP/IPの設定を行うときサブネットマスクが 255.255.255.128 としたとき、ホストAからゲートウェイ（192.168.1.1）宛に送出したパケットは出口を見つけられず消滅するはずです。
ゲートウェイ自身はデフォルトであるという認識は無く、ホストが自身の属しているネットワーク以外の宛先へ送るときにパケットをゲートウェイへ預けます。その預け先のゲートウェイをデフォルトゲートウェイと言っています。

お礼

回答ありがとうございます。

デフォルトゲートウェイの役割は存じ上げており、普通は255.255.255.0にしなければいけないこともわかります。
ただ今回は、実験として質問のようなサブネットマスクにしました。
この質問で通信できることがわかったからといって実際にそのような設定をするつもりはありません。
ただ知識として知りたかったというだけです。

サブネットマスクが間違っていても、質問のような特殊な場合では、私の実験とNo.2さんの実験のとおり、MACアドレスがわかっていれば（わかっていなくてもarpで解決するようですが）通信できるようです。

回答No.5

yokohamahope

No.4です。
＞ホストAからのパケットはデフォルトゲートウェイに送信され、ルーティングされてホストBに届く。
上記のように書きましたが、ルーティングのループを防ぐためにルーティングされないように思えてきました。
（何の機能かは調査未です）

と考えると、No.2さんの以下が納得できます。
＞ちなみに別ネットワークになってしまってたLAN内の別のPCへはPingも通りませんでした。

確かな回答でなくて申し訳ありません。

お礼

回答ありがとうございます。No.4,5まとめてお礼させていただきます。

＞この時デフォルトゲートウェイのMACアドレスがなければ当然ARPで解決が図られる。

というところですが、デフォルトゲートウェイが同じネットワークなら当然ARPで解決されると思いますが、デフォルトゲートウェイが違うネットワークだと分かっているのにARPが出るかどうかというのがわかりませんでした。デフォルトゲートウェイに送る際にMACアドレスが分かっていなければ無条件でARPするような作りなんでしょうか、どうなんでしょうね。

＞ホストAからのパケットはデフォルトゲートウェイに送信され、ルーティングされてホストBに届く。ホストBからのレスポンスはデフォルトゲートウェイを経由しないで（正しいサブネットマスクをもつホストBではホストAを同一ネットワーク内と認識するため）直接ホストAに送られる。

の部分についてですが、ホストBへ行く時の経路はなんとなくそんな感じになりそうな気がしますが、ホストAへ戻ってくるときは、デフォルトゲートウェイからホストBにパケットが行っているため、ホストBから一旦デフォルトゲートウェイに行くのではないでしょうか。MACアドレスって最新のに置き換わるような気がするので。
でもどっちにしろ、デフォルトゲートウェイが中継するなら通信できそうな気がしますね。
結局No.2さんの実験の結果がすべてなんでしょうけど。tracerouteとかしてくれるとちょっとわかったりしないかな（人任せ（笑））

自分の考えでは、MACアドレスはデフォルトゲートウェイを指しているためパケットは届くんだけど、ネットワーク層での判断（？）的なところで同じネットワークのパケットは弾くんじゃないかなと思ったりしました。ブロードキャストとかでもパケットは届くわけですし。でもブロードキャストとは違うのか。
ちょっとわかりませんね。

本来の質問とは違いますが、これも気になるので誰か回答してくれたらいいなと思います。

回答がつかなかったら締め切りたいと思います。

回答No.4

yokohamahope

CCNAレベルでしかない私の考えは。

１）インターネットへの通信は問題なく行えると思います
　　インターネットへの通信ということは、宛先IPアドレスは今回のようなサブネットマスクの間違いでは（又は正しかろうと）、他ネットワークと認識されるので、ホストAからはデフォルトゲートウェイにパケットは送出される。この時デフォルトゲートウェイのMACアドレスがなければ当然ARPで解決が図られる。

２）ホストBへの通信はどうなるか
　　仮に192.168.1.2のアドレスを持つホストBが存在し、ホストAからホストBへの通信ではどうなるか、推測ですが。
　　ホストAからのパケットはデフォルトゲートウェイに送信され、ルーティングされてホストBに届く。ホストBからのレスポンスはデフォルトゲートウェイを経由しないで（正しいサブネットマスクをもつホストBではホストAを同一ネットワーク内と認識するため）直接ホストAに送られる。

上記のように考えますがいかがでしょうか。

回答No.3

bunjii

サブネットマスクでクラスC以下のネットワークを設定する方法になりますので、通信出来なくなります。

サブネットマスクは以下のように規定されています。
クラスA 255.0.0.0 xxx.0.0.0～xxx.255.255.255
クラスB 255.255.0.0 xxx.xxx.0.0～xxx.xxx.255.255
クラスC 255.255.255.0 xxx.xxx.xxx.0～xxx.xxx.xxx.255

クラスC以下の細分化では次のようになります。
２分割 255.255.255.128 xxx.xxx.xxx.0～xxx.xxx.xxx.127
　　　 255.255.255.128 xxx.xxx.xxx.128～xxx.xxx.xxx.255

４分割、８分割などに分割可能です。

あなたの設定では192.168.1.1と192.168.1.200間の通信は物理的な配線で同一に見えるネットワークでも論理的に別のネットワークと見なされますので、192.168.1.200側に別のルーター（ゲートウェイ）が必要です。（192,168.1.129など）
当然ですが、意識的に細分化する場合はルーターのサブネットマスクを同一にしなければなりません。

お礼

そうですね。別ネットワークだとデフォルトゲートウェイに送るため、デフォルトゲートウェイのMACアドレスがわかっていたりしたらどうなるのかや、デフォルトゲートウェイだけ特別扱いでARP要求を送るのか等が知りたかったのです。

回答ありがとうございました。

回答No.2

root139

興味深い内容でしたので WindowsXP SP3 で実験してみました。
下記の様に、arp テーブルをクリアしてから外部へ通信して見たら、普通に通信できてしまいました。

C:\>ipconfig
Windows IP Configuration
Ethernet adapter ローカル エリア接続:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.0.201
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 192.168.0.1

C:\>arp -d
C:\>arp -a
No ARP Entries Found

パケットキャプチャをしてみたところ、意外なことにPC側から Broadcast で 192.168.0.1 のARP要求が出てました。
デフォルトゲートウェイの場合は、自分と違うネットワークのアドレスが設定されていても、ARPするようになっているのかも知れませんね。(Windows の仕様？)
そもそも、デフォルトゲートウェイが自分と違うネットワークのアドレスに設定されている時点で何かが間違っている訳ですからね。

ちなみに別ネットワークになってしまってたLAN内の別のPCへはPingも通りませんでした。

お礼

回答ありがとうございます。

まさに、こんな感じの実験をしたかったのですが、環境がありませんでした。
ARP要求が出るのはOSによっても違うのかもしれませんね。

大変参考になりました！

回答No.1

Toshi0230

ん～、時間がとれなくて検証できてませんが…

> arpテーブルにデフォルトゲートウェイのMACアドレスが登録されているかいないかによっても違うのでしょうか。

違ってくるでしょうね。基本的にnext hopのIPとmacアドレスが判ればパケットを転送できますので。今のPCがWindowsであれば、DOSプロンプトから"arp -d *" とコマンドを実行して、arpテーブルを削除してもう一回やってみてください。多分違う結果が出るのではないかと予想しております。

> 通信前からデフォルトゲートウェイのMACアドレスがarpテーブルにあり

こういう状態は普通有りませんので、試験環境としては特殊になりますね。

普通は質問文のような状況だと通信はできないはずです。

お礼

回答ありがとうございます。

arp -d も試したんですが、なんでか削除できませんでした。
”ARP エントリを削除できませんでした： 87”
と出ました。

普通は通信できないということがわかればOKです。

念のため、他の回答ももう少し待ちたいと思います。