CN1925497A

CN1925497A - 基于vid、mac、ip和用户的绑定方法

Info

Publication number: CN1925497A
Application number: CN 200610002161
Authority: CN
Inventors: 尹志超
Original assignee: REX INFORMATION TECHNOLOGY (BEIJING) Co Ltd
Current assignee: REX INFORMATION TECHNOLOGY (BEIJING) Co Ltd
Priority date: 2006-01-19
Filing date: 2006-01-19
Publication date: 2007-03-07

Abstract

本发明涉及一种计算机网络用户的管理方法，是一种采用VID+MAC+IP+user对用户身份绑定的方法。在网关系统内核通过一个模块专门获取接收到的数据报中的VLAN ID和MAC地址信息，并将VLANID和MAC地址的对应，提供给上层的DHCPD协议；通过设置DHCP server，使DHCPD根据获得的VLANID和MAC地址来分配主机的IP地址；通过设定用户名和特定的VID对应关系，最终实现VID+MAC+IP+user的用户身份绑定，实现对用户身份的管理。

Description

基于VID、MAC、IP和用户的绑定方法

技术领域

本发明涉及一种计算机网络用户的管理方法，是一种采用VID+MAC+IP+user对用户身份绑定的方法。

背景技术

目前，在中小企业内部办公网络和互联网的连接中，通常用户名和密码认证的方法对用户身份进行确认和管理，包括用户能够获得的IP地址和用户对网络资源的使用权限。在进行用户管理的时候，就要获得用户主机的VLAN信息，传统的方法是使用配置文件，将主机的MAC地址与VLAN ID绑定，这中方法不够灵活，给网络管理和配置带来了很大的不便。

发明内容

本发明的目的在于克服论述中使用配置文件将主机的MAC地址与VLAN ID绑定的方法在网络管理和配置中不够灵活而提供一种管理方法。

本发明的目的是通过如下措施来达到：

架设网络时对交换机进行初始配置，通过VLAN交换机将交换机的端口直接与VLAN ID绑定，通过配置使交换机为自己发出的任意一个数据报都加上VLAN ID；

在网关系统内核实现一个模块(DCMSBV_CORE)专门获取接收到的数据报中的VLAN ID和MAC地址信息，并将VLAN ID和MAC地址的对应，提供给上层的DHCPD协议；

通过设置DHCP server，使DHCPD根据获得的VLAN ID和MAC地址米分配主机的IP地址；

通过设定用户名和特定的VID对应关系，最终实现VID+MAC+IP+user的用户身份绑定，实现对用户身份的管理。

系统运行环境如附图1

DCMSBV_CORE就是独立设计开发的用于VLAN驱动的模块。

DCMSBV_CORE是VLAN所需要的内核驱动。与普通的VLAN内核驱动不同，DCMSBV_CORE可以将现有的VLAN任意分组管理，每个组有一个VLANG设备负责数据报的转发，组之间不能重叠。每个VLANG具有一个独立的IP路由意义上的网段，可以单独进行路由。VLANG驱动路由模块能够同时接收所有VLAN的数据报，做一定的处理之后转发给上层网络模块；它同时从上层网络模块接收数据报，并根据数据报的MAC地址填充VID，从而生成有效的VLAN数据报，把数据报传给网络接口设备NIC，数据报到达VLAN交换机之后可以正确的到达目的主机，这就是所谓的路由功能。VLAN驱动路由模块(DCMSBV_CORE)在整个系统中的位置如附图1所示(绿色部分)。DCMSBV_CORE同时完成了MAC地址和VID映射获取的功能。

DCMSBV_CORE的设计：

DCMSBV_CORE模块对广播的处理：

所有来自VLAN的广播只向自己的上层传送，并不分发给每一个VLAN。对于来自上层的广播，则为每个VLAN复制一份，在VLAN内部形成广播，这个功能在函数多次hard_start_xmit函数中完成。

DCMSBV_CORE模块对接收到数据报的处理：

从Linux虚拟网络设备提供的packet_type接口上接收数据报。Linux内核将根据以太网数据帧中的类型字段分发数据报，DCMSBV_CORE向内核注册所有的数据帧类型(ETH_P_ALL)，这将导致操作系统每收到一个数据报都会做一个拷贝之后调用本模块的回调函数。这就是我们接收数据报的原理。需要注意的是，即使是DCMSBV_CORE模块的VLGD设备发送的数据报也回被复制之后再次发送给DCMSBV_CORE模块。

在接受到数据报之后，DCMSBV_CORE要进行如下的处理过程：

1.如果数据报是DCMSBV_CORE模块的设备发送出去的，则释放skb，并直接返回。

2.如果数据报不是VLAN数据报，则做简单的统计之后，直接使用与接收设备相对应的vlgdnull设备发送数据报，之后返回；如果该设备上没有注册vlgdnull设备，则丢弃数据报，直接返回。

3.判断数据报中所指定的VLAN是否属于系统中的某个VLANG设备，如果没有任何VLANG设备负责这个VLAN，则丢弃此数据报。

4.检查数据报中封装的VID与MAC地址映射是否已经存在于MAClist中，如果不存在，则创建一个map_entry，填充相应的属性，加入链表。如果已经存在，并且超时时钟正在工作，则更新超时时钟。

5.确定数据报的类型和目的地。

6.确定数据报中所封装的协议类型，并作相应的处理。现在的系统只处理了三种类型：IP、ARP和RARP。

DCMSBV_CORE模块对发送的数据报的处理：

VLAN数据报的处理：数据报的发送包含了两个过程。首先是创见VLAN帧首部，这过程由dcmsbv_vdev_hard_header函数完成。在我们的实现中，它并没有真正的完成首部的创建，只是为首部创建申请了必要的空间。真正的首部创建在dcmsbv_vdev_hard_start_xmit中完成。函数dcmsbv_vdev_hard_start_xmit同时处理广播数据报。如果数据报是一个广播型数据报，则为每个本VLANG设备管理的VLAN复制一个数据报进行广播，否则只是为指定的VLAN创建首部，并将数据报交给更底层的设备处理(设置skb的dev为底层设备之后，由函数dev_queue_xmit(skb)完成)。

普通数据报的处理：：如果从上层来的数据报所使用的设备是vlgdnull设备，则无需为数据报创建VLAN帧首部，当然也就不需要填充VLANID。对于vlgdnull设备的数据报，在dcmsbv_vdev_hard_header中直接交给底层设备处理首部以太网的首部信息；在dcmsbv_vdev_hard_start_xmit中做判断之后直接使用底层设备发送dev_queue_xmit(skb)。

DCMSBV_CORE与用户空间的通信：

DCMSBV_CORE与用户空间通过netlink进行通信，通信命令用于设置vlang设备和获得DCMSBV_CORE的工作状态，包括：添加和删除VLANG设备、注册和注销VLANG设备上的VLAN、分配和回收IP地址、根据MAC获得VID、列表某个VLANG的map_entry、列表所有的VLANG设备、列表一个VLANG设备上所有的VLAN等功能。

DHCPD的设计：

DHCPD的整体结构如附图3所示。

DHCPD是一个基于消息的串行进程，所有的消息在“DHCPD主控流程“的select上同步。消息通过文件句柄的向DHCPD发送，DHCPD通过select系统调用判断是否有新的消息到达。DHCPD可以处理来自两类文件句柄的消息，一是来自一个socketpair，另外一是来自所有绑定于网络设备上用于接收DHCP报文的文件句柄。

DHCPD通过socketpair接收控制信息。在各种信号处理函数中，DHCPD并不会直接按照信号对应的语义做相应的处理，而是向socketpair的一端写入相应的信号，之后直接退出信号处理。DHCPD在select上监听socketpair的另一端，如果有数据到达，则DHCPD将读取此数据，将此数据作为一个信号，并根据信号类型做相应的处理。当DHCPD收到SIGUSER1信号，它将在socketpair的一端写入SIGUSER1，在“DHCPD主控流程”中DHCPD就会从socketpair的另一端读取到SIGUSER1，其他信号做类似的处理。当在“DHCPD主控流程”的socketpair中读取到SIGUSER1信号，DHCPD会通过重新解析配置文件进行配置切换；当收到SIGALARM信号，DHCPD将对系统中超时的Lease进行回收，同时保存没有保存过的lease；当收到SIGINT、SIGQUIT、SIGTERM或者SIGKILL信号，DHCPD将退出。

所有的DHCP消息通过与网络设备绑定的socket来接收。针对配置文件中给出的需要监听的每个NIC，DHCPD为它创建两个socket，一个用于接收DHCP_SERVER_PORT上的广播，另一个用于接收DHCP_SERVER_PORT的单播。所配置NIC上的任意一个socket有数据报到达，DHCPD都将读取此数据报并进行处理。

DHCP消息的处理：

根据接收DHCP消息所使用的socket可以确定消息来自哪个网络设备，从而进一步确定消息来自哪一个网络，还可以确定消息是以广播的形式发送的还是以单播的形式发送的。根据DHCP消息所携带的MAC地址可以确定消息来自于哪个VLAN。DHCPDISCOVER和DHCPREQUEST是DHCP协议中两个核心的消息，下面给出了系统对这两个消息的处理过程：

Lease的分配：

DHCPD的Lease分配在函数do_discover中进行，也就是只有在接收到DHCPDISCOVER才会进行lease的分配。

首先DHCPD根据接收DHCP消息的NIC确定主机所在的网络，之后根据网络中的三种声明以次匹配，一旦匹配成功，将不再检查后面的规则。匹配优先级依次为：host、vlan_lease_map_pool、vlan_range_lease_pool。

Host匹配使用MAC地址和VLAN ID进行，如果存在host声明的MAC地址与请求的主机相匹配，而且主机所在的VLAN也与其中的一个host声明相匹配，则host匹配成功；如果存在host声明的MAC地址与请求的主机相匹配，但是主机所在的VLAN与其中的任何一个host声明的VLAN_RANGE都不匹配，则主机不允许位于对应的VLAN，分配失败，DHCPD保持沉默。如果没有host声明与主机的MAC地址相匹配，则进入下一步，进行vlan_lease_map_pool的匹配。

如果在任意一个的vlan_lease_map_pool声明中存在一个VLANID与主机所在的VLAN相同，则vlan_lease_map_pool匹配成功，如果对应的IP地址已经分配出去，则回收此IP地址和对应的lease，重新分配给请求的主机；如果IP地址空闲，则直接分配。如果所有的vlan_lease_map_pool声明中都没有VLAN ID与请求主机所在的VLAN对应，则进入下一步进行vlan_range_lease_pool的匹配。

如果在所有的vlan_range_lease_pool声明中，存在一个vlan_range_lease_pool的VLAN_RANGE与主机所在的VLAN匹配，则匹配成功，如果在此vlan_range_lease_pool中找到一个空闲的lease，则分配成功，否则分配失败。如果没有任何一个vlan_range_lease_pool的VLAN_RANGE与主机所在的VLAN匹配，则分配结束，同时通知管理员没有为对应的VLAN配置lease。

Lease的确认和更新：

Lease的确认和更新是一个比较简单的过程，通过do_request函数完成。

如果DHCP消息中的caddr不是0，并且客户端使用的广播的形式发送数据报，则其客户端处于rebind的状态，否则客户端正处于renew的状态；如果caddr是0，则客户端处于selecting(消息中包含SERVER_ID)或者init-reboot状态(消息中不包含SERVER_ID)。

不管客户端出于那种状态，DHCPD中必须有对应的lease才会进行下一步操作，否则向客户端发送NAK，直接返回。

DHCPD根据消息中的MAC地址查找lease，如果没有查找到则向客户端发送NAK后返回；如果查找到，但是lease的VLAN与消息来源的VLAN不同，则回收IP地址，释放lease，并向客户端发送NAK；如果申请的IP地址与lease的IP地址不相同，则回收IP地址，释放lease，并向客户端发送NAK。如果上述检测都合法，则向客户端发送ACK。

Lease的维护

Lease的数据结构如下：

struct lease{

u32 ipaddr；

u_char hwa_ether[6]；

u16 vlan_id；

u32 start_time；

u32 expired_time；//this time can be any expired time.

u32 flags；

u32 status；

void *container；

struct lease_list ipalist；

struct lease_list hwalist；

}；

其中ipaddr给出了lease对应的IP地址；hwa_ehter给出与lease绑定的主机的以太网地址；vlan_id给出主机所在的VLAN；start_time给出lease开始的绝对时间；expired_time给出lease结束的绝对时间；flags是一些标记，现在只使用了三个，用于表示lease的来源，LEASE_TYPE_HOST说明lease来自于host声明，LEASE_TYPE_VLAN_MAP说明lease来自于vlan_lease_map_pool声明，LEASE_TYPE_VLAN_RANGE说明lease来自于vlan_range_lease_pool声明；status用于给出lease当前的状态，lease可以出于以下状态：LEASE_STATUS_FREE(没有使用)，LEASE_STATUS_OFFERED(已经作为offer提供给某个主机)，LEASE_STATUS_ACKED(已经作为正式的lease提供给某个主机)，LEASE_STATUS_SYNCED(lease已经保存过)，LEASE_STATUS_DECLINED(lease已经被主机通过DHCPDECLINE拒绝)；container是一个指针，它可以指向一个host结构，一个vlan_range_lease_pool或者一个vlan_lease_map_pool结构，根据flags的值而定；ipalist和hwalist是两个链表，用于lease的快速查找，ipalist用于根据ip地址进行hash查表，hwalist用于根据MAC地址进行hash查表。

Lease的超时处理：

DHCPD会每个一段时间(60s)给自己发送一个信号，从而触发lease超时处理。如果检测到lease超时，则回收lease对应的IP地址(如果lease处于LEASE_STATUS_ACKED状态)，释放lease。

Lease每种状态超时时间的计算不同，但是都是在改变状态的同时设置lease的超时时间，在检测lease是否超时时只需要将其expired_time与当前时间比较既可。

Lease的保存：

在Lease超时处理的同时会检测lease是否已经被保存过，如果没有保存过(LEASE_STATUS_SYNCED没有置位)，则保存lease，并设置LEASE_STATUS_SYNCED位，否则不作处理。

在进行配置文件切换和DHCPD退出时也会进行同样的处理，以便于后来的恢复。

Lease的恢复：

在成功解析配置文件之后会进行Lease的恢复。Lease的恢复也就是从保存的文件(leasedb)中恢复。以次读取lease数据，并在新配置中恢复。如果新配置不在允许lease的存在，则丢弃该lease。在全部lease恢复完成之后，DHCPD会检查当前lease与DCMSBV模块IP-MAC地址映射的一致性，并强制DCMSBV模块与DHCPD的lease一致。

附图说明

图1是系统结构图

图2是DCMSBV_CORE模块结构图

图3是DHCPD的整体结构图

具体实施方式

图1是本发明的VID+MAC+IP+user用户身份绑定的一个具体实施。该技术与现有技术相比，其最突出的区别特征在于：使用了自主独立研发的DCMSBV_CORE模块对NIC发送和接收的数据报进行处理，并重新修改了DHCPD。

图2是DCMSBV_CORE模块结构图。在模块内部，当从NIC接收到数据报时，获取数据报的VID和MAC的映射关系，并更新MAC/VID/IP的映射表；当从IP路由层接收到数据报时利用MAC/VID/IP的映射表的信息为数据报填充VID，以使数据报正确到达目标主机。当DHCPD需要MAC/VID的映射关系时，通过模块提供的netlink接口从内核获取；当DHCPD分配了一个地址或者回收了一个地址时，也通过netlink接口通知内核模块，内核模块更新MAC/VID/IP的映射表。

图3是DHCPD的整体结构图。启动DHCPD之后，它首先解析命令行参数，检查pidfile以判断是否有另外一个DHCPD在运行，如果没有，初始化与DCMSBV通信的部分，创建一个socketpair，并且注册相关的几个信号，给自己发送一个SIGUSER1信号之后进入“DHCPD主控流程”，这是一个无限循环，直到DHCPD收到退出信号为止。

Claims

一种采用VID+MAC+IP+user对用户身份绑定的方法，它的特征是采用了新设计的模块，系统通过该模块经过如下步骤来实现用户身份管理：

1.架设网络时对交换机进行初始配置，通过VLAN交换机将交换机的端口直接与VLAN ID绑定，通过配置使交换机为自己发出的任意一个数据报都加上VLAN ID；
2.系统内核内部通过一个模块(DCMSBV_CORE)专门获取接收到的用户数据报中的VLAN ID和MAC地址信息，并将VLAN ID和MAC地址的对应，提供给上层的DHCPD协议；
3.通过设置DHCP server，使DHCPD根据获得的VLAN ID和MAC地址来分配主机的IP地址；
4.通过设定用户名和特定的VID对应关系，实现VID+MAC+IP+user的用户身份绑定，实现对用户身份的管理。