CN112673597A - 控制装置、控制方法及程序 - Google Patents

Abstract

一种控制装置，该控制装置与多个网络连接，将从用户终端接收到的分组分配给该多个网络中的任意网络，所述控制装置具有：DNS控制部，其接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及路由部，其接收分组，并根据该分组的目的地地址决定该分组的发送目的地，并向所决定的发送目的地发送该分组。

Description

控制装置、控制方法及程序

技术领域

本发明涉及一种使从用户终端向网络上的服务器等的接入高速化的技术。

背景技术

近年来，Software-as-a-Service(SaaS：软件即服务)的利用得到了爆发性地普及。另一方面，在SaaS中，由于最初设想LAN环境下的利用而设计的应用(application)通过云端(Cloud)上来提供，因此其性能受到网络的延迟或质量所左右，尤其是，企业越是全球扩张，网络的延迟或质量的影响越大。

当前，作为封闭网络(閉域網)的企业网络未面向SaaS利用来设计。例如，在很多企业网络中，面向互联网的连接点受限，因而导致经由互联网的SaaS连接成了绕道而行。

此外，在作为企业网络内的通信的站点间的通信与面向SaaS的通信重叠于同一线路的情况下，在站点间等中，线路的带域受到压力。预计2020年左右一半以上的企业存在与网络相关的SaaS利用上的问题。

以北美的主要金融/分销/零售等企业的IT责任人为中心启动的ONUG(OpenNetworking User Group：开放网络用户组)这样的团体提倡了SD-WAN(Software-definedWAN：软件定义的广域网)的技术。为了实现当前的WAN成本的削减、运行的简化、质量的提高等，很多的企业开始导入了现售的SD-WAN解决方案(SD-WAN solution)。在SD-WAN的利用中，被视为最有前景的用例(use case)被称作以SaaS接入为中心的本地疏导(LocalBreakout)。

所谓Local Breakout是指如下机制：在分支站点中，在接入SaaS时，使用深度分组检测引擎(Deep Packet Inspection(DPI)engine)来识别特定的数据流，并对路由进行控制，以使得识别出的对应的数据流从分支站点直接流向互联网。

通过利用SD-WAN客户端设备(SD-WAN Customer Premises Equipment(CPE))，实现Local Breakout，并使朝向SaaS的业务直接从分支站点流向互联网，由此期待能解决上述各种各样的问题。

现有技术文献

专利文献

专利文献1：日本特许5832970号

发明内容

发明要解决的问题

但是，由于以往的使用了SD-WAN技术的SaaS接入方法大多未被最优化为实际的利用场景，因此存在从用户终端向SaaS服务器的接入产生延迟等的问题。

本发明是鉴于上述情况而完成的，其目的在于提供一种进行经由封闭网络的通信的用户终端能够高速地接入互联网上的预定服务器的技术。

用于解决问题的手段

根据所公开的技术，提供一种控制装置，该控制装置与多个网络连接，并将从用户终端接收到的分组分配给该多个网络中的任意网络，所述控制装置具有：DNS控制部，其接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及路由部，其接收分组，根据该分组的目的地地址决定该分组的发送目的地，并向所决定的发送目的地发送该分组。

发明效果

根据所公开的技术，提供一种进行经由封闭网络的通信的用户终端能够高速地接入互联网上的预定服务器的技术。

附图说明

图1是本发明的实施方式中的系统的整体结构图。

图2是第1实施方式中的接入装置100的功能结构图。

图3是接入装置100的硬件结构图。

图4是示出应用管理DB中存储的信息的示例的图。

图5是示出应用缓存(application cache)中存储的信息的示例的图。

图6是示出DNS分配策略(dispatch policy)管理DB中存储的信息的示例的图。

图7是示出IP路由策略(IP routing policy)管理DB和应用路由策略(application routing policy)管理DB中存储的信息的示例的图。

图8是第1实施方式中的管理流(management flow)控制的流程图。

图9是第1实施方式中的数据流控制的流程图。

图10是改写DNS的查询的目的地的情况下的DNS控制部的结构图。

图11是示出改写DNS的查询的目的地的情况下的应用路由策略管理DB中存储的信息的示例的图。

图12是改写DNS的查询的目的地的情况下的数据流控制的流程图。

图13是使用DNS的查询结果随时更新应用缓存的情况下的流程图。

图14是示出使用DNS的查询结果随时更新应用缓存的情况下的应用缓存的图。

图15是第2实施方式中的接入装置100的功能结构图。

图16是示出IP路由策略管理DB和应用路由策略管理DB中存储的信息的示例的图。

图17是示出代理分配策略(proxy dispatch policy)管理DB中存储的信息的示例的图。

图18是第2实施方式中的管理流控制的流程图。

图19是第2实施方式中的数据流控制的流程图。

图20是示出利用应用缓存的情况下的代理分配策略管理DB中存储的信息的示例的图。

图21是用于说明应用管理DB的定期更新的图。

图22是应用管理DB的定期更新的流程图。

图23是示出应用缓存中存储的信息的示例的图。

具体实施方式

以下，参照附图对本发明的实施方式进行说明。以下所说明的实施方式仅是一例，应用本发明的实施方式不限于以下的实施方式。

(关于课题)

首先，对利用实施方式中说明的接入装置100解决的课题进行说明。另外，以下的3个课题为示例，由接入装置100解决的课题不限于下述的课题。

(1)关于DNS的课题

为了对任意地域的用户均能以最大限的性能提供服务，多数的SaaS采用了GeoDNS技术。通过利用GeoDNS，能够根据向DNS服务器查询出的客户的物理位置而应答最近的SaaS的服务器的IP地址。另外，DNS是域名系统(Domain Name System)的简称。

但是，企业用户大多为在数据中心等主要站点设置内部DNS服务器并使针对外部DNS服务器的查询从该主要站点疏导(breakout)的设计。因此，与SaaS接入相关的DNS业务从数据中心等的主要站点出来而到互联网，与此相对，数据流从分支站点(例：设置于与数据中心不同的国家的站点)出来而到互联网，两者的出口不一致。其结果，好不容易使与SaaS相关的特定的数据流在分支站点疏导(breakout)，从主要站点进行了DNS查询的结果却是接入到离主要站点最近的SaaS服务器，存在得不到所期待的延迟改善效果的情况。

(2)关于代理(proxy)的课题

在用户终端与SaaS服务器之间设置代理(也可以称为代理装置、代理服务器等)，经由代理进行通信的情况较多。但是，根据SaaS的种类，在利用时有时会大量消耗TCP会话，因此由于由会话增加导致的代理的处理限制，有时不能舒适地利用SaaS。

因此，要求对现有的代理进行旁路(bypass)以减轻处理负载。在以往的方式中，针对SaaS业务，为了使代理旁路，与SD-WAN装置分开地，在现有的代理中必须定期地检测朝向SaaS的通信目的地，并且必须将该结果反映在代理自动设定(PAC)文件中并将该PAC文件分发给所有的终端用户。因此，存在运行负载增加的情况。

(3)分组识别延迟的课题

此外，在以往的SD-WAN装置的DPI引擎中，采用对HTTP/HTTPs的握手(handshake)的交互进行解析，并使用在其中提取出的SaaS的域名(Domain name)来判别接入目的地的SaaS的方法。但是，在该方法中，由于难以在最初到达的分组(First Packet：第一分组)中识别SaaS，因此存在对应的SaaS的最初的流程从主要站点出来的情况。

以下，作为本发明的实施方式，对解决上述课题的技术进行详细说明。另外，在本实施方式中，接入装置100与封闭网络20和互联网30连接，但该方式仅为一例。也可以在封闭网络20以及互联网30以外的2个网络之间进行同样的控制。此外，接入装置100也可以与3个以上的多个网络连接，将分组分配给该多个网络中的任意网络。

(系统结构)

图1示出本发明的实施方式中的系统的整体结构。如图1所示，具有与用户终端10、封闭网络20以及互联网30连接的接入装置100。接入装置100是接受来自用户终端10的接入并使用户终端10与封闭网络20上的装置或者互联网30上的装置连接而进行通信的装置。另外，也可以将接入装置100称为SaaS接入高速化装置。此外，接入装置100由于是实施针对数据流的各种各样的控制的装置，因此可以将其称为控制装置。

封闭网络20例如是连接企业的多个站点的企业内的网络。接入装置100例如是按照全球企业的企业网络中的每个分支站点而设置的装置。

下面，对接入装置100的结构和动作进行详细说明。以下，将接入装置100的基本的结构作为第1实施方式进行说明，将对第1实施方式的接入装置100追加了代理控制部的结构作为第2实施方式进行说明。

(第1实施方式)

＜装置结构＞

图2示出第1实施方式中的接入装置100的功能结构图。如图2所示，接入装置100具有指令接收部110、DNS控制部120、公共应用管理部130、SD-WAN路由部140、多个IF(interface：接口)。

作为多个IF的示例，图2中示出了用于与封闭网络连接的封闭网络连接IF150、用于与互联网连接的互联网连接IF160、用于与LAN连接的LAN-IF170。如图所示，封闭网络连接IF150以及互联网连接IF160被分配了IP地址。

如图所示，封闭网络连接IF150与内部DNS服务器210连接，互联网连接IF160与外部DNS服务器310和SaaS服务器320连接，LAN-IF170与用户终端10连接。此外，各服务器被分配有如图所示的IP地址。对于本实施方式中的SaaS服务器320，IP地址是非固定的，IP地址随时改变。

另外，IF不限于物理端口，也可以是终止IPsec等的隧道(tunnel)的逻辑端口。此外，在本实施方式中，作为示例，设各接入装置中具有公共应用管理部130，但是代替于此，也可以设置为在接入装置100的外部具有公共应用管理部130，多个接入装置能够共同地利用。关于接入装置100的各部分的详细介绍将在后面论述。

接入装置100可以是由多个计算机(也包括通信装置等)构成的系统，也可以是由1个计算机实现的装置。此外，该计算机可以是物理机器，也可以是虚拟机器。此外，接入装置100可以通过执行本实施方式中所说明的处理的专用硬件电路来实现。

在接入装置100通过计算机来实现的情况下，接入装置100能够通过使用内置于计算机的CPU或内存等的硬件资源来执行与由接入装置100实施的处理对应的程序而实现。上述程序能够记录在计算机可读取的记录介质(便携式内存等)中，并保存或者分发。此外，也可以经由互联网或电子邮件等通过网络提供上述程序。

图3是示出上述计算机的硬件结构例的图。图3的计算机具有分别通过总线B相互连接的驱动装置1000、辅助存储装置1002、内存装置1003、CPU1004、接口装置1005、显示装置1006以及输入装置1007等。

实现该计算机中的处理的程序例如通过CD-ROM或者内存卡等的记录介质1001来提供。当存储有程序的记录介质1001被设置在驱动装置1000中时，程序从记录介质1001经由驱动装置1000被安装在辅助存储装置1002中。但是，程序的安装不一定必须从记录介质1001来进行，也可以经由网络从其它的计算机下载。辅助存储装置1002存储被安装的程序，并且存储所需的文件或数据等。

在存在程序的起动指示的情况下，内存装置1003从辅助存储装置1002读出程序并存储。CPU1004按照内存装置1003中存储的程序，实现与接入装置100有关的功能。接口装置1005被用作用于与网络连接的接口，并作为经由网络的输入单元以及输出单元发挥功能。显示装置1006显示基于程序的GUI(Graphical User Interface：图形用户界面)等。输入装置157由键盘以及鼠标、按键或者触摸面板等构成，用于输入各种各样的操作指示。

以下，对接入装置100的各部件的结构、动作进行详细说明。

＜公共应用管理部130＞

公共应用管理部130具有应用管理DB和应用缓存(可以称为应用表(applicationtable))。图4示出应用管理DB中存储的信息的示例，图5示出应用缓存中存储的信息的示例。

应用管理DB是管理各种各样的SaaS的通信模式的DB，在图4所示的示例中，作为应用管理DB的列(column)，有应用名、FQDN、目的地IP地址等。图4是示例，应用管理DB的结构不限于图4所示的情况。例如，除了图4的应用名、FQDN、目的地IP地址以外，还可以包含目的地端口编号。此外，也可以包含确定SaaS应用的其它参数。

图4所示的信息示出对于应用名为“Example”的SaaS，存在目的地的FQDN为Example.com或Example365.Com、或者目的地IP地址为B.B.B.B/B这3种通信模式。

应用缓存记录当前时刻接入装置100所掌握的SaaS的目的地服务器的IP地址。如图5所示，作为应用缓存的列，例如，有应用名和目的地IP地址，但不限于此。此外，图5(a)示出应用名为“Example”的目的地IP地址被识别为B.B.B.B的情况。图5(b)示出例如在应用名为“Example”的目的地IP地址被识别为B.B.B.B之后，检测到A.A.A.A作为“Example”的目的地IP地址的情况。

＜DNS控制部120＞

如图2所示，DNS控制部120具有DNS分配部121以及DNS分配策略管理部122。

DNS分配部121按照DNS分配策略管理部122所管理的DNS分配策略，分配DNS查询(也可以称为DNS查询分组)。即，按照该DNS分配策略，决定DNS查询的发送目的地，并朝向该发送目的地发送DNS查询。

DNS分配策略管理部122具有图6所示的DNS分配策略管理DB。DNS分配策略管理DB是针对DNS查询存储定义要执行的动作的信息的DB。在图6所示的示例中，定义如下所述的动作：针对包含有Example.com或者Example365.com的FQDN的DNS查询，IP地址被转发(forward)至Y.Y.Y.Y的外部DNS服务器310，关于其它的查询，作为默认(Default)而被转发(forward)至内部DNS服务器210。

＜SD-WAN路由部140＞

如图2所示，SD-WAN路由部140具有应用检测部141、路由控制部142、路由策略管理部143。

应用检测部141对由SD-WAN路由部140路由的数据流(更详细来说，构成数据流的分组)进行调查，检测该数据流的目的地或者发送源的应用。路由控制部142按照路由策略管理部143中管理的路由策略执行分组的路由。

路由策略管理部143具有IP路由策略管理DB以及应用路由策略管理DB。图7(a)示出IP路由策略管理DB中存储的信息的示例，图7(b)示出应用路由策略管理DB中存储的信息的示例。

IP路由策略管理DB相当于通常的路由器的路由表，如图7(a)所示，存储有目的地IP地址和下一跳(Next Hop)。

应用路由策略管理DB是存储定义针对对象应用的路由控制方法的信息的DB。作为一例，图7(b)中示出了定义将对象应用“Example”的SaaS流程转发至位于本地(local)的下一跳(Next Hop)(互联网连接IF(J.J.J.J))的路由动作的信息。

图7(a)示出IP路由策略管理DB具有目的地IP地址和下一跳(Next Hop)的列的情况，图7(b)示出应用路由策略管理DB具有对象应用以及下一跳(Next Hop)的列的情况，但这些仅为一例。在IP路由策略管理DB和应用路由策略管理DB中可以分别包含通信源的IP地址、端口编号等。

以下，作为接入装置100的基本动作，对用于DB的设定/更新等的动作(称为管理流的控制)以及用户终端10进行通信时的动作(称为数据流的控制)进行说明。

＜管理流的控制＞

沿着图8所示的流程图的步骤对管理流的控制中的接入装置100的动作进行说明。

S101)对象指定

指示接收部110从用户接收Local breakout的对象SaaS的指定，并根据接收内容分别对DNS控制部120和SD-WAN路由部140进行指示。

S102)DNS分配策略管理DB更新

DNS控制部120从公共应用管理部130收集针对对象SaaS的Local breakout所需的信息，并更新DNS分配策略管理DB(例：图6)。

针对对象SaaS的Local breakout所需的信息例如是与对象SaaS对应的1个或者多个FQDN(FQDN列表)。DNS控制部120将所取得的FQDN列表中的FQDN与所设想的动作关联，并存储在DNS分配策略管理DB中。

在本实施方式中，对于Local breakout时的下一跳(Next-hop)，设想事先设定的外部DNS服务器310的IP地址(Y.Y.Y.Y)。对于与除此以外的FQDN相关的查询，设想内部DNS服务器210的IP地址(X.X.X.X)。

例如，图6的最初的记录中记录有与在DNS查询中的对象SaaS的FQDN是Example.com情况下将该DNS查询转发(Forward)至IP地址(Y.Y.Y.Y)的动作对应的信息。

S103)应用路由策略管理DB更新

SD-WAN路由部140更新应用路由策略管理DB(例：图7(b))。具体来说，如图7(b)所示，记录关联了对象SaaS与事先定义的下一跳(Next Hop)地址的信息。

＜数据流的控制例1＞

接着，沿着图9的流程图的步骤对数据流的控制例1中的接入装置100的动作进行说明。在数据流的控制例1中，用户终端10中的DNS服务器的地址被设定为接入装置100的DNS控制部120(Z.Z.Z.Z)。

S201)DNS查询接收/转发

路由控制部142接收从用户终端10发送的DNS查询，与通常的路由器同样地，按照IP路由策略管理DB(例：图7(a))将对应的查询转发至DNS控制部120。DNS控制部120的DNS分配部121接收DNS查询。

S202)DNS查询重新转发

DNS控制部120中的DNS分配部121按照DNS分配策略管理DB(例：图6)重新转发接收到的DNS查询。

例如，在对应的DNS查询中所包含的FQDN是对象SaaS的Example.com的情况下，DNS分配部121按照DNS分配策略管理DB(图6)，将该DNS查询转发至外部DNS服务器310(Y.Y.Y.Y)。对于其它的DNS查询，根据默认(Default)被转发至内部DNS服务器210。另外，在数据流的控制例1中，通过具有后述的查询目的地变更部123，也能够将DNS查询的目的地变更为转发目的地的IP地址。

之后，用户终端10接收从对应的DNS服务器送出的IP地址，并开始将该IP地址作为目的地的数据通信。

S203)数据流检测

在实施DNS的查询之后，当由用户终端10进行的数据通信开始时，对象SaaS的数据流被LAN-IF170接收，并被发送给SD-WAN路由部140。

SD-WAN路由部140的应用检测部141检测特定的SaaS的数据流，并使用对应流的目的地IP地址，更新应用缓存(例：图5)。作为由应用检测部141进行的SaaS数据流的检测方法，例如有从HTTP/HTTPs的报头(Header)中提取的方法，但不限于此。

S204)路由控制

路由控制部142使用应用路由策略管理DB(例：图7(b))和应用缓存(例：图5)，来控制SaaS数据流的路由。例如，在对象SaaS是Example.com的情况下，在应用缓存中作为针对Example.com的目的地地址而记录有A.A.A.A之后，当路由控制部142接收到目的地为A.A.A.A的分组时，通过参考应用缓存，从而掌握对象SaaS是Example的情况，并且通过参考应用路由策略管理DB，将该分组转发到互联网连接IF160(J.J.J.J)。

S205)路由控制

之后，在产生了相同的数据流的情况下，可以通过使用应用缓存而执行路由的控制，而无需经由应用检测部141。

＜数据流的控制例2＞

接着，作为数据流的控制例2，针对用户终端10中的DNS服务器的地址被设定为内部DNS服务器210(X.X.X.X)的案例，说明与数据流的控制例1的不同之处。

在数据流的控制例2中，如图10所示，DNS控制部120除了DNS分配部121和DNS分配策略管理部122以外，还具有查询目的地变更部123。

此外，如图11所示，对应用路由策略管理DB新追加了针对DNS查询的路由策略。该路由策略是通过端口编号(例：53)确定DNS查询业务，并将下一跳(Next Hop)设为DNS控制部120(Z.Z.Z.Z)的策略。

沿着图12的流程图的步骤对该情况下的数据流的控制进行说明。

S301)DNS查询接收/转发

当接收到DNS查询时，路由控制部142按照应用路由策略管理DB(图11)中的与DNS相关的策略，将该DNS查询转发至DNS控制部120(Z.Z.Z.Z)。

S302)DNS查询重新转发

DNS控制部120中的DNS分配部121根据DNS分配策略管理部122重新转发接收到的DNS查询。对于对象SaaS以外的查询，按照默认被重新转发到内部DNS服务器210(X.X.X.X)。

S303)目的地地址变更

另一方面，对于对象SaaS的DNS查询，在由查询目的地变更部123变更了目的地的基础上，重新转发。事先设定作为变更目的地的DNS查询的目的地地址，作为示例，外部DNS服务器310的IP地址(Y.Y.Y.Y)被设定为变更目的地。以后的处理与数据流的控制例1是同样的。

＜使用了DNS的查询的结果的应用缓存的更新＞

在上述的示例中，应用检测部141通过解析分组从而识别与该分组相关的数据流对应的SaaS应用，并更新了应用缓存(例：图5)。代替该方法(或者除了该方法以外)，也可以使用DNS的查询结果来更新应用缓存。

通过具有使用DNS的查询的结果来随时更新应用缓存的功能，能够在第一个分组(First Packet)中进行SaaS应用的识别。

沿着图13的流程图的步骤对该情况下的接入装置100的动作进行说明。

S401)应用缓存更新

例如，DNS查询被转发至外部DNS服务器310，从外部DNS服务器310送出的查询结果(与FQDN对应的IP地址)由路由控制部142接收。路由控制部142使用该查询结果来更新应用缓存。

例如，设Example.com的查询结果为A.A.A.A，Example365.com的查询结果为C.C.C.C，在路由控制部142接收到各个查询结果的情况下，如图14所示，应用缓存被更新。即，被追加A.A.A.A的记录和C.C.C.C的记录。另外，本实施方式中的Example.com和Example365.com的应用名均被识别为“Example”。

S402)路由控制

之后，路由控制部142在接收到对应的SaaS的数据流的情况下，使用应用路由策略管理DB(例：图7(b))和应用缓存(例：图14)，控制对应的流程的路由。

具体来说，路由控制部142通过数据流的目的地IP地址检索应用缓存，在存在命中的记录的情况下，使用该记录的应用名(对象SaaS名)在应用路由策略管理DB中检索该对象SaaS的下一跳(Next Hop)。其结果，路由控制部142向下一跳(Next Hop)中所记述的IP地址转发对应的流程。

(第2实施方式)

接着，对第2实施方式进行说明。在此，主要对与第1实施方式不同之处进行说明。

＜装置结构＞

图15示出第2实施方式中的接入装置100的功能结构图。如图15所示，第2实施方式中的接入装置100是对第1实施方式中的接入装置100追加了代理控制部180的结构。此外，图15中示出了内部代理服务器220。如图所示，在此，代理控制部180的IP地址为Z'.Z'.Z'.Z'，内部代理服务器220的IP地址为Z1.Z1.Z1.Z1。

如图15所示，代理控制部180具有代理分配部181和代理分配策略管理部182。

在第2实施方式中，由于使业务路由至代理控制部180，因此如图16(a)所示，对路由策略管理部143中的IP路由策略管理DB新追加与Z'.Z'.Z'.Z'相关的策略。

此外，代理分配策略管理部182具有代理分配策略管理DB。图17示出代理分配策略管理DB中存储的信息的示例。如图17所示，代理分配策略管理DB是存储有各FQDN以及定义针对IP地址的代理的控制动作的信息的DB。

代理分配部181按照代理分配策略管理DB的信息，执行业务的分配控制。例如，代理分配部181在接收到目的地的FQDN是Example.com的分组的情况下，使该分组通过(passthrough)代理。在默认(Default)的情况下，代理分配部181与内部代理(Z1.Z1.Z1.Z1)实施代理链接(proxy chaining)。

＜管理流的控制＞

沿着图18所示的流程图的步骤，对伴随代理控制部180的追加而追加的控制流程进行说明。

S501)对象指定

首先，指示接收部110从用户接收Local breakout的对象SaaS的指定，并根据接收内容对代理控制部180进行指示。

S502)代理分配策略管理DB更新

代理控制部180从公共应用管理部130的应用管理DB中收集针对对象SaaS的Localbreakout所需的信息，并更新代理分配策略管理DB。

针对对象SaaS的Local breakout所需的信息例如是与对象SaaS对应的1个或者多个FQDN(FQDN列表)和1个或者多个IP地址(IP地址列表)。代理控制部180将所取得的FQDN列表和IP地址列表与设想的动作关联，并存储在代理分配策略管理DB中。

如图17所示，非通过(non-pass through)的情况(默认的情况)下的下一跳(Next-hop)设为作为事先设定的代理链接的目的地的内部DNS服务器220的IP地址(Z1.Z1.Z1.Z1)。

＜数据流的控制＞

接着，沿着图19的流程图的步骤，对数据流的控制中的接入装置100的动作进行说明。

S601)业务接收/转发

路由控制部142接收朝向代理控制部180的业务(在此，为SaaS接入请求)，按照路由策略管理部143的IP路由策略管理DB(例：图16(a))，将业务转发至代理控制部180(Z'.Z'.Z'.Z')。代理控制部180中的代理分配部181接收业务(SaaS接入请求)。

S602)业务接收/转发

代理分配部181暂时终止接收到的SaaS接入请求，并按照代理分配策略管理DB(图17)，进行用于接入对应的SaaS的代理控制。

作为一例，对于接入到Example.com的请求，按照图17的动作定义，使其通过(passthrough)。在通过的情况下，代理控制部180作为起点而实施DNS的查询。DNS的查询动作、之后的一系列的动作与以上所说明是同样的。另外，该情况下的DNS查询从代理控制部180被发送给路由控制部142，从路由控制部140被发送给DNS控制部120。

另一方面，对于对象SaaS接入以外的数据流，相当于默认(Default)，为了与内部代理服务器220链接，代理控制部180向内部代理服务器220请求对应的数据流的接入。作为请求的内容的一例，可以考虑下述的方式。

[IP Header(IP报头)(摘录)]

Src IP：Z'.Z'.Z'.Z'

Dst IP：Z1.Z1.Z1.Z1

[TCP Header(TCP报头)(摘录)]

Src port：26001

Dst port：443

[HTTP request(HTTP请求)(摘录)]

GET HTTPs：//www.example.com

按照上述的请求，针对对应的数据流，内部代理服务器220作为针对用户终端10的代理来进行动作。

＜信息收集方法的其它例＞

在上述的管理流的示例中，假设了代理控制部180从公共应用管理部130的应用管理DB中收集所需的信息，但除此以外(或者代替于此)，也可以从应用缓存中收集信息。图20示出还利用从应用缓存收集到的信息更新的代理分配策略管理DB182的示例。

在该情况下，代理控制部180除了从应用管理DB收集与对象SaaS对应的FQDN列表和IP地址以外，还从应用缓存收集已经高速缓存(caching)的IP地址，并将这些IP地址与代理分配策略管理DB中设想的动作关联。此外，代理分配策略管理部182定期地与公共应用管理部130同步，始终保持应用管理DB和应用缓存的最新信息。

由于SaaS服务器的IP地址被随时变更，因此通过如上所述那样保持应用缓存的最新信息，能够执行基于正确的IP地址的动作。

＜关于应用管理DB、应用缓存的定期更新＞

作为第1实施方式和第2实施方式的公共的动作，如图21所示，可以是通过从外部应用管理服务器400取得信息，公共应用管理部130定期地更新应用管理DB。参照图22的流程图对该情况下的动作进行说明。另外，外部应用管理服务器400中存储有最新的信息。

S701)轮询(polling)

公共应用管理部130定期地对外部应用管理服务器400进行是否存在DB的更新(update)的查询(轮询)。

S702)更新

公共应用管理部130在检测到存在更新(update)时，接收最新的数据，并更新应用管理DB。

此外，公共应用管理部130可以定期地更新应用缓存。在该情况下，如图23所示，应用缓存按照每个记录保持计时器值。公共应用管理部130监视应用缓存，并在从设定有记录的数据的时刻起未被更新而经过了计时器值的期间的时刻自动地删除该记录。

SaaS服务器的IP地址未被固定，随时被变更，因此通过如上所述那样设置更新结构，能够执行基于正确的IP地址的动作。

(实施方式的效果等)

如上述所说明，在本发明的实施方式所涉及的接入装置100中，除了SD-WAN路由部140以外，还设置公共应用管理部130、DNS控制部120以及代理控制部180。

DNS控制部120参考公共应用管理部130，并且追随特定SaaS的数据流的控制，判断/控制与其相关的DNS业务的最佳出口。同样地，代理控制部180参考公共应用管理部130，并且针对特定SaaS的数据流，进行路由控制，以使现有代理迂回。另外，随时向应用缓存反映作为经由DNS控制部120进行的DNS的查询结果的SaaS服务器的IP地址，能够使用接入目的地的SaaS服务器IP，识别特定SaaS。

通过具有上述这样的结构的接入装置100，在使特定SaaS的数据流直接从分支站点疏导(breakout)时，能够与其一起联动地控制与对应的SaaS接入相关的DNS业务和/或朝向代理的路由，从而实现朝向对应的SaaS的最佳接入。

即，通过使DNS流与数据流的出口一致，能够向分支站点的最近的SaaS服务器进行接入。此外，通过将现有代理旁路，能够期待减轻由对应的SaaS接入引起的代理处理负载。另外，能够使用最新的DNS的查询结果，在第一个分组(First Packet)中识别特定SaaS。

(实施方式的总结)

如上述所说明，通过本实施方式，至少提供下述的控制装置、控制方法及程序。

(第1项)

一种控制装置，该控制装置与多个网络连接，并将从用户终端接收到的分组分配给该多个网络中的任意网络，其中，所述控制装置具有：

DNS控制部，其接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及

路由部，其接收分组，并根据该分组的目的地地址决定该分组的发送目的地，向所决定的发送目的地发送该分组。

(第2项)

根据第1项所述的控制装置，其中，

所述控制装置具有应用表，该应用表存储将分组的目的地地址与该分组的目的地的应用关联起来的信息，

所述路由部通过参考所述应用表，掌握与接收到的分组的目的地地址对应的应用，并按照对该应用预先确定的策略将该分组分配给所述多个网络中的任意网络。

(第3项)

根据第2项所述的控制装置，其中，

所述路由部使用所述DNS查询分组的查询对象以及作为查询的应答而接收到的地址来更新所述应用表。

(第4项)

根据第2或3项所述的控制装置，其中，

所述应用表按照每个记录具有计时器值，并删除经过了该计时器值的期间的记录。

(第5项)

根据第1至4项中的任一项所述的控制装置，其中，

所述DNS控制部根据所述DNS查询分组的分配目的地改写该DNS查询分组的目的地地址。

(第6项)

根据第1至5项中的任一项所述的控制装置，其中，

所述控制装置与预定的代理装置连接，

所述控制装置还具有代理控制部，所述代理控制部根据接收到的分组的接入目的地的应用，决定是否向所述代理装置发送该分组。

(第7项)

根据从属于第2至4中的任一项的第6项所述的控制装置，其中，

所述代理控制部具有记录了每个应用的目的地地址以及动作的代理分配表，所述代理控制部通过参考该代理分配表，决定是否向所述代理装置发送分组，

并利用所述应用表来更新所述代理分配表。

(第8项)

根据第1至7项中的任一项所述的控制装置，其中，

所述控制装置具有：

应用管理数据库，其管理应用的信息；以及

管理部，其通过定期地接入到外部的应用管理服务器，来更新所述应用管理数据库。

(第9项)

一种由控制装置执行的控制方法，所述控制装置与多个网络连接，并将从用户终端接收到的分组分配给该多个网络中的任意网络，其中，所述控制方法包括如下步骤：

接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及

接收分组，并根据该分组的目的地地址决定该分组的发送目的地，并向所决定的发送目的地发送该分组。

(第10项)

一种程序，该程序用于使计算机作为第1至8项中的任一项所述的控制装置中的各部件发挥功能。

以上对本实施方式进行了说明，但本发明不限于特定的实施方式，能够在权利要求书所记载的本发明的主旨的范围内，进行各种各样的变形/变更。

本专利申请以在2018年9月20日提出的日本专利申请第2018-176630号为基础并对其主张其优先权，并将日本专利申请第2018-176630号的全部内容引用于本申请中。

标号说明：

10 用户终端

20 封闭网络

30 互联网

100 接入装置

110 指令接收部

120 DNS控制部

121 DNS分配部

122 DNS分配策略管理部

123 查询目的地变更部

130 公共应用管理部

140 SD-WAN路由部

141 应用检测部

142 路由控制部

143 路由策略管理部

150 封闭网络连接IF

160 互联网连接IF

170 LAN-IF

180 代理控制部

181 代理分配部

182 代理分配策略管理部

210 内部DNS服务器

220 内部代理服务器

310 外部DNS服务器

320 SaaS服务器

400 外部应用管理服务器

1000 驱动装置

1001 记录介质

1002 辅助存储装置

1003 内存装置

1004 CPU

1005 接口装置

1006 显示装置

1007 输入装置

Claims (10)

1.一种控制装置，该控制装置与多个网络连接，将从用户终端接收到的分组分配给该多个网络中的任意网络，其中，所述控制装置具有：

DNS控制部，其接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及

路由部，其接收分组，并根据该分组的目的地地址决定该分组的发送目的地，向所决定的发送目的地发送该分组。

2.根据权利要求1所述的控制装置，其中，

所述控制装置具有应用表，该应用表存储将分组的目的地地址与该分组的目的地的应用关联起来的信息，

所述路由部通过参考所述应用表，掌握与接收到的分组的目的地地址对应的应用，并按照对该应用预先确定的策略将该分组分配给所述多个网络中的任意网络。

3.根据权利要求2所述的控制装置，其中，

所述路由部使用所述DNS查询分组的查询对象以及作为查询的应答而接收到的地址来更新所述应用表。

4.根据权利要求2或3所述的控制装置，其中，

所述应用表按照每个记录具有计时器值，并删除经过了该计时器值的期间的记录。

5.根据权利要求1至4中的任一项所述的控制装置，其中，

所述DNS控制部根据所述DNS查询分组的分配目的地改写该DNS查询分组的目的地地址。

6.根据权利要求1至5中的任一项所述的控制装置，其中，

所述控制装置与预定的代理装置连接，

所述控制装置还具有代理控制部，所述代理控制部根据接收到的分组的接入目的地的应用，决定是否向所述代理装置发送该分组。

7.根据从属于权利要求2至4中的任一项的权利要求6所述的控制装置，其中，

所述代理控制部具有记录了每个应用的目的地地址以及动作的代理分配表，所述代理控制部通过参考该代理分配表，决定是否向所述代理装置发送分组，

所述代理控制部利用所述应用表来更新所述代理分配表。

8.根据权利要求1至7中的任一项所述的控制装置，其中，

所述控制装置具有：

应用管理数据库，其管理应用的信息；以及

管理部，其通过定期地接入到外部的应用管理服务器，来更新所述应用管理数据库。

9.一种由控制装置执行的控制方法，所述控制装置与多个网络连接，并将从用户终端接收到的分组分配给该多个网络中的任意网络，其中，所述控制方法包括如下步骤：

接收从所述用户终端发送的DNS查询分组，并根据该DNS查询分组的查询对象，将该DNS查询分组分配给所述多个网络中的任意网络；以及

接收分组，并根据该分组的目的地地址决定该分组的发送目的地，并向所决定的发送目的地发送该分组。

10.一种程序，该程序用于使计算机作为权利要求1至8中的任一项所述的控制装置中的各部分发挥功能。

Images