Win32 сокеты - принуждают ip-пакеты покинуть физические интерфейсы при отправке на другие локальные интерфейсы

Question

Резюме: я пытаюсь создать сокеты для передачи данных между двумя физическими интерфейсами, существующими на одной машине, и сокеты Win32 всегда перенаправляют трафик непосредственно в ядро, а не проталкивают через физические интерфейсы. Есть ли способ отключить это поведение, возможно, с помощью настроек устройства, настроек реестра, махинаций таблицы маршрутизации или опций сокетов? Мы используем Windows XP SP3.

Некоторый фон. Я пытаюсь создать несколько полностью автоматизированных IP-тестов для проверки нашего нестандартного оборудования IPv4. У нас есть большая лаборатория машин с Windows XP и индивидуальные физические интерфейсы Ethernet для каждого устройства, к которому мы подключаемся. Наши устройства фактически являются Ethernet-маршрутизаторами, каждый из которых имеет свой IP-адрес.

Нам нужно отправить данные с наших лабораторных машин через наши устройства, а затем обратно на тот же компьютер. Мы будем отправлять Unicast и Multicast UDP, TCP и широковещательный IP-трафик через устройства.

Мы хотим (и, вероятно, нуждаемся) трафик отправляться на той же машине, на которую он предназначен. Для этого мы настраиваем два отдельных сетевых адаптера, каждый из которых имеет собственный IP-адрес в своей подсети, например NIC № 1 с 10.0.0.1/24 и NIC № 2 с 10.0.1.1/24. Наши устройства тогда действуют как простые сквозные маршрутизаторы и имеют два интерфейса: один в подсети 10.0.0.0/24, другой в подсети 10.0.1.0/24, из которого они просто пересылают пакеты туда и обратно.

Для генерации наших данных мы хотели бы иметь возможность использовать сокеты Win32, поскольку они хорошо поняты, хорошо поддерживаются тем, что используют наши клиенты, и, вероятно, будут наиболее быстрым подходом. Инъекция пакетов, вероятно, возможна для UDP и широковещательного IP, но, скорее всего, не так для TCP. Я бы придерживался идей, в которых использовалось внедрение пакетов, но я бы предпочел стандартные сокеты Win32.

Как указано в сводке, пакеты никогда не покидают машину. Я гуглил как сумасшедший и не нашел много. Есть идеи?

Answer 1

Используйте утилиту ROUTE для командной строки Windows. Вы можете настроить его так, чтобы любой IP-пакет, отправленный на определенный IP-адрес в определенной подсети, отправлялся на другой IP-адрес или устройство. Например:

route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1

В качестве альтернативы, если вам известны номера индексов интерфейсов NIC, вы можете указать их вместо:

route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>

Таким образом, всякий раз, когда пакет отправляется на IP-адрес NIC # 1, пакет отправляется на устройство, подключенное к NIC # 2, который затем передает его на NIC # 1. И наоборот, для пакетов, отправляемых на IP-адрес NIC # 2.

Например, это полезный метод, позволяющий WireShark перехватывать локальный IP-трафик, если ПК подключен к сети с маршрутизатором. Пакеты с одного локального IP-порта на другой локальный IP-порт можно отскочить от маршрутизатора до ПК, чтобы они проходили через физические интерфейсы, которые может отслеживать WireShark (WireShark будет видеть дубликаты каждого локального пакета - один исходящий и один входящий). но вы можете отфильтровать дубликаты).

Answer 2

Как насчет запуска конечных точек вашего тестера внутри отдельных виртуальных машин? Тогда вам понадобится только один аппаратный элемент, но у вас будут отдельные стеки TCP / IP, которые не знают друг друга локально (и большинство решений виртуальных машин пропускают пакет через хост без изменений, я не думаю, что хост собирается захватить пакет и отправить его прямо на другую виртуальную машину, если вы не настроите мостовое соединение между виртуальными машинами ... но вы будете привязывать каждую виртуальную машину к отдельному физическому сетевому адаптеру).

Answer 3

Winsock всегда собирается переносить пакетные данные в пространство ядра и обрабатывать их там.В этом весь смысл универсального API в том, что любое устройство работает на одном и том же «уровне».Если вы хотите придерживаться Winsock, я не думаю, что вы можете (или хотели бы) обойти это поведение.

Вы можете удалить часть буфера копирования с помощью TransmitPackets или TransmitFile, ноне между двумя интерфейсами устройств.

При этом у вас есть проблемы с производительностью при дополнительном копировании буфера, которое выполняет Winsock?Проблемы безопасности?