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

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

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

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

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

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

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

3 4
winapi sockets loopback

3 ответа:

Используйте утилиту маршрута командной строки 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

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

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. И наоборот для пакетов, отправленных в NIC IP #2.

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

4

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

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

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

0

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

0