web-dev-qa-db-ja.com

静的ルートのゲートウェイのIPアドレスはルーティングにどのように影響しますか

私はWindows7コンピューターを使用して、同じ物理ネットワーク上にあるが異なるサブネット上にあるWindows10コンピューターに接続しています。 Windows 7に静的ルートを追加する前は、すべてのトラフィックがメインルーターに行き、次にWindows 10に戻っていました。これにより、RDP接続の開始に長い遅延が発生したため、Windows7に静的ルートを追加して最上位ルーターを回避しました。 。間違えて動作してしまいましたが、理由はわかりません。

ネットワーク図

Network diagram

Windows7の静的ルート

1. None
2. route add 10.1.1.0 mask 255.255.255.0 10.1.0.99
3. route add 10.1.1.0 mask 255.255.255.0 10.1.1.3
  • route 1tracertを使用すると、10.1.0.98 -> 10.1.0.1 -> 10.1.0.99 -> 10.1.1.4が表示されます
  • route 2tracertを使用すると、10.1.0.98 -> 10.1.0.99 -> 10.1.1.4が表示されます
  • route 3tracertを使用すると、10.1.0.98 -> 10.1.0.99 -> 10.1.1.4が表示されます

route 2が機能する理由は理解できますが、route 3も機能する理由はわかりません。

PS：誰かがより明確なタイトルを提案できるなら、そうしてください。

networkingroutingtraceroutestatic-routes
2
chew socks

ルート3は、UbuntuコンピューターによるARPパケットの処理方法が原因で機能します。 10.1.1.3のARP要求は、10.1.0.0/24に送信され、10.1.0.99インターフェイスで受信されます。そのコンピュータまたは10.1.1.3を所有しているので、10.1.0.99のハードウェアアドレスで応答します。後でWindows7コンピューターがWindows10コンピューターへのRDP接続を試みたとき、10.1.1.3ゲートウェイ宛てのパケットを送信しますが、スイッチが直接転送できる同じサブネット上のコンピューターのMACアドレスを伝送します。

それを確認するために

Windows7の場合

.\Arping.exe -i 10.1.0.98 -T 10.1.1.3

Ubuntuの場合

22:19:51.275116 (Windows 7 MAC) > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1.1.3 tell 10.1.0.98, length 46
2
chew socks

ルート3の魔法は、一部はアドレス解決プロトコルのため、一部は転送テーブルのため、一部はルーティングアルゴリズムのために機能します。

ウィキペディア 言う ：

アドレス解決プロトコル（ARP）は、特定のインターネット層アドレス（通常はIPv4アドレス）に関連付けられたMACアドレスなどのリンク層アドレスを検出するために使用される通信プロトコルです。

多くのオペレーティングシステムは、起動時にGratuitous ARPを実行します。これは、たとえば、ネットワークカードが最近変更され（IPアドレスからMACアドレスへのマッピングを変更）、他のホストのARPキャッシュに古いマッピングが残っている場合に発生する問題の解決に役立ちます。

したがって、Ubuntuは起動時に、接続先の両方のサブネット、つまりネットワーク全体での存在とインターフェースを発表しました。 Windows 10によって行われた同様のアナウンスはサブネット内でのみ行われたため、Windows 7に到達することはありませんでした。そのようなアナウンスが受信されなかった場合でも、Windows 7は一致するものを見つけるために、ARPプロトコルを使用してネットワークにブロードキャストパケットを送信して要求します。 「10.1.1.4を持っている人」。

ここでの大きなヒントは、tracertコマンドがホップの中にルーターをリストしなかったことです。 Windows7が10.1.1.4を認識していなくても、10.1.1.4の要求はUbuntuコンピューターに直接送信されました。

ここで動作しているのはWindowsです IPルーティングテーブル：ルート決定プロセス ：

  • ルーティングテーブルのエントリごとに、宛先IPアドレスとネットワークマスクの間でビット単位の論理ANDを実行します。結果を、一致するエントリのネットワークIDと比較します。

  • 一致するルートのリストがコンパイルされます。 一致が最も長いルート（ビット数が最も多く宛先IPアドレスと一致したルート）が選択されます。一致する最長のルートは、宛先IPアドレスへの最も具体的なルートです。一致時間が最も長いエントリが複数見つかった場合（たとえば、同じネットワークIDへの複数のルート）、ルーターは最小のメトリックを使用して最適なルートを選択します。一致が最も長く、メトリックが最も低いエントリが複数存在する場合、ルータは使用するルーティングテーブルエントリを自由に選択できます。

Windows 7ルーティングは、10.1.1.4と10.1.1.3の間に共通のプレフィックス10.1.1を検出しました。他の可能性は10.1.0.99のルーターまたはUbuntuでしたが、共通のプレフィックスは10.1のみであったため、選択されませんでした。

ここでは、ルーティングテーブルの上に構築された転送テーブルが動作していることがわかります。 ルーティングテーブル はIPアドレスに基づいてルートをコンパイルしますが、転送テーブルには対応するMACアドレスが含まれています。そのため、転送テーブルには、「10.1.1.Xの場合、パケットをUbuntuコンピューターのMACアドレスに転送する」というエントリが含まれていました。パケットがUbuntuコンピューターに到着すると、それを10.1.1.4に転送する方法をよく知っていました。

つまり、これがWindows7からのパケットがWindows10に到達する方法であり、その逆も同様です。

1
harrymc