用于数据包注入的Libnet与原始套接字

Question

我需要更有经验的网络程序员关于GNU/Linux系统上包注入的一些意见/建议。我正在开发一个开放源码的C++库，用于数据包注入和嗅探。图书馆是利布匠。在这个页面上有几个例子可以看到库是如何工作的。

我进退两难，我很感激你的想法。目前，图书馆“提供”两种方式来在线路上写包。首先，构建包：

Packet pck = IP()/UDP()/DNS();

)，然后使用Send()函数发送：

pck.Send("eth0");

2)或使用RawSocketSend()函数(它是我用于基准测试的“实验性”函数，但可供用户使用)：

pck.RawSocketSend(sd);

其中sd是套接字描述符。如果数据包有链路层协议(如以太网)，sd应该是数据包套接字描述符。如果不是，应该是一个原始的套接字描述符。

发送数据包的标准和文档化的方式是使用Send()方法。目前，Send()方法使用libnet在线路上写入数据包。

问题是Send()函数比RawSocketSend()慢得多.我经常要做很多棘手和烦人的事情，以适应libcrafter处理协议字段的方式，以正确地使用libnet_build*函数(这会导致性能损失)。每次实现协议时，我都必须查看libnet文档，并使开发过程非常繁琐和缓慢。因此，我想停止使用libnet进行数据包注入，直接在Send()函数中使用原始/数据包套接字。

Libcrafter设计用于处理所有繁琐的包制作工作(校验和计算、字节排序、头长度等)。以一种对用户透明的方式。在最流行的GNU/Linux系统(Ubuntu、Fedora、Debian)上，使用原始/数据包套接字( RawSocketSend函数)，一切都很好。

我使用libnet的唯一原因是可移植性问题。但我不知道也不打算将libcrafter移植到其他系统，而不是GNU/Linux系统。

我的问题是：

1. 在GNU/Linux的包注入库上使用原始/数据包套接字是否谨慎和安全？
2. 如果我决定停止使用libnet，您知道关于GNU/Linux发行版之间带有原始/数据包套接字的可移植性方面应该考虑的一些问题吗？
3. 在内核的未来版本中，原始/包套接字接口可能会改变吗？

非常感谢:-)

Answer 1

开放源码的好处在于，您实际上可以浏览源代码，所以我检查了：http://code.google.com/p/libcrafter/source/browse/libcrafter/crafter/Packet.cpp

看到数据包：：send没有效率:它执行太多的系统调用(每次将设备名称与实际接口匹配)，并调用libnet函数，我猜它每次打开一个套接字并发送数据包。无论如何，发送数据包的开销太大了。

原始发送，我还没有看到函数代码，但我猜它只是使用send()。如果我是您，如果我对sendRawPacket()函数不满意，我只需使用行套接字发送它，我就看到了该包提供了getRawBuffer()函数。

有关原始套接字的更多信息，请访问http://www.tenouk.com/Module43a.html并尝试google。

对于你们的问题：

我不明白你所说的“安全”是什么意思？一般的回答是“是的，小心”

2)关于可移植性，使用原始套接字是POSIX标准的一部分，因此它可以在任何linux上工作，也可能在windows上工作。我不知道libcraft是否可以移植到windows，但是它应该运行在任何linux上。如果没有，你可以贡献给图书馆，并使它可移植。

3)我不能回答关于未来的问题。再说一遍，这是POSIX标准，多年来没有多大变化，将来可能会有变化。我不是先知，但我不认为它在不久的将来会改变。

盖伊