Win32 套接字 - 在发送到其他本地接口时强制 ip 数据包离开物理接口
摘要： 我正在尝试创建套接字以在同一台计算机上存在的两个物理接口之间传递数据，并且 Win32 套接字始终直接在内核中转发流量，而不是通过物理接口推送。有什么方法可以禁用此行为，也许可以通过设备设置、注册表调整、路由表恶作剧或套接字选项？我们使用的是 Windows XP SP3。
一些背景。我正在尝试构建一些完全自动化的 IP 测试来测试我们的自定义 IPv4 设备。我们有一个大型的 Windows XP 计算机实验室，并且为我们连接的每个设备提供单独的物理以太网接口。我们的设备实际上是以太网路由器，每个路由器都有自己的 IP。
我们需要通过我们的设备将数据发送到我们的实验室机器，然后返回到同一台计算机。我们将通过设备发送单播和组播 UDP、TCP 和广播 IP 流量。
我们希望（并且可能需要）流量源自其预定的同一台计算机。 为此，我们配置两个单独的 NIC，每个 NIC 在自己的子网上都有自己的 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 套接字。
正如摘要中所述，数据包永远不会离开机器。我像疯子一样用谷歌搜索，但没有找到太多。有什么想法吗？
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 Windows 的命令行 ROUTE 实用程序。您可以对其进行配置，以便发送到特定子网上的特定 IP 地址的任何 IP 数据包都会发送到另一个 IP/设备。例如：
或者，如果您知道 NIC 接口的索引号，则可以指定它们：
这样，每当数据包发送到 NIC #1 的 IP 时，数据包都会发送到连接到 NIC #2 的设备，这将然后将其传递给 NIC #1。对于发送到 NIC #2 的 IP 的数据包，反之亦然。
例如，如果 PC 通过路由器连接到网络，则这是一项有用的技术，允许 WireShark 捕获本地 IP 流量。从一个本地 IP/端口到另一个本地 IP/端口的数据包可以从路由器弹回 PC，以便它们通过 WireShark 可以监控的物理接口传输（WireShark 将看到每个本地数据包的重复副本 - 一个出站和一个入站 -但您可以过滤掉重复项）。
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock 总是会将数据包数据带入内核空间并在那里进行处理。这就是通用 API 的全部要点，即任何设备都在同一“层”进行处理。如果您想坚持使用 Winsock，我不相信您可以（或不想）解决此问题。
您可以使用
TransmitPackets或TransmitFile删除部分缓冲区复制，但不能在两个设备接口之间进行复制。话虽如此，Winsock 执行的附加缓冲区处理是否存在性能问题？安全问题？
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with
TransmitPacketsorTransmitFile, but not between two device interfaces.That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
在不同的虚拟机中运行测试仪的端点怎么样？那么你只需要一个硬件，但是你将拥有独立的 TCP/IP 堆栈，这些堆栈不知道彼此是本地的（并且大多数虚拟机解决方案将数据包直接通过主机不变地传递，我不认为主机将抓取数据包并将其直接发送到另一个虚拟机，除非您配置虚拟机之间的桥接...但您会将每个虚拟机绑定到不同的物理网络适配器）。
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).