一种基于反向连接和应用层隧道的企业内网访问方法与流程

文档序号:15567534发布日期:2018-09-29 03:41阅读:249来源:国知局

本发明涉及通信技术领域,具体涉及一种基于反向连接和应用层隧道的企业内网访问方法。



背景技术:

企业内网资源的访问需求由来已久,由于内外网分别使用不同的ip地址,在网络边界由nat完成转换,对外表现为一个ip地址,导致外网终端无法直接访问内网主机。

内网访问需关注如下问题:

1)保证安全性,包括身份认证、传输安全以及权限控制等;

2)使用便捷,安装简洁,尽量减小对企业网络环境的改动;

3)操作简洁,隐藏细节,暴露给用户的配置尽量少,降低使用难度;

4)易于扩展,无论是业务扩展还是方法和系统本身的升级都应具备对现有业务影响较小,向下兼容;

5)适应企业复杂的网络环境,各个企业内网安全等级不同,网络建设也参差不齐,访问方法和系统需兼容这些差异。



技术实现要素:

本发明提供了一种基于反向连接和应用层隧道的企业内网访问方法,实现外网终端安全、高效地访问企业内部网络。

一种基于反向连接和应用层隧道的企业内网访问方法,实现所述企业内网访问方法的系统根据通信角色划分为四个层级,分别为:用户使用的外网终端、公网部署的中继服务器、企业内网部署的网关服务器、以及企业内网部署的应用服务器;

外网终端与中继服务器之间采用消息发送端向接收端发送请求的正向方式建立连接;

中继服务器与网关服务器之间,以及网关服务器与应用服务器之间均采用消息接收端向发送端发送请求的反向方式建立连接;

各层级节点之间采用应用层协议作为数据传输隧道;

访问企业内网时,用户通过外网终端发送请求至中继服务器,中继服务器校验后将信息发送至相应的网关服务器,网关服务器将信息发送至目标应用服务器,目标应用服务器执行请求,请求结果依次通过网关服务器、中继服务器返回至外网终端。

本发明中各层级节点之间通过反向方式建立连接,即通过企业内网节点发起连接请求,这样设计的好处在于:

1)增加便捷性,内网主动向外网发起请求,无需开放新端口,新添加服务不需要再做调整,可以自动发现;

2)提高安全性,外网发起请求无法穿透内网,可有效屏蔽外网发起的攻击,同时,配置防火墙策略,使网关服务器只能通过特定端口访问指定ip和端口,即限制网关只能访问服务端主机,屏蔽由内网发起的木马攻击,进一步增加安全系数。

本发明采用应用层协议作为数据传输隧道,例如,websocket,这样带来的好处如下:

1)应用层协议可以轻松穿越网关服务器(即nat),屏蔽下层协议细节,稳定可靠,实现也相对简单;

2)可以代理基于tcp的所有上层协议,包括http、ssl等,屏蔽上层协议细节,基本上可以满足大部分网络请求;

3)仅使用一条数据传输隧道接入内网,可以对内网内所有提供访问权限的主机进行访问,减小了内外网接触的途径,提高网络边界的安全性,与frp相比无需为每个端口额外建立映射关系,扩展性更好、更加简洁方便。

在进行数据传输时,定义用于通信的请求消息和响应消息,以及表示节点的节点信息。请求消息包含版本、消息标识、超时时间、路由信息、消息类型、分片大小以及消息长度,响应消息包含版本信息、响应状态、响应层级、路由信息以及消息长度。

通过路由信息可以将请求消息由任一指定节点执行,同时可以实现请求消息的批量执行。

本发明提供的企业内网访问方法安全便捷,可以进行文件传输、网络请求代理、命令执行等多种操作,可以批量执行操作,减少机械操作,安装配置以及维护扩展更加便捷,尤其在面向多子网的访问和资源管理更能体现出强大优势,可结合文件传输,批量操作等完成服务的远程部署和管理,通过网络代理实现内网服务的访问。

作为优选,通过反向方式建立连接的过程包括:

应用服务器向网关服务器发送连接请求,连接成功后,连接成功后,应用服务器将本机节点信息上传至网关服务器;

在网关服务器配置中继服务器的连接信息,网关服务器向中继服务器发送连接请求,连接成功后,网关服务器将本机节点信息上传至中继服务器;

中继服务器向已建立连接关系的外网终端自动推送最新节点信息。

作为优选,所述外网终端、网关服务器、以及应用服务器均具有至少一个节点,各外网终端节点和网关服务器节点与同一中继服务器建立数据传输隧道,应用服务器节点与对应的网关服务器节点之间建立数据传输隧道。

为了提高安全性,采用以下策略:

(1)网关服务器和中继服务器之间,以及外网终端和中继服务器之间均采用ssl双向认证鉴别身份。

(2)利用ssl加密数据传输隧道。

(3)对外网终端节点和网关服务器节点进行用户等级划分,用户等级包括超级管理员、管理员和普通用户,超级管理员对管理员和普通用户进行访问权限控制,管理员对普通用户进行访问权限控制。

(4)负责数据最终写出执行的执行节点通过配置黑白名单设置资源访问权限,所述黑白名单由执行节点自身配置且禁止通过访问操作修改。

(5)对外网终端各节点进行跨域访问权限控制,阻止局域网内其他节点利用受信任外网终端节点发送伪造请求。

将不同种类请求消息路由至目标节点执行,针对某一请求消息,以单播、组播或广播的形式发送到目标网关服务器节点和目标应用服务器节点。

针对请求消息传输过程中的异常情况做如下处理:

a)建立异常链,针对不同异常类型返回相应的异常码;

b)将请求消息数据分片发送,接收端接收到数据并返回确认信息后进行下一次发送。

本发明与现有技术相比,有益效果如下:

1)采用应用层隧道协议,应用层隧道对应osi七层参考模型应用层,可以轻松穿越nat,屏蔽下层协议细节,稳定可靠,实现相对简单。

2)数据传输隧道通过反向连接建立,即内网主机主动发起连接请求,无需开放新端口,无需对内网环境进行改动,更加安全简洁。

3)针对网络访问功能,可以代理基于tcp的上层协议,包括http、ssl等,屏蔽上层协议细节,基本上可以满足大部分网络请求。

4)仅使用一条隧道接入内网,可以对内网内所有提供访问权限的主机进行访问,减小了内外网的接触途径,增加网络边界的安全性,无需为每个端口额外建立映射关系,扩展性更好、更加简洁方便。

附图说明

图1为本发明基于反向连接和应用层隧道的企业内网访问方法的原理图;

图2为本发明基于反向连接和应用层隧道的企业内网访问方法的网络拓扑及层级划分图;

图3为本发明基于反向连接和应用层隧道的企业内网访问方法的节点注册与发现流程图;

图4为本发明基于反向连接和应用层隧道的企业内网访问方法的通讯流程示意图;

图5为本发明基于反向连接和应用层隧道的企业内网访问方法中超时机制的流程图;

图6为本发明基于反向连接和应用层隧道的企业内网访问方法的组件架构图;

图7为本发明基于反向连接和应用层隧道的企业内网访问方法的节点注册与发现时序图;

图8为本发明基于反向连接和应用层隧道的企业内网访问方法的命令远程执行时序图;

图9为本发明基于反向连接和应用层隧道的企业内网访问方法的网络请求代理时序图;

图10为本发明基于反向连接和应用层隧道的企业内网访问方法的文件操作时序图;

图11为本发明基于反向连接和应用层隧道的企业内网访问方法的文件上传时序图;

图12为本发明基于反向连接和应用层隧道的企业内网访问方法的sender文件下载时序图;

图13为本发明基于反向连接和应用层隧道的企业内网访问方法的recipient文件下载时序图。

具体实施方式

下面结合附图,对本发明基于反向连接和应用层隧道的企业内网访问方法做详细描述。

如图1所示,本发明基于反向连接和应用层隧道的企业内网访问方法的核心思想为:为本地请求添加路由标签,以应用层协议作为数据传输隧道,将本地请求代理到远程目标主机进行执行,再将执行结果封装,通过数据传输隧道返回到本地。用户察觉不到中间的一系列转发操作,与本地操作体验一致。

如图2所示,根据网络节点关系设计网络拓扑并划分角色层级,分别为:

sender(用户使用的外网终端),供用户直接操作使用;

postoffice(公网部署的中继服务器),负责消息路由、验证以及节点信息汇总等;

postman(企业内网部署的网关服务器),部署在企业内部,须同时可以访问内网和外网;

recipient(企业内网部署的应用服务器),部署在企业内部,用于运行服务。

各层级的各个节点通过应用层隧道连接,构建起一个树状的节点网络。

节点在连接上级节点的时候完成自动注册。节点启动,尝试建立隧道连接,通过认证之后,成功建立隧道连接,这时会将节点信息自动上传到上级节点,如图3所示,各节点建立连接的具体过程如下:

1)建立postoffice(即中继服务器);

2)postman(即网关服务器)配置连接信息,启动节点,postman向postoffice发送连接请求,连接成功后,将postman本机节点信息上传到postoffice;

3)recipient配置连接信息,启动节点,recipient向postman发送连接请求,连接成功后,将recipient本机节点信息上传到postman;

4)postman监测到节点信息发生变动时,将最新节点信息上传到postoffice,所有节点的最新状态最终汇集到postoffice,用户端登录到postoffice即可获取节点列表信息。

如图4所示,需要访问企业内网时,sender选择所要访问节点(即所要访问的应用服务器节点),根据需求配置网络端口映射关系;应用客户端向本地代理端口发送请求,代理将请求封装,发送到postoffice,postoffice通过路由信息分发到相应postman,再到相应的目标recipient,目标主机执行请求,并封装响应消息按原路径返回到sender,与请求匹配,完成通讯过程。

为实现上述通讯过程,定义用于传输及节点标识的消息,并约定以请求传递方向为请求消息,以响应传递方向为响应消息。通过指定字段不同值来实现对节点访问以及功能的覆盖,指定内容如下:

1)指定所要执行的功能,如shell命令远程执行、代理网络请求以及处理文件等;

2)指定执行节点层级,比如,查询节点列表即可指定postoffice为执行节点;

3)执行节点的范围,即同一层级有哪些节点需要执行请求。

整个传输过访问程中,各个环节可能出现的异常情况做如下处理:

1)通过建立完整的异常链,针对不同的异常类型返回相应的异常码。

如图5所示,不同于两个节点之间的异常处理与恢复,本发明通过确认机制实现,具体过程如下:首先将消息的msgid存储在一个本地的延迟队列中,然后发送消息,当消息到达下级节点之后,下级节点返回一个ack消息给当前节点,并删除当前节点关于该消息的超时设置;若超时未返回,不进行重试,直接触发超时事件,封装异常消息返回;

2)通过结合数据分片发送与确认方法和系统,实现流量控制与整形。通过设定消息头字段指定分块大小,当数据大于分块阈值,将拆分发送,接收端收到数据并返回确认信息进行下一次发送。

通过数据传输加密、身份认证、节点访问权限管理、网络边界安全策略以及执行节点审查的方式确保通信过程的安全,采用异常处理与恢复以及流量整形的方式确保通信过程稳定可靠。

整个传输过程中,对各个环节存在的安全隐患做以下处理:

1)通过用户端的跨域访问控制防止利用受信任的用户发送伪造请求;

为了防止源头上的入侵,比如针对web的csrf(cross-siterequestforgery,跨站请求伪造),伪装来自受信任用户的请求来利用受信任的网站。同样,攻击者也可能利用受信任的sender主机作为跳板进行攻击,伪造sender请求。因此对sender主机进行必要的权限控制和验证,代理端口仅允许本机访问,禁止局域网内其他机器访问。从源头上过滤利用本机做跳板发起的攻击。

2)弱化端对端的身份认证,转而变为网关服务器和中继服务器之间的ssl双向认证鉴别接入用户身份,以及外网终端和中继服务器之间的ssl双向认证登录认证,使用户无需维护大量的认证信息;

3)通过ssl加密传输隧道保证数据安全;

4)执行节点通过配置黑白名单设置资源访问权限,配置文件无法通过访问操作修改,由节点按需自行配置;

执行节点作为消息传输的最后一道关卡,负责数据最终的写出、执行,需要对写出的数据进行必要审查。sender通过postoffice验证,访问到接入postman的内网目标主机,默认情况下,只具备当前主机资源的访问权限,这样可以有效控制对局域网内其他主机的影响。当然可以根据需求进行进一步的调整,比如需要访问未接入postman的内网主机资源,可以添加相应权限;如果禁止某些指令执行,就需要必须对一些资源权限加以控制,只暴露必要的资源,保护内网网络环境安全。

5)对用户划分等级,普通用户、管理员以及超级管理员,超级管理员具有最高权限,并负责普通用户和管理员的权限分配;管理员负责普通用户的权限分配,对用户实现节点级别的访问控制。

如图6所示,用户使用的外网终端、公网部署的中继服务器、企业内网部署的网关服务器、以及企业内网部署的应用服务器的各节点分别由若干功能模块组成,每个功能模块实现对应的智能,以提高软件的复用性和可维护性。

图6中,各功能模块的作用如下:

certificate,用于身份认证以及建立安全的传输隧道。

nodeinfo,用于收集节点信息,部署于postman和recipient。

nodelist,节点注册中心,用于合并存储下级节点的相关信息,部署于postman和postoffice。

broker,实现消息的接收、暂储和分发,部署于postoffice和postman。

excutor,负责消息的最终执行并返回响应结果,具体包括消息的审查、执行,以及响应的封装。部署于postoffice、postman和recipient。excutor中包含三种模式的实现组件,分别为commend-excutor、file-excutor以及proxy-excutor。

proxy,透传模式组件,用于接收网络请求并封装成请求消息,解析响应消息,部署于sender。view通过sender-service提供接口配置代理端口,建立起与远程目标服务(即企业内网部署的应用服务器)的端口映射关系,配置信息包括本地端口、远程ip、远程端口等。

file,文件处理的相关组件,用于封装文件操作请求、解析响应,以及上传下载等传输操作,部署于sender。

command,请求-响应的相关组件,用于封装命令请求以及解析响应,部署于sender;

service,访问接口,在不同的角色中有更细致的划分。sender-service用来处理view和proxy的交互逻辑,提供restful风格接口供view调用。

postoffice/postman-service,用于给节点存取数据的提供接口,供excutor调用。

client,指应用的客户端,部署于sender端,与server相对应。

server,指应用的服务端,可以在postoffice、postman、recipient部署。与sender的client相对应,用于处理client请求并返回响应。

view,提供给用户的交互视图,提供配置代理、执行命令、操作文件以及查看主机状态等操作的可视化界面。

选取websocket作为传输隧道,利用websocket的事件通知系统传递消息。

根据功能需求,实现节点注册及发现、命令远程执行、网络请求代理以及文件处理等通信过程,各通信过程的具体过程详述如下。

如图7所示,节点注册以及发现的具体过程如下:

1.首先保证postoffice节点正常运行。

2.postman配置postoffice相关连接信息,包括postoffice的地址信息以及必要的身份认证信息,postman启动后,通过websocket尝试与postoffice建立连接,成功建立连接时,触发connect事件,将postman本机节点信息上传到postoffice。

3.同样当recipient通过websocket与上级postman节点建立连接时,触发connect事件,将recipient本机节点信息上传至上级postman节点。

4.postman收到节点信息有更新的通知,将最新的节点信息通过update-node事件更新到postoffice中,完成节点的注册过程。

5.sender启动后通过验证连接到postoffice,监听node-info事件,postoffice节点信息列表更新会主动推送给sender,完成节点的发现过程。

如图8所示,命令远程执行的具体消息传输过程如下:

1.sender首先获取节点信息,选择要访问的节点;

2.发起请求,sender随机生成msgid作为消息唯一标识,连同其它配置信息一并封装在请求消息头中,内容封装在请求消息体中;

3.sender通过sender-request事件将请求消息发送到postoffice;

4.postoffice获取到消息,根据请求消息头中postmanid信息,通过postman-request事件将请求消息发送到相应postman;

5.postman获取到消息,并根据消息头信息recipientid,通过recipient-request事件将请求消息发送到相应recipient;

6.recipient获取到请求消息,执行请求,并将结果封装成响应消息,通过recipient-response事件将响应消息返回到相应postman;

7.postman获取到响应消息,通过postman-response事件将响应消息返回到相应postoffice;

8.postoffice获取到响应消息,根据响应头信息senderid,通过sender-response事件将响应消息返回到相应sender;

9.sender获取到响应消息,通过msgid与请求消息进行匹配,匹配成功,拆解得到最终的响应信息,并进行显示。

如图9所示,网络请求代理的具体过程如下:

1.首先获取节点信息,选择要访问的节点,配置本地端口到远程server端口的映射关系;

2.client向proxy发起请求,与proxy建立tcp连接后,请求的码流写入到端口,码流为16进制字节流,作为消息体进行封装,同时将建立的通道id作为channelid、proxy的相关配置信息映射到消息头中;

3.sender通过sender-request事件将请求消息发送到postoffice;

4.postoffice获取到消息,根据请求消息头中postmanid信息,通过postman-request事件将请求消息发送到相应postman;

5.postman获取到消息,并根据消息头信息recipientid,通过recipient-request事件将请求消息发送到相应recipient;

6.recipient获取到请求消息,通过消息头中的映射关系指定写入ip地址和端口号,将消息体中内容发送到目标端口中,并将响应封装成响应消息,通过recipient-response事件将响应消息返回到相应postman;

7.postman获取到响应消息,通过postman-response事件将响应消息返回到相应postoffice;

8.postoffice获取到响应消息,根据响应头信息senderid,通过sender-response事件将响应消息返回到相应sender;

9.sender获取到响应消息,通过channelid与请求进行匹配,匹配成功拆解得到最终的响应信息,最终写回到client。

如图10所示,文件操作的具体过程与命令远程执行类似,只是采用了不同的事件通知。

如图11所示,sender文件上传的具体过程如下:

1.准备阶段,封装获取到目录结构的请求消息,通过file-op-req-sd事件查询postoffice目录结果,并封装响应通过file-op-res-sd返回给sender。

2.握手协商阶段,选择待上传的本地文件,sender将文件大小、格式、目标存储路径、上传目标目录等封装成请求消息通过file-upload-sh发送。服务端对存储空间、文件格式要求等进行验证反馈,若已存在文件或者存储空间不足则封装响应消息进行异常提示,否则开始创建文件,并通过file-upload-sh-ack返回响应消息,至此握手协商阶段结束。

3.文件传输阶段,sender打开文件,读取二进制文件内容,封装请求消息通过file-upload事件发送,postoffice接收到消息并进行存储,并通过file-upload-ack返回接收结果与进度,再进行下一次传输,对没有接收到ack消息的进行超时重传。

4.文件传输结束,sender通过file-upload-fin事件,通知postoffice文件上传完毕;postoffice收到通知,关闭文件,并返回确认消息;sender收到确认消息,关闭本地文件。

如图12所示,sender文件下载的具体过程如下:

1.准备阶段,sender首先通过file-op-req-sd查询文件目录结构,并通过file-op-res-sd事件将结果返回。

2.握手协商阶段,sender选中下载文件,通过file-dowmload-sh事件发送下载请求,postoffice接到消息进行验证,若出现异常,封装异常响应返回;否则加载文件,并通过file-download-sh-ack通知sender下载就绪。sender接收到ack消息,在本地创建对应的文件,通过file-download-sh-fin事件通知postoffice下载可以开始,至此握手协商阶段完成。

3.文件下载阶段,postoffice读取文件内容,通过file-download事件,传输到sender,sender将信息写入文件并保存,并通过file-download-ack事件通知postoffice信息已经保存,进行下一次传输,如此往复。

4.文件内容全部传输完毕,postoffice通过file-download-fin事件通知sender传输已结束;sender收到消息,关闭文件,并通过file-download-fin-ack事件通知postoffice文件下载已完成,postoffice接收到信息,关闭文件。

如图13所示,recipient下载的具体过程如下:

1.准备阶段,sender通过文件操作方式获取postoffice以及下载目标主机的目录结构。

2.握手协商阶段,指定待下载文件以及目标路径等信息,封装成下载请求,通过file-download-sd事件发送下载请求;消息首先经由postoffice,进行合法校验,查看文件是否存在;若存在异常则封装异常响应返回,通过验证则继续向下传递,通过file-dowmload-sh-pm将请求传递到相应的postman;postman获取到信息根据recipientid,继续向下传递,通过file-download-sh-rc事件将下载请求发送到相应的recipient。

recipient获取到消息,对下载文件信息进行校验,包括存储空间、文件路径以及文件格式;未通过验证封装异常响应消息通过file-download-sh-ack-*事件组返回;通过验证则创建文件,准备接收文件信息,通过file-download-sh-ack-*事件组通知postoffice下载可以开始;

3.文件传输阶段,文件分片通过file-download-*事件组进行传输,消息保存到目标文件,并通过file-download-ack-*事件组进行送达确认以及进度反馈,postoffice接收到反馈后,通过file-download-ack-sd向sender反馈进度,同时进行下一次发送;若遇到异常情况,或者超时未收到响应,则进行重发,重发五次仍然失败,则反馈给sender下载失败;

4.文件传输完毕,通过file-download-fin事件组通知传输成功,接收端收到通知,关闭文件并通过file-download-fin-ack事件进行反馈;postoffice接收到反馈后关闭文件,并通过file-download-fin-ack-sd事件通知sender文件下载成功。

根据上述说明书的揭示和教导,本发明所属领域的技术人员还可以对上述实施方式进行适当的变更和修改。因此,本发明并不局限于上面揭示和描述的具体实施方式,对本发明的一些修改和变更也应当落入本发明的权利要求的保护范围内。此外,尽管本说明书中使用了一些特定的术语,但这些术语只是为了方便说明,并不对本发明构成任何限制。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1