linux收发包内核进程名称,Linux内核IP Queue机制的分析（一）——用户态接收数据包...

缺乏、安全感 2023-01-19 15:57 287阅读 0赞

序

笔者将会通过包括本文在内的三篇文章，对IP Queue机制从用户态的应用到内核态的模块程序设计进行分析。三篇文章的题目分别是：

Linux内核IP Queue机制的分析(一)——用户态接收数据包

Linux内核IP Queue机制的分析(二)——用户态处理并回传数据包

Linux内核IP Queue机制的分析(三)——内核态ip\_queue代码分析

笔者希望通过这三篇文章，能够给不熟悉或者对IP Queue使用有问题的朋友一些帮助。文章中分析不妥或错误之处，希望各位朋友可以及时指出。

本文欢迎自由转载，但请标明出处，并保证本文的完整性。

作者：Godbach

日期：2008/11/27

本文的大纲如下：

一、基础知识

1. Netfilter

2. Netlink机制

二、IP Queue编程接口

三、一个实现接收内核态发送的IP Queue数据包的用户态例程

1. libipq.h

2. libipq.c

3. ipq\_user.c

四、应用程序的测试

1.测试环境的建立

2.程序的测试

基础知识部分的很多部分内容都重点参考或者直接引用了《如何用IP Queue机制编写用户态防火墙》，原文的链接为：。在此，向该文的作者表示感谢。

Linux内核在Netfilter(下文简称NF)框架的基础上提供了IP Queue机制，使得基于用户态(User Mode)的防火墙开发成为可能。

内核中NF对网络报文的处理这里不做详细描述。假设读者已经熟悉NF的工作原理和工作流程。但这里还是要简单介绍一下NF中各个钩子(hook)函数对数据包处理的返回值，即该函数告诉内核对该数据包的处理意见。所有的返回值如下：

NF\_DROP：丢弃该报文，释放所有与该报文相关的资源；

NF\_ACCEPT：接受该报文，并继续处理；

NF\_STOLEN：该报文已经被HOOK函数接管，协议栈无须继续处理；

NF\_QUEUE：将该报文传递到用户态去做进一步的处理；

NF\_REPEAT：再次调用本HOOK函数。

当HOOK处理函数返回值为NF\_QUEUE时，内核协议栈将通过IP Queue机制把当前报文传递到用户态，由用户态的应用程序进行处理。这样，只要能够在相应的HOOK点上返回NF\_QUEUE值，就可以将符合要求的报文传送到用户态去做进一步对报文行处理。随后，用户态程序会将处理后的报文以及对报文的处理意见(ACCEPT，DROP等)传递给内核协议栈。内核协议栈就会按照用户态对报文的处理意见将报文做接受、丢弃等处理。整个处理的过程就相当于一个用户态的防火墙，所有数据包的实质性处理都放在用户态进行。这样，即使是不具有深入内核知识的开发人员，也可以开发出适应一定应用场合的用户态防火墙。

机制

前面讲到，所谓IP Queue机制，只是当NF上Hook函数对数据包处理的返回值为NF\_QUEUE时，协议栈会将数据包交给内核中的ip\_queue模块。而ip\_queue又是怎么将数据包传递给用户态的呢？这里就涉及到在内核开发中常见的问题，如何将内核态的数据传递到用户态，实现内核空间和用户空间的通信。具体实现的方法有多种。本人的博客中也总结了若干种，并配有测试的例程：对于IP Queue，则是使用Netlink机制实现内核态和用户态的交互。

NetLink是Linux系统特有的、基于socket编程接口的通信机制。它是一个面向数据报文的服务，并提供NETLINK\_ROUTE(更新和修改路由操作)、NETLINK\_FIREWALL(接受和发送IPv4协议NF传输的包，基于内核的ip\_queue模块)，NETLINK\_ARPD(用户态ARP表操作)等多种通信协议。在创建基于IP Queue的NetLink Socket时，将采用如下系统调用：

fd =

socket(PF\_NETLINK, SOCK\_RAW, NETLINK\_FIREWALL);这里，PF\_NETLINK指明要创建NetLink Socket；SOCK\_RAW指明采用原始套接字，也可以采用SOCK\_DGRAM，因为NetLink机制的实现并不区分SOCK\_RAW和SOCK\_DGRAM；参数NETLINK\_FIREWALL则指明通信协议采用IP Queue。

既然IP Queue是基于NetLink的，其消息格式自然也遵从NetLink的规范。NetLink消息由两部分组成：消息头(struct nlmsghdr)和数据负载(data payload)。

消息头的定义如下(include/linux/netlink.h)：

\[quote\]

struct nlmsghdr

\_\_u32 nlmsg\_len;

/\*消息长度\*/

\_\_u16

nlmsg\_type;/\*消息类型\*/

\_\_u16

nlmsg\_flags;/\*额外的标志\*/

\_\_u32

nlmsg\_seq; /\*序列号\*/

\_\_u32

nlmsg\_pid; /\*进程号\*/

\};

\[/quote\]

struct nlmsghdr

\_\_u32 nlmsg\_len;

/\*消息长度\*/

\_\_u16

nlmsg\_type;/\*消息类型\*/

\_\_u16

nlmsg\_flags;/\*额外的标志\*/

\_\_u32

nlmsg\_seq; /\*序列号\*/

\_\_u32

nlmsg\_pid; /\*进程号\*/

\};

所有的IP Queue消息都将包含一个struct nlmsghdr消息头，具体的IP Queue消息则包含在NetLink消息的数据负载中。有关NetLink消息格式的详情可以参见手册页Netlink(7)。

Queue编程接口

使用IP Queue机制的程序必须包含如下的头文件：

\#include

在这个头文件中定义了所有IP Queue消息的格式。以下谈到关于IP Queue的若干个数据结构以及宏定义都包含在该文头件。

IP Queue消息可以分为两大类：由内核协议栈发给用户态进程的IP Queue消息和由用户态进程发给内核的IP Queue消息。

由内核协议栈发给用户态进程的IP Queue消息(nlmsghdr.nlmsg\_type =

IPQM\_PACKET)，其数据结构为ipq\_packet\_msg\_t，定义如下：

/\* Messages

sent from kernel \*/

typedef struct

ipq\_packet\_msg \{

unsigned long packet\_id;/\*报文的ID号\*/

unsigned long mark;/\* NF标记值\*/

long timestamp\_sec;/\*报文到达时间(秒)\*/

long timestamp\_usec;/\*报文到达时间(毫秒)\*/

unsigned int hook;/\*报文所处的NF hook点\*/

char indev\_name\[IFNAMSIZ\];/\*流入网口名称\*/

char outdev\_name\[IFNAMSIZ\];/\*流出网口名称\*/

unsigned short hw\_protocol;/\*硬件协议(网络顺序)\*/

unsigned short hw\_type;/\*硬件类型\*/

unsigned char hw\_addrlen;/\*硬件地址长度\*/

unsigned char hw\_addr\[8\];/\*硬件地址\*/

size\_t data\_len;/\*报文数据的长度\*/

unsigned char payload\[0\];/\*报文本身的数据，可选\*/

ipq\_packet\_msg\_t;

这个数据结构也被称为“报文的元数据”。个人理解，所谓“报文的元数据”应该是关于报文的摘要信息，而不包括报文数据的本身。从上面的这个结构体中也可以看出来。内核除可以单独向用户进程传递“报文的元数据”以外，也可以同时传递报文本身。此时，报文本身的数据将存储在ipq\_packet\_msg\_t数据成员payload开始的地方。

至于内核在什么情况下向用户传递报文的元数据，什么情况下向用户传递报文的元数据加报文本身的数据，那就要看用户所请求的模式了。下面将讲述用户态发到内核态消息的格式，也正好解答了我们这里提出的问题。

用户态发到内核态的消息，其数据结构如下所示：

typedef struct

ipq\_peer\_msg \{

union \{

ipq\_verdict\_msg\_t verdict;

ipq\_mode\_msg\_t mode;

\} msg;

ipq\_peer\_msg\_t;

通过该数据结构可知，这类消息又分为“模式设置消息(nlmsghdr.nlmsg\_type = IPQM\_MODE)”和“断言消息(nlmsghdr.nlmsg\_type = IPQM\_VERDICT)”两个子类。

“模式设置消息”的数据结构定义如下：

typedef struct ipq\_mode\_msg \{

unsigned char value;/\*请求的模式\*/

size\_t range;/\*请求拷贝的报文长度\*/

\} ipq\_mode\_msg\_t;

这里，请求模式value的值可以是IPQ\_COPY\_NONE、IPQ\_COPY\_META和IPQ\_COPY\_PACKET，具体解释如下：

(1)请求模式value为IPQ\_COPY\_NONE时，报文将被丢弃；

(2)请求模式value为IPQ\_COPY\_META时，内核将在其后的报文传递中只传递“报文的元数据”。

以上两种情形传递range的值将被内核忽略。内核中会将该值置为0。

(3)请求模式value为IPQ\_COPY\_PACKET时，内核将同时传递“报文的元数据”和报文本身，报文本身的传递长度由ipq\_mode\_msg\_t的另一个数据成员range指定。range的最大值不能超过IP报文的最大长度，也就是0xFFFF。否则，会被自动置为0xFFFF。如果请求的长度大于报文自身的长度，将会按照报文自身长度进行传递。

另一子类即“断言消息”，其数据类型定义如下：typedef struct

ipq\_verdict\_msg \{

unsigned int

value;

unsigned long

id;

size\_t

data\_len;

unsigned char

payload\[0\];

ipq\_verdict\_msg\_t;

其中，value是用户态程序回传给内核的对当前报文的处理意见，可以是NF\_ACCEPT或NF\_DROP等值。id则是用以区分报文的标识号，即内核传来的ipq\_packet\_msg\_t结构中的packet\_id。当用户态程序修改了当前报文以后，需要将报文重新传递回内核，此时，新的报文内容必须存储在payload的开始处，并由data\_len指明新报文的长度。

从上述内容可以看出，在整个IP Queue的报文传递过程中，用户态程序和内核协议栈之间的互动顺序是：

(1)用户态程序利用“模式设置消息”告诉内核协议栈所请求的报文传递模式；

(2)根据这个模式，内核组织好等待传递的消息，通过NetLink Socket发给用户态程序；

(3)用户态程序对接收到的数据包进行处理，得出该报文的处理意见(可能同时修改当前报文)，并回传给内核。

Queue数据包的用户态例程

由于IP Queue是使用Netlink机制进行内核态和用户态通信的。因此，用户态要接收内核态发送的IP Queue数据包，就需要设计相应的Netlink程序，也就是设计相应的基于Netlink的socket程序即可。这里，我不会详细介绍如何使用Netlink机制实现用户态和内核态进行通信。我假设阅读本文的朋友，已经熟悉了Netlink的使用。如果对Netlink的使用还不是很熟悉，那么可以参考独孤九贱大侠的文章——《Linux用户态与内核态的交互——netlink篇》，其链接为：

这篇文章提供了一个使用netlink的完整的例程，包括内核态和用户态。讲的非常清楚，我看完这篇文章，又跑了一下上面提供的例程，基本上熟悉了Netlink的使用方法。

当然，如果读者不想花时间再去了解netlink的话，也可以通过这篇文章熟悉Netlink的使用。因为我这里提供的是完整的用户态例程，我会将源码完全提供出来，对于急于通过执行程序观察结果来学习Netlink和IP Queue的朋友，也可以通过随后提供的方法编译并执行程序。

以下讲述用户态例程接收IP Queue数据包的程序设计。

其实，由于Netlink程序也是使用socket的方式进行通信。那么接收IP Queue报文的方式应该遵循socket的标准流程，具体流程如下：

(1)调用socket()创建一个地址类型为PF\_NETLINK(AF\_NETLINK)的套接字。该套接字使用SOCK\_RAW方式传输数据，协议类型为NETLINK\_FIREWALL，即使用IP Queue；

(2)调用bind()将本地地址(Netlink通信双方使用该协议特有的地址格式，见下面struct sockaddr\_nl)绑定到已建立的套接字上；

struct sockaddr\_nl \{

sa\_family\_tnl\_family;/\* AF\_NETLINK \*/

unsigned shortnl\_pad;/\* Zero. \*/

pid\_tnl\_pid;/\* Process ID. \*/

\_\_u32nl\_groups;/\* Multicast groups mask. \*/

\};

(3)调用sendto()发送相关的配置信息，告诉内核应用程序准备接受的是数据包的元数据，还是同时包括数据包本身；

(4)调用recvfrom()接受内核态发送来的IP Queue报文；

(5)调用close()关闭套接字，结束通信。

看了以上流程，我相信很多熟悉socket编程的朋友已经可以写出接收IP Queue报文的用户态程序了。

本文中的示例代码的实现整体也是依照上面的步骤。但在细节的实现上，参考了iptables源码给给出的libipq库的实现代码。libipq库是iptables中封装的实现用户态接收和发送IP Queue报文操作的，也就相当于对上面总结的IP Queue报文接受流程进行封装。整个libipq库分别由libipq.c和libipq.h两个源文件。我这里将两个源文件移植(基于iptables-1.3.5版本)到示例代码中并裁剪，并编写了测试程序ip\_user.c。因此，整个实现代码包含三个源文件：ip\_user.c、libipq.c和libipq.h。

以下将对三个源文件进行分析。

该头文件定义了一个关键的数据结构，并提供了所有进行Netlink通信的API.

数据结构的定义如下：

struct

ipq\_handle

int fd;

struct sockaddr\_nl local;

struct sockaddr\_nl peer;

\};

其中，fd是socket通信的描述符，local和peer分别是Netlink通信双方的地址。

除了定义数据结构，剩下的主要就是提供给用户调用的API，函数列表如下：

struct

ipq\_handle \*ipq\_create\_handle(u\_int32\_t flags, u\_int32\_t protocol);

int

ipq\_destroy\_handle(struct ipq\_handle \*h);

ssize\_t

ipq\_read(const struct ipq\_handle \*h, unsigned char \*buf, size\_t len);

int

ipq\_set\_mode(const struct ipq\_handle \*h, u\_int8\_t mode, size\_t len);

ipq\_packet\_msg\_t

\*ipq\_get\_packet(const unsigned char \*buf);

int

ipq\_message\_type(const unsigned char \*buf);

int

ipq\_get\_msgerr(const unsigned char \*buf);

int

ipq\_set\_verdict(const struct ipq\_handle \*h,

ipq\_id\_t id,

unsigned int verdict,

size\_t data\_len,

unsigned char \*buf);

int

ipq\_ctl(const struct ipq\_handle \*h, int request, ...);

char

\*ipq\_errstr(void);

void

ipq\_perror(const char \*s);

我将在下面libipq.c的讲解中对若干我们将要用到的一些函数进行分析。

该源文件实现了libipq.h中定义的所有函数，并定义了一些出错信息。

(1)ipq\_create\_handle()函数申请了一个struct ipq\_handle \*h结构体，用来存储随后创建的IPv4 socket通信的fd，以及通信双方的地址。本函数完成了通信双方地址的初始化，并将本地地址绑定到已生成的fd上。

ipq\_create\_handle()函数的源码如下

struct

ipq\_handle \*ipq\_create\_handle()

int status;

struct ipq\_handle \*h;

h = (struct ipq\_handle \*)malloc(sizeof(struct

ipq\_handle));

if (h == NULL) \{

ipq\_errno = IPQ\_ERR\_HANDLE;

return NULL;

memset(h, 0, sizeof(struct ipq\_handle));

if (protocol == PF\_INET)

h->fd

= socket(PF\_NETLINK, SOCK\_RAW, NETLINK\_FIREWALL);

else \{

ipq\_errno = IPQ\_ERR\_PROTOCOL;

free(h);

return NULL;

if (h->fd == -1) \{

ipq\_errno = IPQ\_ERR\_SOCKET;

close(h->fd);

free(h);

return NULL;

memset(&h->local, 0, sizeof(struct

sockaddr\_nl));

h->local.nl\_family = AF\_NETLINK;

/\*传递本地的pid\*/

h->local.nl\_pid = getpid();

h->local.nl\_groups = 0;

status = bind(h->fd, (struct sockaddr

\*)&h->local, sizeof(h->local));

if (status == -1) \{

ipq\_errno = IPQ\_ERR\_BIND;

close(h->fd);

free(h);

return NULL;

memset(&h->peer, 0, sizeof(struct

sockaddr\_nl));

h->peer.nl\_family = AF\_NETLINK;

/\*代表通信的另一方为内核\*/

h->peer.nl\_pid = 0;

h->peer.nl\_groups = 0;

return h;

ipq\_destroy\_handle()函数关闭由ipq\_create\_handle()建立起来的fd，并释放申请的内存。源码如下：

int

ipq\_destroy\_handle(struct ipq\_handle \*h)

if (h) \{

close(h->fd);

free(h);

return 0;

(2)向内核发送模式请求的函数

int

ipq\_set\_mode(const struct ipq\_handle \*h,

u\_int8\_t mode, size\_t range)

/\*构造一个向内核发送报文的结构体\*/

struct \{

struct nlmsghdr nlh;

ipq\_peer\_msg\_t pm;

\} req;

memset(&req, 0, sizeof(req));

req.nlh.nlmsg\_len =

NLMSG\_LENGTH(sizeof(req));

req.nlh.nlmsg\_flags = NLM\_F\_REQUEST;

req.nlh.nlmsg\_type = IPQM\_MODE;

req.nlh.nlmsg\_pid = h->local.nl\_pid;

/\*告诉协议栈所请求的报文传递模式\*/

req.pm.msg.mode.value = mode;

/\*请求内核返回报文的长度\*/

req.pm.msg.mode.range = range;

return ipq\_netlink\_sendto(h, (void

\*)&req, req.nlh.nlmsg\_len);

在构造完向内核发送的结构体req并设置相关内容之后，调用ipq\_netlink\_sendto函数发送用户态的请求数据，该函数代码如下：

static ssize\_t

ipq\_netlink\_sendto(const struct ipq\_handle \*h,

const void

\*msg, size\_t len)

int status = sendto(h->fd, msg, len, 0,

(struct sockaddr

\*)&h->peer, sizeof(h->peer));

if (status < 0)

ipq\_errno = IPQ\_ERR\_SEND;

return status;

ipq\_netlink\_sendto函数直接调用了sendto系统调用发送用户态的数据，返回的是发送出去的数据长度。当sendto调用失败时，对全局变量ipq\_errno赋值IPQ\_ERR\_SEND。这样方便以后用专门返回出错信息的函数引用。

(3)用户态发送了请求数据包之后，就处于等待接收内核返回数据包的状态。一旦内核NF得到包处理函数返回NF\_QUEUE时，该包就会被ip\_queue模块发送到用户态。用户态接收IP Queue数据包的函数为：

ssize\_t

ipq\_read(const struct ipq\_handle \*h, unsigned char \*buf, size\_t len)

该函数的代码如下。其中buf存储来自内核态的数据包，len为buf的长度。

ssize\_t

ipq\_read(const struct ipq\_handle \*h,

unsigned char \*buf, size\_t

len)

return ipq\_netlink\_recvfrom(h, buf, len);

该函数直接调用ipq\_netlink\_recvfrom()函数，其源码为：

static ssize\_t

ipq\_netlink\_recvfrom(const struct ipq\_handle \*h,

unsigned char

\*buf, size\_t len)

unsigned int addrlen;

int status;

struct nlmsghdr \*nlh;

/\*buf长度的校验，不能小于Netlink Message的头部长度\*/

if (len < sizeof(struct nlmsgerr)) \{

ipq\_errno = IPQ\_ERR\_RECVBUF;

return -1;

addrlen = sizeof(h->peer);

status = recvfrom(h->fd, buf, len, 0,

(struct sockaddr

\*)&h->peer, &addrlen);

if (status < 0) \{

ipq\_errno = IPQ\_ERR\_RECV;

return status;

/\*判断接收到的发送方的地址长度是否正确\*/

if (addrlen != sizeof(h->peer)) \{

ipq\_errno = IPQ\_ERR\_RECV;

return -1;

/\*内核态向用户态发送数据报文时，其pid=0\*/

if (h->peer.nl\_pid != 0) \{

ipq\_errno = IPQ\_ERR\_RECV;

return -1;

if (status == 0) \{

ipq\_errno = IPQ\_ERR\_NLEOF;

return -1;

nlh = (struct nlmsghdr \*)buf;

/\*判断是否发生数据报文被截断的情况\*/

if (nlh->nlmsg\_flags & MSG\_TRUNC ||

nlh->nlmsg\_len > status) \{

ipq\_errno = IPQ\_ERR\_RTRUNC;

return -1;

return status;

该函数返回读取到报文的实际长度。

至此，我们已经可以通过上面几个函数实现从内核态接收到既定模式的IP Queue报文。

(4)输出出错信息

char

\*ipq\_errstr(void)

return ipq\_strerror(ipq\_errno);

static char

\*ipq\_strerror(int errcode)

if (errcode < 0 || errcode >

IPQ\_MAXERR)

errcode = IPQ\_ERR\_IMPL;

return ipq\_errmap\[errcode\].message;

根据函数执行过程中记录的出错信息，打印对相关出错的具体提示。

这个函数就是具体的测试函数。功能比较简单，通过调用libipq.c中提供的API实现获取IP Queue数据包的简单信息，包括数据包在本地机上的入口以及报文的长度等，

整个源码如下：

/\*

\* ipq\_usr.c

\* Testing program for receiving IP Queue

packets from kernel 2.6.18.3

\* Dec 1, 2008

\* Godbach created.

\* This program is free software; you can

redistribute it and/or modify

\* it under the terms of the GNU General Public

License as published by

\* the Free Software Foundation; either version

2 of the License, or

\* (at your option) any later version.

\* This program is distributed in the hope that

it will be useful,

\* but WITHOUT ANY WARRANTY; without even the

implied warranty of

\* MERCHANTABILITY or FITNESS FOR A PARTICULAR

PURPOSE.See the

\* GNU General Public License for more details.

\*/

\#include

"libipq.h"

struct ipq\_handle

\*h = NULL;

static void

sig\_int(int signo)

ipq\_destroy\_handle(h);

printf("Exit: %s\\n",

ipq\_errstr());

exit(0);

int main(void)

unsigned char buf\[1024\];

/\* creat handle\*/

h = ipq\_create\_handle(0, PF\_INET);

if(h == NULL)\{

printf("%s\\n", ipq\_errstr());

return 0;

printf("ipq\_creat\_handle

success!\\n");

/\*set mode\*/

unsigned char mode = IPQ\_COPY\_PACKET;

int range = sizeof(buf);

int ret = ipq\_set\_mode(h, mode, range);

printf("ipq\_set\_mode: send bytes =%d,

range=%d\\n", ret, range);

/\*register signal handler\*/

signal(SIGINT, sig\_int);

/\*read packet from kernel\*/

int status;

struct nlmsghdr \*nlh;

ipq\_packet\_msg\_t \*ipq\_packet;

while(1)\{

status = ipq\_read(h, buf,

sizeof(buf));

if(status > sizeof(struct

nlmsghdr))

nlh = (struct nlmsghdr \*)buf;

ipq\_packet =

ipq\_get\_packet(buf);

printf("recv bytes =%d,

nlmsg\_len=%d, indev=%s, datalen=%d, packet\_id=%x\\n", status,

nlh->nlmsg\_len,

ipq\_packet->indev\_name,ipq\_packet->data\_len,

ipq\_packet->packet\_id);

return 0;

测试环境的建立

(1)内核态：要求已编译的内核支持Netlink机制，并进入内核源码目录net/ipv4/netfilter下，检查是否生成ip\_queue.ko。如果有相应的文件，则确保该模块是否加载，没有加载的话，modprobe ip\_queue进行加载

(2)用户态：要求有已经安装iptables，并加上一条如下规则：

iptables -I

INPUT -p icmp -j QUEUE

这里我们在INPUT链上开始处添加了一条对所有ICMP报文进行IP Queue的规则。通过添加不同的iptables规则，可以对不同的报文进行IP Queue。

如果系统上没有安装iptables的话，那么可以用一个简单的内核模块来实现其功能。即在NF对应的Hook点上注册一个钩子函数，对于某种类型的数据包直接return NF\_QUEUE即可。附件的源码中我提供了一个模块程序，在NF的PRE\_ROUTING出注册了一个对所有ICMP报文return NF\_QUEUE的模块。没有iptables的朋友可以使用这个小模块程序替代。

注意：我这里所使用的内核为2.6.18.3。其他内核版本没有进行测试。不过，个人觉得如果用户态的应用程序应该在2.6上没有问题，只是提供的内核模块程序不能保证。

程序的测试

搭建好上面提示的环境之后，可以对应用程序的源码进行编译：

gcc libipq.c

ipq\_user.c -o ipq\_user

执行ipq\_user:

\[root@localhost

ipq\_user\]\# ./ipq\_user

ipq\_creat\_handle

success!

ipq\_set\_mode:

send bytes =44, range=1024