サブネットマスク/ゲートウェイの設定が誤っている場合の影響

Question

ネットマスク (サブネットマスク) は IP アドレスの一部ではなく、IP ヘッダーのどこにも配置されません。つまり、「192.168.65.96」宛てのパケットは、使用されるネットマスクに関係なく、「192.168.65.96」宛てになります。

代わりに、ネットマスクはルートこれらはパケットの送信時にのみ使用され、受信時には使用されません。つまり、間違ったネットマスクが設定されたホストはパケットを受信できますが、正しく送信できない可能性があります。

パケットを送信する際、ネットマスクをチェックして宛先IPアドレスが同じサブネット内にあるかどうか送信ホストとして:

送信元と送信先の両方が同じサブネットにある場合、MACレベル（「レイヤー2」）でパケットを直接送信できることを意味します。ゲートウェイを使用せずに送信者は ARP を使用して IP アドレスを受信者の MAC アドレスに直接解決します。

したがって、両方のホストが同じサブネット内にある場合 (互いのネットマスクに従って)、その状況ではゲートウェイは必要ないため、ゲートウェイアドレスが誤って構成されていても問題ありません。
もし彼らがない同じサブネット内にある場合はゲートウェイが必要となり、送信者は代わりに ARP を使用してゲートウェイの MAC アドレスを見つけます。

したがって、誤って構成されたネットマスクは、「同じサブネットですか?」テストで誤った結果を返すアドレスとの通信にのみ影響します。

ネットマスクが広すぎます(プレフィックスの長さが短すぎる) 場合や、必要以上に多くのアドレスをカバーしている場合、ネットマスクに誤って含まれているアドレス (ただし、実際にはサブネットに対して「ローカル」ではないアドレス) にパケットを送信できなくなります。

このようなアドレスにパケットを送信しようとすると、ホストは、それらがローカルであるかのように ARP 経由で解決しようとしますが、実際にはローカルではないため、ARP 要求はそれらのアドレスに到達しません。

たとえば、192.168.1.0/24 サブネット内にいるときに、誤ってネットマスクを /16 (255.255.0.0) に設定した場合、192.168.xx の残りの部分との通信が失われます (ただし、192.168.1.x には以前と同じようにアクセスできます)。

（コミュニケーション5月ゲートウェイが「プロキシ ARP」を実装し、「反対側」に代わってそれらの ARP 要求に応答する場合は、それでも可能です。これは、ISP によって「クライアント分離」として、または大規模なサブネットを分割する際の中間ステップとして実際に実行されることがあります。実際、サブネットが発明される前には、プロキシ ARP が大規模なクラスフルネットワークを分割するために使用されていました。

どちらの方法でも、サブネット内に実際に存在するローカルホストや、間違ったネットマスクがカバーしていないリモートホストと通信できるため、しばらくは気付かれない可能性があります。
ネットマスクが狭すぎる(プレフィックス長が長すぎる) ため、カバーすべきアドレスをカバーしていない場合は、逆の結果になります。つまり、ホストがそれらのアドレスに対してゲートウェイを通過する必要があると判断するため、ネットマスクが誤って除外したサブネットの部分と通信できない可能性があります。

もしそこにあるならはゲートウェイの場合、パケットを同じサブネットに戻すだけで、まだ動作しますが、非常に非効率的です。ゲートウェイは、より直接的なパスが存在することを通知する ICMP「リダイレクト」パケットを送信する場合もあり、OS はルーティングテーブルを自動的に更新して、直接通信を再び可能にする場合があります。そのため、誤った構成は長い間気付かれない可能性があります。

しかし、ネットマスクが狭すぎるとそしてゲートウェイが間違っている場合、それらのアドレスにパケットをまったく送信できなくなります。ホストは存在しないゲートウェイを経由してパケットを送信しようとします。

どちらの状況でも、影響を受ける宛先は、「正しい」ネットマスクと「間違った」ネットマスクが異なる結果を返す宛先のみです。

Answer 1