赵江云，董 平，高德云

(北京交通大学电子信息工程学院，北京 100044)

0 引言

近些年来，中国高铁事业发展迅速，在国内外取得了令人瞩目的成就。同时，中国互联网事业也在蓬勃发展，人们对随时随地接入网络的要求也日益增强。高铁列车具有高速运动、强封闭性等特点，造成列车上用户终端设备无线数据信道频繁切换、带宽小、性能衰减等问题［1］。这对高铁上的移动互联网接入提出了挑战。为了应对这些挑战，多种车地通信方案被提出［2-5］。基于隧道技术的移动路由系统设计出全新的路由器体系结构，提供了解决车地通信问题的可行方法。

当前情况下，移动路由系统使用隧道技术，为高铁乘客的互联网接入需求提供解决方案。考虑到路由系统的安全性和计费收费等需求，需要加入认证机制。本文设计并实现的认证机制，能够结合移动路由系统软硬件条件和特殊的架构，在不影响路由系统数据转发功能的前提下，具有轻便、高效的特点，能很好地满足实际需求。

1 移动路由系统与认证机制

1.1 移动路由系统

移动路由系统基于隧道技术。普遍地，隧道技术实现构成可以分为2 部分，即客户端与服务端［6］。与此相对应，如图1 所示，移动路由系统也由2 个主要部分组成，其中车载设备被称为多链路无线接入路由器MAR(Multilink Access Router)，地面服务器被称为多链路边缘路由器MER(Multilink Edge Router)［7］。

图1 基于隧道技术的移动路由系统

MAR 是部署在高铁上的车载设备，其用户设备接口是WiFi 接口，这与普通路由器无异。区别于一般的路由器，MAR 的出口是多块3G 网卡，而普通路由器出口一般是宽带连接或者以太网线。MER 是部署在地面的网络实体，它通过有线以太网链路和公网相连。

移动路由系统中的隧道技术使用了Linux 下的TUN/TAP 设备，TUN/TAP 设备能够在用户空间和内核空间交换数据报［8］。高铁上多个用户设备形成的子网称为移动子网［9］。MAR 作为隧道的一端，通过操作路由，将移动子网的用户数据报通过内核协议栈发送到虚拟网卡TUN。应用程序将数据报从虚拟网卡读出到用户空间，将数据报作为隧道数据报的载荷部分，为其加隧道报头［10］，从3G 网卡通过公网发送到MER。MER 作为隧道的另一端，应用程序从TUN设备上收到数据报之后去掉隧道报头，就能露出原来的数据报。移动子网产生的数据报通过隧道封装解封之后，就能与普通有线接入设备产生的数据报一样，将请求通过MER 发送至公网，并获得响应。

图2 MAR 数据流向

如图2 所示，当在高铁恶劣的无线链路质量情况下，3G 网卡没能成功拨号取得IP 地址时，网络应用程序及时将隧道数据报调度去往别的拨号成功的3G网卡发出;当某块3G 网卡的地址变换时，迅速关闭该网卡上的隧道连接，建立起新的隧道连接，就能继续进行数据传输。对于移动子网内的用户设备来说，与外网的连接始终未能中断，高速移动环境下3G 网卡地址的频繁变换对它们是没有影响的，这样就成功解决了移动子网的数据通信问题。

1.2 移动路由系统中认证机制

移动路由系统中MAR 和MER 均采用x86 架构硬件平台，软件平台为Linux 的Fedora 或者Ubuntu版本。认证机制的实现需要结合该软硬件条件。

目前主要的互联网认证技术有以下3 种方法:PPPoE 认证、IEEE802.1x 认证和基于Web 的认证［11-12］。相比于PPPoE 认证和IEEE802.1X 认证，Web 认证只需要终端用户设备安装有Web 浏览器即可，降低了对终端用户设备的配置要求，同时，便于认证系统的升级与完善［13］。综上所述，移动路由系统中认证机制应该采用Web 认证技术。

认证机制应该达到如下基本要求:用户访问放行网段，认证机制应予以直接放行;用户访问分放行网段，应首先使用浏览器进行Web 认证，输入正常用户名和密码之后，再次访问放行网段，认证机制不再弹出登录认证页面，并进行流量统计，否则无法访问非放行网段。

1.2.1 认证机制的功能实体

1)用户终端设备:可以是笔记本电脑、手机等通过WiFi 接口连接MAR 的、支持Web 浏览器的智能终端。

2)数据报标记模块:根据数据报的源IP，目的IP和源PORT，目的PORT 打上不同的标记。标记结果作为数据报导向模块判断的依据。主要依靠Linux下Netfilter/iptables［14-15］的mark 模块实现。

3)数据报导向模块:根据数据报上的标记，进行数据报的放行、拦截或者重定向到认证与注销模块。主要是Netfiler/iptables 的ACCEPT、DROP 策略和NAT 机制。

4)认证与注销模块:为用户提供认证登录和认证注销服务。主要是Linux 下的PHP 脚本和MySQL数据库部分。

5)流量统计模块:统计用户的上网行为，如上网时长、上下行流量等信息。主要包括定时更新脚本和数据库部分。

1.2.2 认证机制的位置设计

对于MAR，所有的数据报都必须经过WiFi 网卡转发到虚拟网卡，进入隧道，从3G 网卡发出，或是从3G 网卡接收，出隧道，从虚拟网卡转发回WiFi 网卡。

上网行为由用户终端主动发起。因此，认证机制的认证依据应该是用户设备产生数据报的网络层的源IP、目的IP 和传输层的源PORT、目的PORT。在MAR 的3G 网卡上，数据报的形态必然为隧道数据报，已经产生隧道开销，即将发送出去。作为隧道报出口的3G 网卡的网卡名称、IP 地址和数量都是动态变化的。同时，TUN 设备是所有用户数据报的必经之地，是数据报形态变化的连接点。因此，认证机制应该针对用户设备产生的原始数据报，而非隧道数据报，其作用点主要在于WiFi 网卡和虚拟网卡设备TUN，而非3G 网卡。

TUN/TAP 设备全部使用软件实现，却能像运行于操作系统上的软件一样提供与硬件的网络设备一样完全相同的功能。所以，完全可以将TUN 设备作为下行流量的入口来看待。对应地，WiFi 网卡则是上行流量的入口。

2 认证机制的具体实现

2.1 数据报标记模块

用户数据报进入MAR，交予内核协议栈处理。首先进入Netfilter 机制的PREROUTING 链。Netfilter的Mangle 表支持用户自定义链的定义，为了方便对数据报进行统一的标识，需要预先定义一些自定义链，分别为:AM_UP_INCOMING、AM_UP_EXCEPTIONS、AM_UP_AUTHORIZED、AM_DOWN_INCOMING、AM_DOWN_EXCEPTIONS、AM_DOWN_AUTHORIZED。

通过操作iptables 规则，使移动子网通过WiFi 网卡wlan0 发往外网的包，首先跳转到PREROUTING链进行规则匹配:

在AM_UP_INCOMING 进行目的地址的区分。若数据报是去往放行网段，则跳转到AM_UP_EXCEPTIONS 链进行匹配，反之，则去往AM_UP_AUTHORIZED 链进行规则匹配。如果目的地址没有被指明是放行网段的地址，则默认是去往非放行网段。

同理，为了将下行流量进行用户自定义链的匹配，iptables 应该首先进行如下配置:

这样从外网经过虚拟网卡tun0 发往移动子网的包，就首先跳转到AM_DOWN_INCOMING 链进行规则匹配。若数据报是来自放行网段，则跳转到AM_DOWN_EXCEPTIONS 链进行匹配，反之，则去往AM_DOWN_AUTHORIZED 链进行规则匹配。

上行和下行流量都已经根据业务进行了区分，下一步使用Netfilter/iptables 的mark 模块，打上标记，进行标识。标记的意义如表1 所示。

表1 流量标记及其意义

2.2 数据报导向模块

数据报导向模块采用的是默认拦截，指定放行的策略。

对于经过PREROUTING 链被打上标记的数据报，数据报导向模块直接予以放行。没有被打上标记的部分数据报，视为首先需要进行用户的登录认证。在PREROUTING 链上添加 iptables 规则，将其DROP。但是为了实现主动弹出登录认证页面的要求，还需要指定开放DNS、HTTP 端口，其主要处理过程如图3 所示。

图3 数据报导向模块工作流程

放行DNS 数据报的目的在于便于浏览器找到URL 对应的IP 地址，否则将无法进一步触发HTTP请求。放行HTTP 请求的目的在于登录认证，弹出登录认证界面。所以需要在合适的位置将HTTP 重定向到本地认证服务器监听端口80 上［16］。因此，需要在NAT 表上部署如下的重定向规则:

若用户发起的URL 请求只有域名，即＜域名＞，获得DNS 响应和经过REDIRECT 规则之后，URL 请求变为＜认证服务器的IP 地址＞，此时将网站的缺省文件定义为认证网站的首页，就能在用户的浏览器中弹出认证网站首页。如果用户发起的URL 是＜域名+路径名+文件名＞，经过DNS 和REDIRECT 之后，URL 请求变为＜认证服务器IP 地址+路径名+文件名＞，但是在认证服务器网站上并没有这样的路径名和文件名，此时会出现HTTP 的404 NOT FOUND错误。需要将网站的404 NOT FOUND 错误定义为认证网站的首页。

2.3 认证和注销模块的实现

2.3.1 数据库的设计

用户终端设备的浏览器中弹出认证网站首页之后，就看到要求用户输入用户名和密码的输入框。通过网页的方式验证用户名和密码，必然需要数据库的支持。关于保存用户身份信息的数据表关键字段设计如表2 所示。

表2 用户身份信息数据表关键字段

认证机制还需要记录的用户行为，关于记录用户行为的数据表关键字段设计如表3 所示。

表3 用户行为信息数据表关键字段

2.3.2 认证的处理

用户在弹出的Web 页面输入用户名和密码(以及验证码)，认证服务器收到用户提交的数据之后，去数据库查询匹配。如果用户名和密码都正确，就需要放行该用户的请求。也就是，从该IP 地址产生的数据报和去往该IP 的数据报都予以放行。

用户设备的IP 地址，通过认证服务器PHP 网页脚本的$_SERVER［"REMOTE_ADDR"］获得。获得用户设备IP 地址之后，首先组装能够通过PHP 脚本执行的Linux 系统命令$command_up 和$command_down，其形式如下:

通过PHP 的shell_exec()函数执行上述2 条命令，为该IP 产生的上行、下行数据报分别打上标记0x02 和0x04。命令执行成功之后，跳转到登录成功界面，提示用户可以正常上网。

2.3.3 注销的处理

当接收到用户发起的注销请求时，同样通过PHP脚本执行Linux 系统命令，将该用户设备IP 地址对应的iptables 规则删除，这样该IP 地址产生的数据报又没有mark 标记，下次访问非放行网站时又需要进行认证。

2.4 流量统计的实现

iptables 工具的-L 选项能够用来查看IP 地址的流量情况。通过下面2 条iptables 的命令，能够分别查看地址为$2 的上行流量为$8，地址为$2 的下行流量为$9。

其中acct_input_update()函数和acct_output_update()函数的主要功能结构如图4 所示。

图4 流量统计函数主要结构

通过Linux 下的crontab 服务，定时执行上述命令，就能取出所有接入MAR 的用户终端设备的上下行流量，并将统计结果存入数据库，从而能够对每个用户终端设备进行流量统计和计费。

3 实验与分析

3.1 实验环境

图5 移动路由系统实验拓扑

网络拓扑如图5 所示。使用安装了WiFi 模块和3G 网卡模块的PC 平台充当MAR，2 块不同制式的3G 网卡能够拨号成功，顺利获取IP 地址。用户终端设备通过WiFi 接入MAR。地面上，一台具有公网IP地址的服务器作为隧道的终点，充当MER 的角色。

实验中，用户终端设备通过DHCP 获得的私网地址为192.168.20.127，CDMA 和WCDMA 制式的3G网卡拨号成功。MAR 接口配置信息和路由状态信息具体如图6 所示。

图6 MAR 网卡接口及路由状态信息

3.2 实验结果分析

如图7 所示，用户终端设备192.168.20.127 向1.1.1.1 发出Http 请求。由于192.168.20.127 地址没有经过认证，而1.1.1.1 处于非放行网段，请求所以被重定向到192.168.20.1 的80 端口上来。此时，弹出如图8 所示登录认证界面。

图7 WiFi 网卡上抓包结果

图8 认证网站首页

在登录认证界面，输入正确的用户名和密码之后，192.168.20.127 发出的请求包不再被重定向，能够顺利通过移动路由系统发出并获得响应。

图9 上行流量查询结果

执行流量查询语句后，得到如图9 所示结果。图中清晰显示192.168.20.127 地址的上行流量为152831 bytes，并且被成功打上标记0x2。

4 结束语

通过对移动路由系统认证机制的研究和实现，完善了移动路由系统的功能。测试结果表明，在移动路由系统特殊的架构情况下，认证机制能够支持移动路由系统，正常地完成登录、注销和流量统计功能，具有良好的稳定性和可靠性，适合大规模网络的部署。此外，要达到使用一个用户帐户在多个MAR 上进行登录认证，还需要将保存用户身份和行为信息的数据库集中部署在MER，或者同步MAR 和MER 上的数据库。这项功能，还需要进一步研究与开发。

［1］朱廷武，常德远.高速铁路宽带无线接入的几种技术方案分析［J］.铁道通信信号，2008，44(3):40-43.

［2］Fokum D T，Frost V S.A survey on methods for broadband Internet access on trains［J］.IEEE Communications Surveys ＆ Tutorials，2010，12(2):171-185.

［3］Lannoo B，Colle D，Pickavet M，et al.Radio-over-fiberbased solution to provide broadband Internet access to train passengers［J］.IEEE Communications Magazine，2007，45(2):56-62.

［4］Pareit D，Gheysens N，Van Leeuwen T，et al.QoS-enabled Internet-on-train network architecture:Inter-working by MMP-SCTP versus MIP［C］// Proceedings of the 7th International Conference on Telecommunications.2007:1-6.

［5］Ishizu K，Kuroda M，Harada H.Bullet-train network architecture for broadband and real-time access［C］// Proceedings of the 12th IEEE Symposium on Computers and Communications.2007:241-248.

［6］宫兴琦.高速移动环境下连接及拥塞控制的研究与实现［D］.北京:北京交通大学，2014.

［7］吴楠.高速移动互联网中多形态并行隧道技术的设计与实现［D］.北京:北京交通大学，2014.

［8］龙湘君，邵栋，荣国平.基于TUN/TAP 与UDP 打洞技术的虚拟局域网［J］.计算机应用与软件，2011，28(7):224-227.

［9］Devarapalli V，Wakikawa R，Petrescu A，et al.RFC3963，Network Mobility (NEMO)Basic Support Protocol［S］.

［10］陈华兵.基于Linux 的IPv4_v6 虚拟隧道路由器设计［D］.太原:太原科技大学，2009.

［11］刘志权.基于WEB 方式的网络接入认证系统的设计与实现［D］.广州:华南理工大学，2011.

［12］朱建勋.基于WEB 和RADIUS 的无线局域网接入认证系统［D］.成都:西南交通大学，2006.

［13］马燕，范植华.Web/Portal 认证技术研究［J］.微电子学与计算机，2014，21(8):76-79.

［14］Welte H.The Netfilter framework in Linux 2.4［C］// Proceedings of Linux Kongress.2000.

［15］宋敬彬，孙海滨.Linux 网络编程［M］.北京:清华大学出版社，2010:486-489.

［16］张晓军，吕洁，张蓓.HTTP 重定向在网关认证中的应用［J］.大连理工大学学报，2005，45(S1):48-51.