私はこの構成をLinuxで正常に機能させていますが、Windowsは厄介な戦いを繰り広げています。
Windows 7ボックスは、それぞれが個別のサブネット用に2つのNICでセットアップされています。
Windowsボックスからすべてが正常に動作します。適切なサブネットへの期待されるインターフェースを介してpingを実行して接続を取得できます。 NIC 2サブネットでのpingと接続はNIC 2で動作し、NIC 1でのpingと接続は正常に動作します。
問題は、WindowsがNIC 2。の外部pingに応答しないことです。)== Windowsのインターフェイス統計は、pingが到着していることを示していますが、それらに応答しません。 。NIC 1への外部pingは問題ありません。
ファイアウォールが無効になっています。
任意の提案をいただければ幸いです。これと同じセットアップは、Linuxでは問題なく機能します。
Windows IP Configuration
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::cd15:7e83:1dd8:4531%14
IPv4 Address. . . . . . . . . . . : 192.168.1.7
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : nowhere.com
Link-local IPv6 Address . . . . . : fe80::2c63:4544:c29d:5dfd%11
IPv4 Address. . . . . . . . . . . : 10.13.132.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.13.132.1
$ route print
===========================================================================
Interface List
14...52 54 00 24 8b 8e ......Red Hat VirtIO Ethernet Adapter #2
11...54 52 00 77 87 59 ......Red Hat VirtIO Ethernet Adapter
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.13.132.1 10.13.132.63 266
10.13.132.0 255.255.255.0 On-link 10.13.132.63 266
10.13.132.63 255.255.255.255 On-link 10.13.132.63 266
10.13.132.255 255.255.255.255 On-link 10.13.132.63 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.7 266
192.168.1.7 255.255.255.255 On-link 192.168.1.7 266
192.168.1.255 255.255.255.255 On-link 192.168.1.7 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.13.132.63 266
224.0.0.0 240.0.0.0 On-link 192.168.1.7 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.13.132.63 266
255.255.255.255 255.255.255.255 On-link 192.168.1.7 266
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.13.132.1 Default
===========================================================================
NIC 2へのpingが10.0.0.0/8などの別のサブネット/ネットワークから送信されている場合、ping応答はNICのデフォルトゲートウェイから送信されます。 1.これは、ping応答が10.0.0.0/8アドレスをターゲットにしており、ルーティングテーブルによるそのようなアドレスへのトラフィックがNIC 1を経由するためです。pingコンピューターは認識しません。 NIC 1上のIPはpingを実行しているIPであるため、受信したping応答をドロップします。
残念ながら、現時点では解決策はなく、説明のみです。
Windowsファイアウォール(または別のソフトウェアベースのファイアウォールがある場合)が、2番目のNICでのping応答をブロックしている可能性があります。テスト目的で、ファイアウォールを無効にします。これで問題が解決した場合は、適切なルールを追加して、2番目のインターフェイスからのping応答を許可できます。
また、2番目のインターフェイスのサブネットへの静的ルートを手動で作成することはお勧めしません。 Windowsは、NIC 2で指定したIPアドレス/サブネットマスクの組み合わせにより、そのNICを介してのみサブネットに到達できることを認識しています。2。手動でルートを指定する必要がある唯一の理由NIC2は、そのインターフェイスを介してのみ到達可能な追加のサブネットネットワークがある場合です。この場合、NIC2のネットワークのどこかにルーターがあります。同様に。
IMHOは、すでに自動的に行われていることを手動で行うと、別の変数を追加して、現在トラブルシューティングしている問題を複雑にし、さらに悪いことに、将来の問題を不必要に設定します。