CN117544424A - 基于泛在联接的多协议智慧园区管控平台 - Google Patents

基于泛在联接的多协议智慧园区管控平台 Download PDF

Info

Publication number
CN117544424A
CN117544424A CN202410029790.XA CN202410029790A CN117544424A CN 117544424 A CN117544424 A CN 117544424A CN 202410029790 A CN202410029790 A CN 202410029790A CN 117544424 A CN117544424 A CN 117544424A
Authority
CN
China
Prior art keywords
platform
wake
management
control
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202410029790.XA
Other languages
English (en)
Other versions
CN117544424B (zh
Inventor
郭云昌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wanzhou Jiazhi Information Technology Co ltd
Original Assignee
Wanzhou Jiazhi Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wanzhou Jiazhi Information Technology Co ltd filed Critical Wanzhou Jiazhi Information Technology Co ltd
Priority to CN202410029790.XA priority Critical patent/CN117544424B/zh
Publication of CN117544424A publication Critical patent/CN117544424A/zh
Application granted granted Critical
Publication of CN117544424B publication Critical patent/CN117544424B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请涉及网络通信技术领域，公开了一种基于泛在联接的多协议智慧园区管控平台，该多协议智慧园区管控平台包括管控平台中台、云服务器和智慧园区管控内网；管控平台中台与智慧园区管控内网连接；云服务器包括负载均衡器、至少一个第一业务服务器和NAT网关；负载均衡器上配置第一公网互联网协议IP地址，且负载均衡器基于第一公网IP地址与各第一业务服务器通信连接；NAT网关分别与各第一业务服务器和智慧园区管控内网通信连接，NAT网关用于在云服务器与智慧园区管控内网之间进行IP地址转换，实现云服务器与智慧园区管控内网的互联。本申请实施例可减少公网IP资源的浪费，降低了系统的安全风险和系统的运维复杂度。

Description

基于泛在联接的多协议智慧园区管控平台
技术领域
本申请涉及网络通信技术领域，具体涉及一种基于泛在联接的多协议智慧园区管控平台。
背景技术
目前，在多协议智慧园区管控过程中，需要部署各项业务服务器时，一般将主要的服务部署在云服务器，而次要的服务则部署在智慧园区管控内网中。在云服务器访问智慧园区管控内网中的业务服务器时，通过DNAT（Destination Network AddressTranslation，地址转换），将公网中的流量基于不同的源IP地址和DPORT（DestinationPORT，目标端口）转发至智慧园区管控内网中对应的业务服务器上。然而，部署在云服务器的各业务服务器均配置有对应的公网IP，既消耗较多的公网IP资源，还会增加各业务服务器的安全风险。
发明内容
本申请旨在至少解决相关技术中存在的技术问题之一。为此，本申请实施例提供一种基于泛在联接的多协议智慧园区管控平台，可以减少公网IP资源的浪费，降低系统的安全风险和系统的运维复杂度。
第一方面，本申请提供一种基于泛在联接的多协议智慧园区管控平台，多协议智慧园区管控平台包括管控平台中台、云服务器和智慧园区管控内网；所述管控平台中台与所述智慧园区管控内网连接，对所述智慧园区管控内网进行管理；所述云服务器包括负载均衡器、至少一个第一业务服务器和NAT网关；
所述负载均衡器上配置第一公网IP地址，且所述负载均衡器基于第一公网IP地址与各所述第一业务服务器通信连接；所述NAT网关分别与各所述第一业务服务器和所述智慧园区管控内网通信连接，所述NAT网关用于在所述云服务器与所述智慧园区管控内网之间进行IP地址转换，实现所述云服务器与所述智慧园区管控内网的互联；
所述负载均衡器上配置第一防火墙规则和安全套接层SSL证书；所述NAT网关上配置有第二公网IP地址和第二防火墙规则，各所述第一业务服务器用于基于所述第二公网IP地址访问公网；所述智慧园区管控内网包括路由器和至少一个第二业务服务器，所述路由器分别与各所述第二业务服务器和所述NAT网关通信连接；所述路由器上配置所述第二公网IP地址对应的第二防火墙规则和出口IP地址，各所述第二业务服务器用于基于所述出口IP地址访问所述公网；
所述负载均衡器用于：基于第一公网IP地址，获取每个待接入平台对应的目标网址；在所述目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将所述目标网址发送至所述NAT网关；
所述NAT网关用于：将所述目标网址发送至所述智慧园区管控内网中的路由器；将所述目标网址与所述智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定所述目标网址对应的目标业务服务器；将所述目标网址发送至所述目标业务服务器，以将每个所述待接入平台连接至所述多协议智慧园区管控平台。
第二方面，本申请提供一种多协议智慧园区管控方法，用于第一方面所述的基于泛在联接的多协议智慧园区管控平台，包括：
于第一公网IP地址，获取每个待接入平台对应的目标网址；
在所述目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将所述目标网址发送至所述NAT网关；
将所述目标网址发送至所述智慧园区管控内网中的路由器；
将所述目标网址与所述智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定所述目标网址对应的目标业务服务器；
将所述目标网址发送至所述目标业务服务器，以将每个所述待接入平台连接至所述多协议智慧园区管控平台。
第三方面，本申请还提供一种电子设备，包括存储器存储有多条指令；处理器从存储器中加载指令，以执行本申请实施例所提供的任一种多协议智慧园区管控方法。
第四方面，本申请还提供一种计算机可读存储介质，计算机可读存储介质存储有多条指令，指令适于处理器进行加载，以执行本申请实施例所提供的任一种多协议智慧园区管控方法。
第五方面，本申请还提供一种计算机程序产品，包括计算机程序或指令，计算机程序或指令被处理器执行时实现本申请实施例所提供的任一种多协议智慧园区管控方法。
本申请的多协议智慧园区管控平台通过在云服务器中部署负载均衡器、至少一个第一业务服务器和NAT网关，仅在负载均衡器上配置第一公网IP地址，且负载均衡器和各第一业务服务器通信连接，且NAT网关分别与各第一业务服务器和智慧园区管控内网通信连接，统一通过负载均衡器和NAT网关访问智慧园区管控内网，减少公网IP资源的浪费，同时，公网IP地址的配置数量的减少，可降低系统被攻击的概率，进而降低了系统的安全风险和系统的运维复杂度。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之一；
图2是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之二；
图3是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之三；
图4是本申请实施例中提供的策略路由方法的流程示意图之一；
图5是本申请实施例中提供的策略存储结构的示意图；
图6是本申请实施例中提供的策略路由方法的流程示意图之二；
图7是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之四；
图8是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之五；
图9是本申请实施例中提供的云接入网关架构的示意图；
图10是本申请实施例中提供的多协议智慧园区管控方法的流程示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。同时，在本申请实施例的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更特征。在本申请实施例的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
需要说明的是，本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台应用于封闭铁路环境中。可选的，参考图1，图1是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之一。多协议智慧园区管控平台包括管控平台中台、云服务器和智慧园区管控内网；管控平台中台与智慧园区管控内网连接，对智慧园区管控内网进行管理。
在本申请实施例中，在云服务器中部署负载均衡器（UCloud Load Balancer，ULB）、至少一个第一业务服务器和NAT网关（NAT Gateway），并仅在负载均衡器中配置第一公网IP地址，在各第一业务服务器中不再配置第一公网IP地址（Internet ProtocolAddress，互联网协议地址），并通过NAT网关与智慧园区管控内网的通信连接，实现云服务器与智慧园区管控内网互联，并通过减少配置的第一公网IP地址的数量，降低通过该第一公网IP地址攻击各第一业务服务器和智慧园区管控内网的概率，进而提高系统的安全性，且第一公网IP地址的配置数量减少，还可降低对该第一公网IP地址的管理难度，进而降低系统的运维复杂度。需要说明的是，该负载均衡器是一种网路设备或服务，用于基于网络报文或代理方式在多个第一业务服务器之间分配流量，实现负载均衡和高可用性，即，通过该第一公网IP地址，负载均衡器可以接收来自公网的流量，并将该流量转发至云服务器的各第一业务服务器上。
可选的，第一业务服务器可以包括git业务服务器、gitlab业务服务器、jira业务服务器和wiki业务服务器等，本申请实施例对此不做限制。
在本申请实施例中，在负载均衡器上配置第一公网IP地址后，为提高系统的安全性，仅在该负载均衡器上配置第一防火墙规则和安全套接层SSL（Secure Socket Layer，安全套接层）证书，避免浪费各第一业务服务器的算力，且随着SSL证书和第一防火墙规则的配置数量的减少，大幅度降低系统的维护复杂度。需要说明的是，SSL证书用于加密待接入平台与各第一业务服务器或智慧园区管控内网之间的通信，确保通信过程中数据传输的安全性。防火墙规则可用于防止来自公网的非法访问和攻击，提高整个系统的安全性和可靠性。
在本申请实施例中，在NAT网关上配置有第二公网IP地址和第二防火墙规则，便于各第一业务服务器通过该NAT网关访问公网，且第二防火墙规则可用于防止来自公网通过该NAT网关对各第一业务服务器或智慧园区管控内网的非法访问和攻击，降低整个系统的安全风险。
进一步地，图2是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之二，如图2所示，所述智慧园区管控内网中部署有路由器和至少一个第二业务服务器，且该路由器连接云服务器中的NAT网关和各第二业务服务器，在待接入平台通过负载均衡器访问对应的第二业务服务器时，可通过NAT网关将目标网址转发至路由器，并由路由器将该目标网址通过DNAT（Destination Network Address Translation，目的地址转换）技术转发至对应的第二业务服务器，实现待接入平台对智慧园区管控内网的访问。
需要说明的是，若在智慧园区管控内网中部署的第二业务服务器的数量较少，上述路由器分别与各第二业务服务器通信连接可以理解为该路由器与各第二业务服务器直接通信连接，若在智慧园区管控内网中部署的第二业务服务器的数量较多，上述路由器与各第二业务服务器通信连接可以理解为该路由器可以与部分第二业务服务器直接连接，同时，可通过该部分第二业务服务器与其他部分的第二业务服务器间接连接。
可选的，第二业务服务器可以包括：ldap业务服务器和AD域业务服务器，本申请实施例对此不做限制。此外，各第二业务服务器之间可通信连接，此时，路由器中包括各第二业务服务器之间的网络拓扑结构，并根据该网络拓扑结构确定路由表。该路由表中可以包括网络地址、子网掩码、下一跳地址、出接口和路由度量值等信息，其中，网络地址和子网掩码用于确定数据包的目标网络或主机，下一跳地址和出接口用于确定数据包的转发路径，路由度量值用于衡量不同路径的优先级和可靠性。
在本申请实施例中，在云服务器中，NAT网关分别连接各第一业务服务器和路由器，且该NAT网关上配置有第二公网IP地址，即，NAT网关作为云服务器的一个访问接口，而路由器作为智慧园区管控内网的访问接口。为避免非法待接入平台从路由器非法访问或攻击智慧园区管控内网，在路由器上需配置第二公网IP地址对应的第二防火墙规则，降低系统的安全风险的同时，通过配置与NAT网关相同的第二防火墙规则，可降低对防火墙规则的管理复杂度。此外，该路由器上还配置有出口IP地址，该出口IP地址为公网IP地址，各第二业务服务器可通过该出口IP地址访问公网。
在本申请实施例中，负载均衡器根据第一公网IP地址，获取每个待接入平台对应的目标网址，在目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将目标网址发送至NAT网关。进一步地，NAT网关将目标网址发送至智慧园区管控内网中的路由器，并将目标网址与智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定目标网址对应的目标业务服务器。进一步地，NAT网关将目标网址发送至目标业务服务器，以将每个待接入平台连接至多协议智慧园区管控平台。
本申请实施例的多协议智慧园区管控平台通过在云服务器中部署负载均衡器、至少一个第一业务服务器和NAT网关，仅在负载均衡器上配置第一公网IP地址，且负载均衡器和各第一业务服务器通信连接，且NAT网关分别与各第一业务服务器和智慧园区管控内网通信连接，统一通过负载均衡器和NAT网关访问智慧园区管控内网，减少公网IP资源的浪费，同时，公网IP地址的配置数量的减少，可降低系统被攻击的概率，进而降低了系统的安全风险和系统的运维复杂度。
进一步地，图3是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之三。多协议智慧园区管控平台还包括策略路由单元，管控平台中台与策略路由单元连接，对策略路由单元进行管理。
在本申请实施例中，策略路由单元根据待接入平台数据和策略数据库，进行策略匹配；策略数据库包括多条策略，各策略包括多个动作。
图4是本申请实施例提供的策略路由方法的流程示意图之一。参照图4，在数据面增加uabf（uni-acl-based forward，统一abf）处理节点，uabf节点对配置在接口的所有的策略进行匹配，若策略中配置了对应的动作，则在数据转发过程中进行该动作标记。后续数据处理节点如果读到该节点的标记，则进行相应的业务处理。可以理解的是，图4中仅仅列出了匹配命中需要执行的动作，动作执行后，还有一系列的转发操作来完成把数据包发送出去。
此处，策略作用在接口上，使能snat和abf处理节点，保证后续业务可以进入到对应action节点进行业务处理。
图5是本申请实施例提供的策略存储结构的示意图。可选地，如图5所示，策略以upolicy_t的数据结构存储，包括acl_id（策略对应的acl的id）、policy_id（策略的id）和action（需要执行的动作），action中包括Action1到ActionX的X个需要执行的动作，以c++语言为例，action若以vector对象数组进行存储，则vector中的一个元素对应一个动作。如图5所示，每个action以upolicy_action_t的数据结构存储，其中，action_type是策略执行的动作的类型，例如是pbr（Policy-Based Routing，策略路由）还是snat等；upolicy_snat_t是snat的配置信息，如地址池编号等配置参数；upolicy_pbr_t是pbr的配置信息和内部转发信息，包括创建fib_node（路由节点）和fib_path（路由路径）用于后续路由转发使用，如路由模式为二层转发还是三层转发，若是二层转发，还记录有接口信息，若是三层转发，则记录转发路径信息。
在本申请实施例中，策略路由单元根据匹配结果，生成标记位图，标记位图中的一个比特位对应一个动作。
匹配到待接入平台数据对应的策略后，将待接入平台数据中配置的动作与该策略在策略数据库中对应的动作逐一比对，生成标记位图。此处，位图（Bitmap，BMP）是0-1表示的一组数，每一个比特位对应一个动作，例如以0表示待接入平台数据中未配置的动作，以1表示待接入平台数据中配置有的动作，则110表示待接入平台数据配置有左边两个比特位对应的动作，而没有配置最右边一个比特位对应的动作，若左边第一个比特位对应snat动作，左边第二个比特位对应abf动作，则110表征该待接入平台数据需要执行snat操作和abf转发。此处，生成标记位图后，将生成的标记位图存储在缓存中，以供后续节点读取使用。
在本申请实施例中，策略路由单元根据标记位图，执行相应的动作。
各动作节点（如执行snat操作的snat节点、进行abf的abf节点）分别读取标记位图，根据对应比特位的值，判断自身是否需要执行相应的动作，若确定需要执行相应动作，则进行相应处理。
此外，整个转发过程每个节点只完成自己特定的操作。uabf节点的作用是策略匹配，匹配命中后，策略信息会存储在缓存中，后续节点可以读取使用。若uabf配置了策略路由，则进入abf节点后，读取策略信息，需要执行策略路由；二层转发则会重新封装二层头部信息，直接送到发送节点进行处理；三层转发会，传递给ip4-load-balance节点处理，选择优先级最高的路径进行转发。若uabf配置了SNAT，进入SNAT后，读取到SNAT策略信息，则进行SNAT转换，否则进行后续转发处理。
需要说明的是，创建策略时在uabf节点创建了路由路径，但是查询转发策略的是abf节点，因此需要在策略创建时，创建abf的下一个节点转发信息，明确下一转发节点。在报文转发过程中uabf节点会把转发策略传递给abf。数据在abf节点查询uabf传递过来的转发策略，数据传递给ip4-load-balance节点进行具体路径选择（可能包含多路径）。
在本申请实施例中，如图4所示，具体地，策略是配置在接口上的，对接口上的策略进行匹配，也就是将待接入平台数据中配置的策略信息与接口上配置的policy db（策略数据库）中存储的策略进行匹配，确定与该待接入平台数据相匹配的策略，该策略包括多个动作，逐一判断待接入平台数据是否配置有该策略中的各个动作。
在本申请实施例中，对于二进制的位图，每一个比特位为0或1，可以将第一标记设置为0，第二标记设置为1，也可以将第一标记设置为1，第二标记设置为0。为便于理解，下述各实施例以第一标记是1，第二标记是0为例进行说明。
在本申请实施例中，匹配模式分permit（允许通过）和deny（拒绝通过）两种：
permit：路由将被允许通过，并且对路由信息的一些属性进行设置；
deny：路由将被拒绝通过；
为了区分permit与deny，对标记位图的最高位进行设置，若策略匹配模式为deny，则将最高的比特位设置为1，若策略匹配模式为permit，则将最高的比特位设置为0。例如，若策略匹配模式为deny，则对应的标记位图为1000 0000 0000 0110，若策略匹配模式为permit，则对应的标记位图为0000 0000 0000 0110。
本申请实施例通过最高比特位区分permit和deny两种模式，后续各动作节点基于最高比特位进行处理，对于标记为deny的路由进行拒绝，不执行相应的动作，实现策略路由。
在本申请实施例中，标记位图0110，从左往右第一位（最高位）为0，表示匹配模式为permit，需要执行相应动作，第二位对应的动作为snat，snat节点读取第二位的值，第二位为1，表示需要执行动作，snat节点执行snat操作，第三位对应的动作为abf，abf节点读取第三位的值，第三位为1，表示需要执行动作，abf节点进行abf转发。
在本申请实施例中，待接入平台配置云网关的acl规则，配置云网关的统一策略，将策略关联acl，并配置策略对应的action，所有action信息记录到策略中，策略信息存储到策略数据库。
图6是本申请实施例提供的策略路由方法的流程示意图之二。为便于理解，下面结合图6，对本申请实施例提供的策略路由方法的总体技术流程进行说明。
（1）配置云网关的acl规则，匹配数据包的五元组（源IP地址，源端口，目的IP地址，目的端口和传输层协议）等信息。
（2）配置云网关的统一策略，关联ACL和配置对应的action，所有action信息记录到策略中，策略信息存储到策略数据库。配置了abf action时，策略路由相关的fib path和fib node等也在创建策略时创建。
（3）接口上配置统一策略，策略ID会记录到该接口的策略数据库中，后续匹配时，从该接口的策略数据库中读取策略进行匹配。配置了abf action时，需要设置ip-load-balance的上一个转发节点为abf，而非uabf。
（4）uabf收到数据后，进行策略匹配。若匹配结果为permit，遍历该策略所有action_type，若配置了该action，则在标记位图对应的bit位置1，若策略匹配结果为deny或者匹配失败，则在标记位图的最高位置1，表示不执行该action。
（5）uabf节点打完action标记，并将转发策略传递至action节点。action节点读取action标记，若配置了action，则执行对应的action。abf会从策略中读取转发信息，将数据报文转到ip-load-balance节点进行路由，把数据转发到其他节点。其他action节点，也会读取action标记，执行对应action处理。
（6）策略处理完毕后，进入到其他转发节点进行处理。
本申请实施例将策略及相应的动作存入策略数据库中，将待接入平台数据与策略数据库中的策略进行匹配，在需要执行的动作所对应的比特位进行标记，后续数据处理节点读取标记位图即可确定是否需要执行相应的业务处理动作，实现了一条策略对应配置多个动作，减少策略配置的数量，从而减少策略匹配时间，提高路由转发效率。
进一步地，图7是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之四，多协议智慧园区管控平台还包括语音协同唤醒单元，管控平台中台与语音协同唤醒单元连接，对语音协同唤醒单元进行管理。
在本申请实施例中，语音协同唤醒单元接收每个待接入平台发送的协同唤醒请求消息，将每个待接入平台加入至协同唤醒清单，协同唤醒清单中的不同平台通过预设的统一唤醒词唤醒。
协同唤醒请求消息中携带的信息包括至少一项：待接入平台的交互令牌、对应的用户标识信息、待接入平台的位置信息、待接入平台的能力信息和唤醒优先级信息。用户将待接入平台带离语音协同唤醒单元后，语音协同唤醒单元发现下挂的平台有变化，会主动更新协同唤醒清单，即将该待接入平台从协同唤醒清单中删除，后续在唤醒判别时将只选择在协同唤醒清单中的待接入平台。
在本申请实施例中，语音协同唤醒单元向每个待接入平台发送协同唤醒请求响应消息，协同唤醒请求响应消息中携带统一唤醒词。
统一唤醒词是预先设置的唤醒词，可以根据需要进行设置，通过统一唤醒词，可以实现对该语音协同唤醒单元中的各个平台进行协同唤醒。
待接入平台根据配网时生成的位置ip上报，用于后续协同唤醒判别。并且用户可自定义唤醒优先级。语音协同唤醒单元中的网络设备（如语音协同唤醒单元的网关或平台），接收待接入平台发送的协同唤醒请求消息之后，反馈协同唤醒请求响应消息。协同唤醒请求响应消息中携带的信息包括：交互令牌、用户唯一标识、统一唤醒词标识和唤醒判别标识，如表1所示。
表1 协同唤醒请求响应消息中携带的信息
在本申请实施例中，语音协同唤醒单元接收待接入平台的唤醒语音信息，对唤醒语音信息进行语音识别，在唤醒语音信息与统一唤醒词匹配的情况下，通过端侧唤醒判别定位目标唤醒平台。
网络设备接收用户的唤醒语音信息，对唤醒语音信息进行语音识别，若唤醒语音信息与统一唤醒词匹配，则确定用户要唤醒语音协同唤醒单元中的某一平台，那么网络设备首先会通过端侧唤醒判别定位目标唤醒平台。
其中，端侧唤醒判别是指在网络设备本地进行协同唤醒的判别，以定位出目标唤醒平台，目标唤醒平台即用户的唤醒语音信息所针对的唤醒对象。
端侧唤醒判别可以根据距离和朝向等信息来确定目标唤醒平台，例如，离用户较近的平台会优先应答。在本申请一些实施例中，端侧唤醒判别考虑语音朝向和强度。端侧唤醒判别的优点是判别速度快，可以保证用户交互体验，且端侧判别由于只需网络设备日常拾音，所以只需网络设备长期连接电源，其他终端则不开启唤醒判别。并且其他终端均可采用低功耗方式，只有收到网关侧的拾音通知后，才开始拾音。
在本申请实施例中，语音协同唤醒单元向目标唤醒平台发送唤醒指令，唤醒指令用于唤醒目标唤醒平台，以使目标唤醒平台执行拾音操作。
网络设备向目标唤醒平台发送唤醒指令，目标唤醒平台接收到唤醒指令后，执行拾音操作。
采用以下公式计算协同唤醒清单中各平台的唤醒判别值：
其中，K代表语音协同唤醒单元中需做唤醒判别的平台数目，Qj代表音量分贝值，即协同唤醒清单中各平台所采集到的唤醒语音信息的强度，a、b代表预设的唤醒判别参数，Pj代表协同唤醒清单中各平台所在位置与唤醒语音信息的朝向的相似度。
计算协同唤醒清单中各平台的端侧唤醒判别值之后，确定协同唤醒清单中各平台的唤醒判别值中的最大值，若最大值大于等于预设阈值，则将最大值对应的平台确定为目标唤醒平台。
可以理解，若端侧唤醒判别计算出的协同唤醒清单中各平台的端侧唤醒判别值中的最大值都小于预设阈值，则表示端侧唤醒无法判断出目标唤醒平台，则需要启动云端侧唤醒判别。
其中，云端侧唤醒判别是指通过云服务器进行唤醒判别，云端侧唤醒判别方案适用性强，判别准确性高。
可以理解，网络设备向云服务器发送唤醒判别请求消息，云服务器接收网络设备发送的唤醒判别请求消息，唤醒判别请求消息中携带协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息；云服务器向协同唤醒清单中的各平台下发唤醒判别指令，唤醒判别指令用于指示协同唤醒清单中的各平台上报通过拾音获得的音频流信息；云服务器根据协同唤醒清单中各平台上报的音
频流信息以及协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，确定目标唤醒平台。
可以理解的是，在确定出目标唤醒平台之后，本申请实施例提供判别方式纠正能力，即通过唤醒后拾音效果、平台功能情况判断该平台是否继续拾音。
具体地，网络设备接收目标唤醒平台发送的通过拾音获得的服务请求语音信息，计算目标唤醒平台的唤醒判别值；
若目标唤醒平台的唤醒判别值大于等于预设阈值，则执行与服务请求语音信息对应的处理操作，例如，播放音乐，打电话，打开视频软件等。
若目标唤醒平台的唤醒判别值小于预设阈值，则启动云端侧唤醒判别，以重新确定目标唤醒平台。
网络设备向云服务器发送唤醒判别请求消息，唤醒判别请求消息中携带服务请求语音信息、协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息；云服务器根据服务请求语音信息、协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，重新确定目标唤醒平台。
云端判别特点是各待接入平台在开始时需要共同拾音上报云服务器，云服务器会综合音频采集情况、端侧自身能力、端侧算力提供综合评判结果，评判算法如下：
其中，K代表语音协同唤醒单元中需做唤醒判别的平台数目，sj代表端侧自身能力（音视频播报、通话等等）跟语义解析结果的匹配度，ej代表端侧富裕的算力资源权重，z*代表音频采集的质量，a、b代表协同唤醒纠偏参数，Tj代表音频信噪比。
云服务器通过上述方法计算每个终端的协同唤醒判别值指标，选择具体进行协同唤醒的待接入平台，并下发唤醒指令，执行后续唤醒操作。云端判别由于功耗大、响应慢，所以仅仅当端侧唤醒判别值达不到要求时才会开启
在一些实施例中，唤醒判别请求消息中还携带服务请求语音信息；云服务器接收网络设备发送的唤醒判别请求消息之后，方法还包括:
云服务器根据服务请求语音信息、协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，重新确定目标唤醒平台。
对于云服务器进行唤醒判别的具体步骤，可以参考前述待接入平台和网络设备的协同唤醒方法实施例中的描述，在此不再赘述。
进一步地，图8是本申请实施例中提供的基于泛在联接的多协议智慧园区管控平台的结构示意图之五，多协议智慧园区管控平台还包括云接入网关，管控平台中台与云接入网关连接，对云接入网关进行管理。
在本申请实施例中，云接入网关用于对每个待接入平台随机生成的字符串进行加密，得到通信秘钥；将通信秘钥添加至SPA数据包，并将SPA数据包发送至管控平台中台；基于发送的SPA数据包添加第一过滤规则；向管控平台中台发送TCP连接请求；TCP连接请求通过第一过滤规则生成签名；当管控平台中台验证签名成功时，建立每个待接入平台与负载均衡器之间的安全连接通道，具体流程包括：
云接入网关和管控平台中台是基于SDP（Software-Defined Perimeter，软件定义边界）技术进行通信的设备。
请参阅图9，图9是本申请实施例中提供的云接入网关架构的示意图。云网关包括socks5代理和加速pop点。在云接入网关（Cloud Gateway，CG）架构中，待接入平台通过socks5协议连接到服务端，连接建立后，将加密数据发送到加速pop点，进一步经加速链路发送到业务服务器。其中，socks5协议是基于ss5协议over tcp/ip得到的。
在该架构中，业务数据在socks5协议层进行了加密传输，保证了数据在传输过程中的安全性。然而，socks5协议工作在开放的TCP层之上，业务数据加密是在TCP连接建立之后进行的，该交互方式容易受到SYN Flood、IP欺骗、TCP重置攻击等针对TCP/IP协议的攻击。
因此，本申请实施例可以利用SDP技术中的单包授权（Single PacketAuthorization，SPA）技术，在TCP连接建立之前进行安全认证。
云接入网关和管控平台中台的交互具体流程包括：
0、初始状态：开启ssh服务，拒绝所有发往22端口的数据包。
1、发送SPA数据包，待接入平台ip=1.1.1.1。
2、SPA数据包校验通过，添加rule1：接收src_ip=1.1.1.1 and dst_port=22的数据包。
3、向22端口发起TCP连接请求。
4、根据rule1接收连接请求。
5、30s后删除rule1。
流程说明：管控平台中台默认拒绝任何连接，以防止端口扫描。云接入网关与管控平台中台建立连接之前，发送一个加密的SPA数据包给管控平台中台，然后再发送TCP连接请求；管控平台中台收到SPA数据包之后，向Iptables过滤系统中添加规则rule，rule包括两条规则rule1和rule2，rule2指定阻断所有到达指定端口的流量，rule1指定对已经连接的指定端口流量作放行。
示例性地，SPA数据包格式如表2：
字段 描述
待接入平台ID 32位标识符，用于唯一标识一个待接入平台，该字段是可选的。
随机数 16位随机数据字段，通过避免SPA数据包重用从而防止重放攻击。
时间戳 通过报文有效期（例如15~30秒）防止过时的SPA数据包被认证。
源IP地址 因为报文头中的IP地址很容易被修改，所以发送者的IP地址应该包含在数据报文中，以便服务器不依赖于报文头中的源IP地址。
消息类型 该字段是可选的，用于通知服务器在建立连接后可能收到什么类型的消息。
消息字符串 该字段是可选的，内容取决于消息类型字段。例如，如果在建立连接时知道后续的服务，此字段可用于指定发送者制定连接建立后的服务。
HOTP 由诸如RFC 4226等算法基于共享秘密生成的一次性密码。SPA数据包中使用HOTP以确保其真实性。
Counter 计数器是一个64位无符号整数，用于通信者之间的同步。详细信息可参考RFC 4226。
HMAC 报文签名。
云接入网关在发送SPA数据包时，通过共享密钥和随机数，经过基于RFC4266定义的HOTP（HMAC-based One-Time Password）算法计算出SPA密钥，与终端标识、随机数、时间戳（日期、小时、分钟）、待接入平台IP（UDP报头内）、端口一起打包成UDP数据包发送到管控平台中台指定敲门端口。管控平台中台根据接收到UDP报头中的时间戳、云接入网关IP以及管控平台中台内部存储的服务密码计算出SPA密钥，并将SPA密钥与接收到的哈希值进行对比，如果相同，管控平台中台则为云接入网关在预设时间（例如30秒内）打开申请访问的服务端口。此外，管控平台中台将记录它收到的最后一个有效授权的数据包，以防止重放攻击。
SPA协议在连接发起之前实现待接入平台的认证，能够有效防止端口扫描，提高了网络连接过程中的安全性。然而，该协议仅能实现类似于“端口敲门”的功能，并不能保证整个TCP连接建立过程的安全性。
下面举例说明SPA的安全性缺陷。当攻击者与被攻击者在同一个NAT网络之后，在合法的待接入平台认证成功后，服务端开发的30s内，攻击者发起连接请求，则同样会被接受，即同一SNAT网络中待接入平台可以越权访问。
TCP连接被攻击的具体流程如下：
0、管控平台中台初始状态：开启ssh服务拒绝所有发往22端口的数据包。
1、云接入网关发送SPA数据包，待接入平台ip=1.1.1.1。
2、管控平台中台校验SPA数据包通过，添加rule1：接收src_ip=1.1.1.1 and dst_port=22的数据包。
3、云接入网关向22端口发起TCP连接请求。
4、管控平台中台根据rule1接收来自云接入网关的连接请求。
5、攻击者向22端口发起TCP连接请求。
6、管控平台中台根据rule1接收来自攻击者的连接请求。
7、攻击者能够访问管控平台中台的服务。
基于这个问题，相关技术中也给出了不同的解决方案，比如在连接到具体网关时进行二次认证，通过多次交互以建立连接，以及在连接建立后对业务数据进行验证等等。然而，这些方案都是在连接建立前或建立后通过增加的机制来对待接入平台进行多次认证，降低被攻击的风险，并没有试图在连接过程中对数据和资源进行保护，因此并没有从根本上解决问题。
而在本实施例中，可以对已有SPA协议进行扩展，在TCP连接建立过程中，增加了数据的合法性校验，使得攻击者无法在端口开放期间伪造TCP连接请求，有效防止TCP请求伪造，TCP重置等攻击。
具体地，在SPA数据包中增加一个通信秘钥TrafficKey，对其进行加密传输，修改后的SPA数据包格式如表3所示：
字段 描述
待接入平台ID 32位标识符，用于唯一标识一个待接入平台，该字段是可选的。
随机数 16位随机数据字段，通过避免SPA数据包重用从而防止重放攻击。
时间戳 通过报文有效期（例如15~30秒）防止过时的SPA数据包被认证。
源IP地址 因为报文头中的IP地址很容易被修改，所以发送者的IP地址应该包含在数据报文中，以便服务器不依赖于报文头中的源IP地址。
消息类型 该字段是可选的，用于通知服务器在建立连接后可能收到什么类型的消息。
消息字符串 该字段是可选的，内容取决于消息类型字段。例如，如果在建立连接时知道后续的服务，此字段可用于指定发送者制定连接建立后的服务。
HOTP 由诸如RFC 4226等算法基于共享秘密生成的一次性密码。SPA数据包中使用HOTP以确保其真实性。
Counter 计数器是一个64位无符号整数，用于通信者之间的同步。详细信息可参考RFC 4226。
TrafficKey 通信秘钥，加密形式
HMAC 报文签名。
云接入网关基于SPA数据包中的通信秘钥可以生成第一过滤规则，第一过滤规则用于在云接入网关向管控平台中台发送TCP连接请求时，对携带的TCP报文进行签名，从而生成安全连接的凭证。当管控平台中台验证签名成功时，云接入网关和管控平台中台才能建立安全连接通道。
综上，本实施例通过在SPA数据包中加入通信秘钥，并且结合签名验证的方式对TCP连接请求进行验证，在TCP连接建立过程中引入认证机制，增加了数据的合法性校验，从而保证了TCP连接过程的安全性。
需要说明的是，通信秘钥TrafficKey在每次连接建立前都会重新生成。
TCP报文包括自定义的options字段。options字段的最大长度为40字节，支持多个预定义的选项，其中包括TCP-MD5和TCP-AO报文，用于对数据的完整性进行验证，但由于存在安全性问题，因此本方案没有复用这两个选项，而是新增了一个自定义选项，用于实现更安全的认证。
TCP报文的options字段中包括了1字节的“Kind=30”、2字节的“random”和16字节的“sign”（相当于本实施例通过第一过滤规则生成的签名，即TCP报文签名）。
其中kind=30指定了选项类型，random为二字节的随机字符串。
在一些实施例中，sign的计算方法为：
sign=f(源IP+源端口+目的IP+目的端口+TCP数据+random, TrafficKey)
其中f为签名算法，可以是HMAC，也可以是带盐值的SHA256以及其他签名算法；
对于SYN报文，其TCP数据为空，源IP、源端口、目的IP、目的端口相对固定，但由于random参与了签名，因此即使TrafficKey相同，每个SYN报文计算出来的的签名也是不相同的，这样就可以防止攻击者通过收集大量SYN报文发送字典攻击。
安全连接通道可以为TLS通道或者IPSEC通道。
TLS通道是基于TLS协议（TransportLayerSecurity，安全传输层协议）进行数据传输的通道。其中TLS协议由两层组成：TLS记录协议（TLSRecord）和TLS握手协议（TLSHandshake）。
IPSEC通道是基于IPSEC协议（InternetProtocolSecurity，互联网安全协议）进行数据传输的通道。IPSEC协议是一个协议包，通过对IP协议的分组进行加密和认证来保护IP协议的网络传输协议簇（一些相互关联的协议的集合）。
在一个实施例中，当管控平台中台验证签名成功时，与管控平台中台建立安全连接通道的步骤，具体可以包括：
当管控平台中台验证签名成功时，与管控平台中台建立TLS通道；其中TLS通道用于数据的加密传输；在建立TLS通道之后，删除第一过滤规则。
云接入网关可以对连接状态进行检测，在TLS连接建立后，通信双方传输的数据都被加密，攻击者无法通过抓包获取到报文内容，此时虽然云接入网关发送的报文不再进行签名校验，其数据也是安全的；当双方建立了安全的TLS通道时，云接入网关可以删除第一过滤规则。
在一个实施例中，对随机生成的字符串进行加密，得到通信秘钥的步骤，具体可以包括：
0、初始状态：开启ssh服务，拒绝所有发往22端口的数据包。
本实施例以ssh服务的访问为例，对流程进行说明。在开始时，管控平台中台处于初始状态。在初始状态下，管控平台中台开启ssh服务，拒绝所有发往22端口的数据包。
1、发送SPA数据包，内容包括加密后的TrafficKey。
云接入网关封装SPA数据包时，随机生成一个字符串并对其加密后得到通信秘钥TrafficKey，通信秘钥TrafficKey添加到在SPA数据包中。
其中，通信秘钥TrafficKey的加密密钥与计算HOTP时的密钥相同，该秘钥可以由管控平台中台通过安全渠道预先分配给云接入网关。
2、添加规则client_rule。
云接入网关守护进程添加数据包过滤规则，即第一过滤规则client_rule，对发往指定IP和端口的数据进行签名计算，结果放在TCP报文的options字段中。
3、SPA数据包校验通过，解密得到TrafficKey。
管控平台中台守护进程对SPA数据包进行校验，校验通过后，使用预置的秘钥对通信秘钥TrafficKey进行解密，得到明文。
4、添加server_rule：校验来源ip和签名。
管控平台中台增加数据包过滤规则，即第二过滤规则server_rule，第二过滤规则server_rule可以接受特定源IP，并且签名正确的数据包。
5、向22端口发起TCP连接请求，经过client_rule时，生成签名并放在options中。
云接入网关向管控平台中台发起TCP连接请求，经过守护进程时，可以使用通信秘钥TrafficKey对TCP报文内容进行签名，签名结果放在options字段中。
6、根据server_rule校验签名成功，放行数据包。
管控平台中台守护进程对TCP报文进行签名校验，如果签名正确，则接收，否则丢弃。
7、建立安全的TLS连接。
云接入网关与管控平台中台在TCP连接的基础上建立TLS通道，后续数据进行加密传输。
8、30s后删除规则server_rule，不接受新的连接。
管控平台中台在30s后，删除第二过滤规则server_rule。此时，管控平台中台可以接受连接状态为ESTABLISHED的数据包，但拒绝其他数据包。
9、35s后删除规则client_rule。
云接入网关在35s后，删除第一过滤规则client_rule。
10、通过TLS连接安全地传输数据。
在TLS连接建立后，管控平台中台和云接入网关之间传输的数据都被加密，攻击者无法通过抓包获取到报文内容，此时虽然云接入网关发送的报文不再进行签名校验，其数据也是安全的。
上述流程以TLS通道为例对方案进行说明，对于IPSec协议，本方案仍然适用。云接入网关的第一过滤规则和管控平台中台的第二过滤规则的持续时间为可配置的，通信接口也是可配置的。
其中，云接入网关的第一过滤规则的配置时间总是比管控平台中台的第二过滤规则的配置时间长，这样能够保证安全通道建立完成后再删除规则。
此外，如果由于网络原因，导致建立安全通道的时间过长，可以增加规则的持续时间。
下面对本申请实施例提供的多协议智慧园区管控方法进行描述，下文描述的多协议智慧园区管控方法与上文描述的基于泛在联接的多协议智慧园区管控平台可相互对应参照。图10是本申请实施例提供的多协议智慧园区管控方法的流程示意图，如图10所示，该方法包括：
步骤101，基于第一公网IP地址，获取每个待接入平台对应的目标网址；
步骤102，在所述目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将所述目标网址发送至所述NAT网关；
步骤103，将所述目标网址发送至所述智慧园区管控内网中的路由器；
步骤104，将所述目标网址与所述智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定所述目标网址对应的目标业务服务器；
步骤105，将所述目标网址发送至所述目标业务服务器，以将每个所述待接入平台连接至所述多协议智慧园区管控平台。
具体的，待接入平台可以在浏览器中输入目标业务服务器对应的目标网址，第一公网IP地址用于将包括目标网址的HTTP（Hypertext Transfer Protocol，超文本传输协议）请求路由至负载均衡器。该HTTP请求中包括目标业务服务器对应的目标网址，该目标网址可以包括协议、主机名（IP地址）、端口号和URL（Uniform Resource Locator，统一资源定位器）路径等信息。
可选的，该协议可以包括HTTP协议或HTTPS（Hypertext Transfer ProtocolSecure，超文本传输安全协议）协议，本申请实施例对此不做限制。
具体的，负载均衡器在获取到待接入平台对应的目标网址后，提取该目标网址中的主机名（IP地址），遍历各第一业务服务器的IP地址，并将该主机名（IP地址）与各第一业务服务器的IP地址进行匹配，若该主机名与其中一个第一业务服务器的IP地址匹配，表明该待接入平台希望访问的目标业务服务器为云服务器中的第一业务服务器，此时，可将该HTTP请求转发至该目标业务服务器，在该目标业务服务器对该HTTP请求处理后，向负载均衡器返回响应内容，并由负载均衡器将响应内容转发至浏览器，并在浏览器显示该响应内容。若该主机名与各第一业务服务器的IP地址均不匹配时，可从至少一个第一业务服务器中选择空闲的第一业务服务器，并将HTTP请求先发送该空闲的第一业务服务器，并由该空闲的第一业务服务器将该HTTP请求转发至NAT网关。此外，负载均衡器在进行匹配时，还可提取目标网址中的URL路径与各第一业务服务器的URL路径进行匹配，在匹配时，可根据URL路径中的参数或使用正则表达式进行匹配，本申请实施例对此不做限制。
在负载均衡器将目标网址与各第一业务服务器进行匹配时，可采用轮询、随机、加权轮询等算法确定待匹配的第一业务服务器，对此不做限制。
具体的，在NAT网关接收到该目标网址后，可将该目标网址发送至智慧园区管控内网，以确定待接入平台希望访问的目标业务服务器，实现对智慧园区管控内网中该目标业务服务器的访问。
具体的，NAT网关在接收到目标网址后，可将该目标网址发送至智慧园区管控内网中的路由器，路由器可通过查询路由表，根据目标网址和路由表中各第二业务服务器对应的网络地址和子网掩码进行匹配，进而从路由表中确定目标业务服务器，若该目标业务服务器与路由器直接连接，可将待接入平台对应的HTTP请求直接发送至该目标业务服务器。若该目标业务服务器与路由器间接连接，则路由器可根据各第二业务服务器对应的路由度量值，确定路由器至该目标业务服务器之间的最优路径。在确定最优路径后，路由器可将该HTTP请求先发送至最优路径中的首个节点，并根据该首个节点的下一跳地址将该HTTP请求发送至下一个节点，重复执行发送操作，直至发送至目标业务服务器时停止发送操作。
可选的，该路由度量值可以包括：带宽、延迟、经过节点数、路径成本、负载、传输成本和可靠性等，本申请实施例对此不做限制。此外，在该目标业务服务器接收到HTTP请求后，对该HTTP请求进行处理，确定响应内容，并沿原始路径将该响应内容转发至浏览器，以在浏览器中显示该响应内容。
本申请实施例通过云服务器中部署的负载均衡器的第一公网IP地址，获取待接入平台对应的目标网址，并由负载均衡器将该目标网址与各第一业务服务器对应的网址进行匹配，在该目标网址与各第一业务服务器对应的网址均不匹配的情况下，通过各第一业务服务器将该目标网址发送至NAT网关，避免各第一业务服务器配置公网IP地址以浪费较多的公网IP资源，降低各第一业务服务器被非法访问的概率和系统运维复杂度，且在NAT网关接收到目标网址后，将该目标网址发送至智慧园区管控内网中的路由器，并由路由器将该目标网址转发至目标业务服务器，确保将该目标网址的高效传输，进而提高待接入平台访问智慧园区管控内网的效率。
本申请提供的多协议智慧园区管控方法的具体实施例与基于泛在联接的多协议智慧园区管控平台各实施例基本相同，在此不作赘述。
以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种基于泛在联接的多协议智慧园区管控平台，其特征在于，所述多协议智慧园区管控平台包括管控平台中台、云服务器和智慧园区管控内网；所述管控平台中台与所述智慧园区管控内网连接，对所述智慧园区管控内网进行管理；所述云服务器包括负载均衡器、至少一个第一业务服务器和NAT网关；
所述负载均衡器上配置第一公网IP地址，且所述负载均衡器基于第一公网IP地址与各所述第一业务服务器通信连接；所述NAT网关分别与各所述第一业务服务器和所述智慧园区管控内网通信连接，所述NAT网关用于在所述云服务器与所述智慧园区管控内网之间进行IP地址转换，实现所述云服务器与所述智慧园区管控内网的互联；
所述负载均衡器上配置第一防火墙规则和安全套接层SSL证书；所述NAT网关上配置有第二公网IP地址和第二防火墙规则，各所述第一业务服务器用于基于所述第二公网IP地址访问公网；所述智慧园区管控内网包括路由器和至少一个第二业务服务器，所述路由器分别与各所述第二业务服务器和所述NAT网关通信连接；所述路由器上配置所述第二公网IP地址对应的第二防火墙规则和出口IP地址，各所述第二业务服务器用于基于所述出口IP地址访问所述公网；
所述负载均衡器用于：基于第一公网IP地址，获取每个待接入平台对应的目标网址；在所述目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将所述目标网址发送至所述NAT网关；
所述NAT网关用于：将所述目标网址发送至所述智慧园区管控内网中的路由器；将所述目标网址与所述智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定所述目标网址对应的目标业务服务器；将所述目标网址发送至所述目标业务服务器，以将每个所述待接入平台连接至所述多协议智慧园区管控平台。
2.根据权利要求1所述的多协议智慧园区管控平台，其特征在于，所述多协议智慧园区管控平台还包括策略路由单元；所述管控平台中台与所述策略路由单元连接，对所述策略路由单元进行管理；
所述策略路由单元用于：基于待接入平台数据和策略数据库，进行策略匹配；所述策略数据库包括多条策略，各所述策略包括多个动作；基于匹配结果，生成标记位图；所述标记位图中的一个比特位对应一个动作；基于所述标记位图，执行相应的动作。
3.根据权利要求2所述的多协议智慧园区管控平台，其特征在于，所述基于匹配结果，生成标记位图，包括：
对所述待接入平台数据配置的动作，将对应的比特位置作为第一标记；或，若选择出的策略的匹配模式为拒绝通过，或所述策略数据库中没有与所述待接入平台数据相匹配的策略，则将所述标记位图的最高位置作为第一标记；
对所述待接入平台数据未配置的动作，将对应的比特位置作为第二标记；或，若选择出的策略的匹配模式为允许通过，则将所述标记位图的最高位置作为第二标记；
相应地，所述基于所述标记位图，执行相应的动作，包括：
各动作节点分别读取所述标记位图中对应的比特位的值；
若所述动作节点读取到的值为第一标记，则所述动作节点基于预设步骤进行数据处理；或，若所述动作节点读取到的值为第二标记，则所述动作节点不执行所述预设步骤。
4.根据权利要求1所述的多协议智慧园区管控平台，其特征在于，所述多协议智慧园区管控平台还包括语音协同唤醒单元；所述管控平台中台与所述语音协同唤醒单元连接，对所述语音协同唤醒单元进行管理；
所述语音协同唤醒单元用于：接收每个所述待接入平台发送的协同唤醒请求消息，将所述每个所述待接入平台加入至协同唤醒清单；所述协同唤醒清单中的不同平台通过预设的统一唤醒词唤醒；向所述每个所述待接入平台发送协同唤醒请求响应消息，所述协同唤醒请求响应消息中携带所述统一唤醒词；接收待接入平台的唤醒语音信息，对所述唤醒语音信息进行语音识别，在所述唤醒语音信息与所述统一唤醒词匹配的情况下，通过端侧唤醒判别定位目标唤醒平台；向所述目标唤醒平台发送唤醒指令，所述唤醒指令用于唤醒所述目标唤醒平台，以使所述目标唤醒平台执行拾音操作。
5.根据权利要求4所述的多协议智慧园区管控平台，其特征在于，所述通过端侧唤醒判别定位目标唤醒平台，包括：
计算所述协同唤醒清单中各平台所在位置与所述唤醒语音信息的朝向的相似度；
获取所述协同唤醒清单中各平台所采集到的所述唤醒语音信息的强度；
根据所述相似度和强度以及预设的唤醒判别参数，计算得到所述协同唤醒清单中各平台的唤醒判别值；
确定所述协同唤醒清单中各平台的唤醒判别值中的最大值；
若所述最大值大于等于预设阈值，则将所述最大值对应的平台确定为所述目标唤醒平台。
6.根据权利要求5所述的多协议智慧园区管控平台，其特征在于，还包括：
若所述最大值小于所述预设阈值，则向所述管控平台中台发送唤醒判别请求消息；所述唤醒判别请求消息中携带所述协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，以使得所述管控平台中台根据所述各平台的位置信息、能力信息和唤醒优先级信息，确定所述目标唤醒平台。
7.根据权利要求4所述的多协议智慧园区管控平台，其特征在于，还包括：
接收所述目标唤醒平台发送的通过拾音获得的服务请求语音信息，计算所述目标唤醒平台的唤醒判别值；
若所述目标唤醒平台的唤醒判别值大于等于预设阈值，则执行与所述服务请求语音信息对应的处理操作；或，
若所述目标唤醒平台的唤醒判别值小于预设阈值，则向所述管控平台中台发送唤醒判别请求消息；所述唤醒判别请求消息中携带所述服务请求语音信息、所述协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，以使得所述管控平台中台根据所述服务请求语音信息、所述协同唤醒清单中各平台的位置信息、能力信息和唤醒优先级信息，重新确定所述目标唤醒平台。
8.根据权利要求1所述的多协议智慧园区管控平台，其特征在于，所述多协议智慧园区管控平台还包括云接入网关；所述管控平台中台与所述云接入网关连接，对所述云接入网关进行管理；
所述云接入网关用于：对每个所述待接入平台随机生成的字符串进行加密，得到通信秘钥；将所述通信秘钥添加至SPA数据包，并将所述SPA数据包发送至管控平台中台；基于发送的SPA数据包添加第一过滤规则；向所述管控平台中台发送TCP连接请求；所述TCP连接请求通过所述第一过滤规则生成签名；当所述管控平台中台验证所述签名成功时，建立每个所述待接入平台与所述管控平台中台之间的安全连接通道。
9.根据权利要求8所述的多协议智慧园区管控平台，其特征在于，所述向所述管控平台中台发送TCP连接请求，包括：
基于所述TCP连接请求生成TCP报文；
基于源IP、源端口、目的IP、目的端口、TCP数据、随机数和所述通信秘钥对所述TCP报文进行签名；所述签名位于所述TCP报文的options字段中；
将所述TCP报文发送至所述管控平台中台。
10.一种多协议智慧园区管控方法，其特征在于，应用于权利要求1至9任一项所述的基于泛在联接的多协议智慧园区管控平台，包括：
基于第一公网IP地址，获取每个待接入平台对应的目标网址；
在所述目标网址与至少一个第一业务服务器对应的网址均不匹配的情况下，将所述目标网址发送至所述NAT网关；
将所述目标网址发送至所述智慧园区管控内网中的路由器；
将所述目标网址与所述智慧园区管控内网中至少一个第二业务服务器对应的网址进行匹配，确定所述目标网址对应的目标业务服务器；
将所述目标网址发送至所述目标业务服务器，以将每个所述待接入平台连接至所述多协议智慧园区管控平台。
CN202410029790.XA 2024-01-09 2024-01-09 基于泛在联接的多协议智慧园区管控平台 Active CN117544424B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410029790.XA CN117544424B (zh) 2024-01-09 2024-01-09 基于泛在联接的多协议智慧园区管控平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410029790.XA CN117544424B (zh) 2024-01-09 2024-01-09 基于泛在联接的多协议智慧园区管控平台

Publications (2)

Publication Number Publication Date
CN117544424A true CN117544424A (zh) 2024-02-09
CN117544424B CN117544424B (zh) 2024-03-15

Family

ID=89790378

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410029790.XA Active CN117544424B (zh) 2024-01-09 2024-01-09 基于泛在联接的多协议智慧园区管控平台

Country Status (1)

Country Link
CN (1) CN117544424B (zh)

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101984623A (zh) * 2010-11-02 2011-03-09 北京天融信科技有限公司 防火墙网络地址转换动态负载均衡方法及装置
US20120117571A1 (en) * 2010-11-05 2012-05-10 Adam Davis Load balancer and firewall self-provisioning system
US20150341428A1 (en) * 2014-05-20 2015-11-26 Citrix Systems, Inc. Systems and methods for providing load balancing as a service
CN107733991A (zh) * 2017-09-19 2018-02-23 大唐网络有限公司 一种基于OpenStack架构提供负载均衡服务实现方法
CN109032760A (zh) * 2018-08-01 2018-12-18 北京百度网讯科技有限公司 用于部署应用的方法和装置
CN109361768A (zh) * 2018-12-07 2019-02-19 居丽芳生态科技(上海)有限公司 一种基于物联网的智能植物种植管理平台
CN109743415A (zh) * 2019-02-27 2019-05-10 上海浪潮云计算服务有限公司 一种公有云网络弹性ip实现方法及系统
CN110266822A (zh) * 2019-07-23 2019-09-20 浪潮云信息技术有限公司 一种基于nginx的共享式负载均衡实现方法
CN111327720A (zh) * 2020-02-21 2020-06-23 北京百度网讯科技有限公司 一种网络地址转换方法、装置、网关设备及存储介质
CN111638957A (zh) * 2020-06-01 2020-09-08 山东汇贸电子口岸有限公司 一种集群共享式公有云负载均衡的实现方法
CN111866064A (zh) * 2016-12-29 2020-10-30 华为技术有限公司 一种负载均衡的方法、装置和系统
CN112671628A (zh) * 2019-10-15 2021-04-16 华为技术有限公司 业务服务提供方法及系统
CN113225409A (zh) * 2021-05-27 2021-08-06 北京天融信网络安全技术有限公司 一种nat负载均衡访问方法、装置及存储介质
CN114971954A (zh) * 2021-11-18 2022-08-30 广东轻工职业技术学院 一种一体化智慧校园中台架构
CN115665049A (zh) * 2022-10-11 2023-01-31 浪潮云信息技术股份公司 一种云平台针对多活负载均衡分配权重的方法
CN116418595A (zh) * 2023-04-28 2023-07-11 广发银行股份有限公司 访问Web服务器的安全验证系统及安全验证方法
CN117255089A (zh) * 2023-09-26 2023-12-19 中国联合网络通信集团有限公司 容器网络系统及其使用方法

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101984623A (zh) * 2010-11-02 2011-03-09 北京天融信科技有限公司 防火墙网络地址转换动态负载均衡方法及装置
US20120117571A1 (en) * 2010-11-05 2012-05-10 Adam Davis Load balancer and firewall self-provisioning system
US20150341428A1 (en) * 2014-05-20 2015-11-26 Citrix Systems, Inc. Systems and methods for providing load balancing as a service
CN111866064A (zh) * 2016-12-29 2020-10-30 华为技术有限公司 一种负载均衡的方法、装置和系统
CN107733991A (zh) * 2017-09-19 2018-02-23 大唐网络有限公司 一种基于OpenStack架构提供负载均衡服务实现方法
CN109032760A (zh) * 2018-08-01 2018-12-18 北京百度网讯科技有限公司 用于部署应用的方法和装置
CN109361768A (zh) * 2018-12-07 2019-02-19 居丽芳生态科技(上海)有限公司 一种基于物联网的智能植物种植管理平台
CN109743415A (zh) * 2019-02-27 2019-05-10 上海浪潮云计算服务有限公司 一种公有云网络弹性ip实现方法及系统
CN110266822A (zh) * 2019-07-23 2019-09-20 浪潮云信息技术有限公司 一种基于nginx的共享式负载均衡实现方法
CN112671628A (zh) * 2019-10-15 2021-04-16 华为技术有限公司 业务服务提供方法及系统
CN111327720A (zh) * 2020-02-21 2020-06-23 北京百度网讯科技有限公司 一种网络地址转换方法、装置、网关设备及存储介质
CN111638957A (zh) * 2020-06-01 2020-09-08 山东汇贸电子口岸有限公司 一种集群共享式公有云负载均衡的实现方法
CN113225409A (zh) * 2021-05-27 2021-08-06 北京天融信网络安全技术有限公司 一种nat负载均衡访问方法、装置及存储介质
CN114971954A (zh) * 2021-11-18 2022-08-30 广东轻工职业技术学院 一种一体化智慧校园中台架构
CN115665049A (zh) * 2022-10-11 2023-01-31 浪潮云信息技术股份公司 一种云平台针对多活负载均衡分配权重的方法
CN116418595A (zh) * 2023-04-28 2023-07-11 广发银行股份有限公司 访问Web服务器的安全验证系统及安全验证方法
CN117255089A (zh) * 2023-09-26 2023-12-19 中国联合网络通信集团有限公司 容器网络系统及其使用方法

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
单庆元;南峰;: "基于PROXY-ARP和智能DNS的校园内网服务器双线访问技术研究", 中国教育信息化, no. 08, 10 April 2016 (2016-04-10) *
宋晓辉;陈康骏;: "校园网出口双向多链路负载均衡策略分析", 科协论坛(下半月), no. 12, 25 December 2011 (2011-12-25) *
李勇: "高校服务器集群负载均衡在模拟器中的实验仿真", 曲 靖 师 范 学 院 学 报, 30 November 2020 (2020-11-30) *
杨礼;刘静;古丽孜热・艾尼外;: "基于防火墙的园区网设计与仿真", 新疆师范大学学报(自然科学版), no. 02, 10 October 2020 (2020-10-10) *
陈晔;: "论校园网出口链路改造的必要性及改造方案研究", 信息通信, no. 06, 15 June 2020 (2020-06-15) *
陈松;战学刚;: "基于双向NAT和智能DNS内网服务器安全快速访问策略", 计算机工程与设计, no. 12, 28 June 2009 (2009-06-28) *
鞠洪尧;: "数字化校园网络架构优化与实现策略研究", 齐齐哈尔大学学报(自然科学版), no. 01, 15 January 2010 (2010-01-15) *

Also Published As

Publication number Publication date
CN117544424B (zh) 2024-03-15

Similar Documents

Publication Publication Date Title
US7823194B2 (en) System and methods for identification and tracking of user and/or source initiating communication in a computer network
EP3142327B1 (en) Intermediate network entity
Ahmed et al. IPv6 neighbor discovery protocol specifications, threats and countermeasures: a survey
EP1583318B1 (en) Signing and validating session initiation protocol routing headers
US10277576B1 (en) Diameter end-to-end security with a multiway handshake
CA2506418C (en) Systems and apparatuses using identification data in network communication
CN112615866B (zh) Tcp连接的预认证方法、装置和系统
CN111565389A (zh) 节点管理方法、装置、设备及存储介质
CN112954683A (zh) 域名解析方法、装置、电子设备和存储介质
WO2023279782A1 (zh) 一种访问控制方法、访问控制系统及相关设备
CN113904826B (zh) 数据传输方法、装置、设备和存储介质
US20110055571A1 (en) Method and system for preventing lower-layer level attacks in a network
JP4183664B2 (ja) 認証方法、サーバ計算機、クライアント計算機、および、プログラム
KR100856918B1 (ko) ＩＰｖ6 기반 네트워크상에서의 ＩＰ 주소 인증 방법 및ＩＰｖ6 기반 네트워크 시스템
Lagutin Redesigning internet-the packet level authentication architecture
CN117544424B (zh) 基于泛在联接的多协议智慧园区管控平台
JP2011054182A (ja) ディジタルバトンを使用するシステムおよび方法、メッセージを認証するためのファイアウォール、装置、および、コンピュータ読み取り可能な媒体
Yoganguina et al. Proposition of a model for securing the neighbor discovery protocol (NDP) in IPv6 environment
CN113242249B (zh) 一种会话控制方法和设备
JP2008199420A (ja) ゲートウェイ装置および認証処理方法
WO2023109450A1 (zh) 访问控制方法及其相关装置
KR101333305B1 (ko) 안전한 ｔｃｐ 연결 관리 장치 및 방법
Al-Ibrahim et al. Cookie-less browsing
CN113890761A (zh) 一种面向分区操作系统的轻量级安全通信方法及系统
Ababu et al. Survey on IP Spoofing Detection and Prevention

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant