Secure access service edge fusion method and device

Abstract

The invention relates to the technical field of network communication, and provides a secure access service edge fusion method and device. According to the invention, a VXLAN tunnel is constructed between a service cloud gateway and an LAN port of SD-WAN vCPE; the branch terminal sends the original message to the access cloud gateway; the access cloud gateway forwards a first message obtained based on the original message to the service cloud gateway; the service cloud gateway converts the first message into a second message, so that the second message is forwarded to the SD-WAN vCPE through the VXLAN tunnel; and the SD-WAN vCPE processes the received second message to obtain a third message, and forwards the third message to headquarters equipment, so as to transmit the traffic of the branch terminal to the headquarters equipment, thereby solving the problems of low efficiency, high cost and complex configuration of the existing remote networking scheme, or large data transmission quality fluctuation caused by strong dependence on a public network.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a method and apparatus for edge fusion of secure access services. Background Technology

[0002] In existing technologies, there are network data transmission needs for cross-regional interconnection, such as when a branch office of an enterprise accesses the headquarters' intranet. For example, when a branch office accesses resources on the headquarters' intranet, or when the headquarters centrally manages the branch office's equipment, it must access the headquarters' terminals through a metropolitan area network (MAN) or a wide area network (WAN). Employees need to connect to the enterprise's intranet to work remotely, so it is necessary to achieve cross-regional interconnection between the employee's terminal and the intranet.

[0003] To meet the needs of cross-regional interconnection, geographically dispersed networking is often required. Conventional geographically dispersed networking often employs Multi-Protocol Label Switching (MPLS) Virtual Private Networks (VPNs), or Layer 2 Tunneling Protocol (L2TP) or Generic Routing Encapsulation (GRE) via Virtual Local Area Networks (VLANs). However, MPLS-based geographically dispersed networking solutions require label switching, resulting in low efficiency, high cost, and complex configuration. L2TP tunnels require at least one end to have a public IP address, making L2TP-based geographically dispersed networking heavily reliant on the public network for traffic transmission between headquarters and branch offices, highly susceptible to network fluctuations, and unable to guarantee communication quality. Existing geographically dispersed networking solutions have poor practicality.

[0004] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a secure access service edge fusion method and apparatus, which aims to solve the problems of low efficiency, high cost and complex configuration of MPLS VPN remote networking scheme, and the problem of large fluctuations in data transmission quality caused by the strong dependence of virtual LAN remote networking scheme on the public network.

[0006] The present invention adopts the following technical solution: In a first aspect, the present invention provides a secure access service edge fusion method, comprising: Build a VXLAN tunnel between the business cloud gateway and the LAN port of the SD-WAN vCPE; The branch terminal sends the original message to the access cloud gateway; the access cloud gateway forwards the first message obtained based on the original message to the service cloud gateway; The service cloud gateway converts the first packet into a second packet, and forwards the second packet to the SD-WAN vCPE through the VXLAN tunnel; The SD-WAN vCPE processes the received second message to obtain a third message, and forwards the third message to the headquarters equipment to transmit the traffic of the branch terminal to the headquarters equipment.

[0007] Furthermore, the access cloud gateway forwarding the first message obtained based on the original message to the service cloud gateway includes: Obtain the source MAC address and source IP address from the original message; The source MAC address is determined as the destination MAC address, and the source IP address is determined as the destination IP address to generate the first packet; The first message is forwarded to the business cloud gateway.

[0008] Further, the service cloud gateway converts the first packet into a second packet to forward the second packet to the SD-WAN vCPE through the VXLAN tunnel, including: Obtain the QinQ tag on the LAN side of the access cloud gateway carried in the first message; Based on the first message, the QinQ tag is mapped to VNI information on the MEC side to obtain the second message; The second message is forwarded to the LAN port of the SD-WAN vCPE.

[0009] Further, the step of mapping the QinQ tag to VNI information on the MEC side based on the first message to obtain the second message includes: The VXLAN tunnel required by the business cloud gateway is determined according to the QinQ tag. Obtain the VNI information of the VXLAN tunnel; The first message is encapsulated using the VNI information to map the QinQ tag to VNI information on the MEC side, thus obtaining the second message.

[0010] Furthermore, the step of using the VNI information to perform VXLAN encapsulation on the first message also includes: The destination MAC address of the next-hop device is determined to be the LAN port MAC address of the SD-WAN vCPE.

[0011] Furthermore, the SD-WAN vCPE processes the received second message to obtain the third message, including: The WAN port of the SD-WAN vCPE performs NAT based on the second packet to obtain the third packet.

[0012] Furthermore, in the scenario of remote networking, the method also includes: The access cloud gateway receives a broadcast DHCP message from the SD-WAN vCPE side; The access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value; wherein, the Option60 field value is pre-agreed between the branch terminal and the access cloud gateway.

[0013] Furthermore, after the access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value, it also includes: The access cloud gateway learns and records the gateway MAC address and internal link information from the broadcast DHCP message for use in unicast forwarding when the headquarters device accesses the branch terminal.

[0014] Secondly, the present invention also provides a secure access service edge fusion apparatus for implementing the secure access service edge fusion method described in the first aspect, the apparatus comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the secure access service edge fusion method described in the first aspect.

[0015] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the secure access service edge fusion method described in the first aspect.

[0016] Existing technologies for remote networking employ MPLS VPN or L2TP. MPLS requires label switching, resulting in low efficiency and complex configuration; L2TP tunnels require at least one end to have a public IP address. This invention solves these two major problems by using SDWAN VXLAN tunnel networking. It offloads traffic that heavily relies on public network transmission in existing solutions to the business gateway, which then creates an SDWAN VXLAN tunnel between headquarters and branches, connecting the headquarters and branches. This solves the problems of low efficiency, high cost, and complex configuration of MPLS VPN remote networking solutions, as well as the large fluctuations in data transmission quality caused by the heavy reliance on public networks in virtual LAN remote networking solutions. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0018] Figure 1 This is a schematic diagram illustrating a specific example of another prior art network topology provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating a specific example of a prior art network topology provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating a secure access service edge fusion method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a network topology provided in an embodiment of the present invention; Figure 5 This is a flowchart illustrating step 20 provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating a specific example of message conversion provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating a specific example of traffic transmission from a branch terminal to the headquarters, provided by an embodiment of the present invention. Figure 8 This is a flowchart illustrating step 30 provided in an embodiment of the present invention; Figure 9 This is a flowchart illustrating step 302 provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the architecture of a secure access service edge fusion device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In the description of this invention, the terms "inner", "outer", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and do not require that this invention must be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0021] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0022] In this application, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. Furthermore, the term "coupled" can refer to an electrical connection that enables signal transmission.

[0023] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0024] Example 1: The two main existing remote networking schemes are as follows: Option 1: MPLS VPN Networking like Figure 1As shown, the P device (Provider Router) is the core router in the service provider network, responsible for forwarding label-switched packets within the MPLS network, and does not directly connect to the customer network. The PE device (Provider Edge Router) is located at the edge of the service provider network, directly connected to the CE (Customer Edge Router) devices in the customer site, responsible for mapping customer routing information to the VPN routing table and handling label allocation and switching. The CE device is a router at the edge of the customer network, directly connected to the service provider's PE devices, responsible for directing customer network traffic into the MPLS VPN. The Route Distinguisher (RD) is used to distinguish different route prefixes within the same VPN, ensuring that the same IP address from different customers can be correctly routed. For example, RD 2:2 is used to represent a specific VPN instance. The Route Target (RT) controls the import and export of VPN routes; RT 200:1 indicates that the VPN's exported routes carry this RT, and other PE devices will only accept routes with the same RT imported. MPLS is a technology that uses tags to guide the high-speed and efficient transmission of data over open communication networks.

[0025] This solution relies on MPLS VPN networks deployed by local telecom operators to interconnect VPN tunnels between city A and city B (or two or more enterprise branches) through operator-side technical configuration. Typically, such cross-city connections require relaying through provincial network nodes; that is, business traffic must first converge at the provincial company level and then be distributed level by level to the target city. If cross-provincial interconnection is involved, it also needs to traverse the backbone networks of different provinces, making the path even more complex. However, MPLS networks have slow access speeds, especially in cross-border, geographically dispersed networking scenarios, where the quality of access for critical applications is not guaranteed, broadband is expensive, and continuous broadband upgrades are difficult.

[0026] Option 2: L2TP or GRE network via virtual LAN like Figure 2 As shown, this networking scheme requires at least one of the interconnected sites to have a public IP address. A virtual private channel between the two locations can be established by deploying Point-to-Point Tunneling Protocol (PPTP), L2TP, OpenVPN, or Internet Protocol Security (IPsec)-VPN. Among them, L2TP is a link-layer virtual tunneling protocol, and GRE is a network-layer tunneling protocol.

[0027] In this approach, typically one end with a public IP address (e.g., the company headquarters) acts as the server, and the other end (e.g., a branch office) acts as the client. Alternatively, IPsec-VPN can be used to configure a point-to-point tunnel on a router or firewall, enabling direct communication between the two internal networks. L2TP or GRE networks require at least one end to have a public IP address, and their communication stability depends entirely on the transmission quality of the public internet link. They are susceptible to fluctuations in public internet activity, such as network congestion and latency, resulting in poor data transmission quality.

[0028] To solve the above problems, such as Figure 3 As shown, this embodiment of the invention provides a secure access service edge fusion method, including: Step 10: Build a VXLAN tunnel between the business cloud gateway and the LAN port of the SD-WAN vCPE.

[0029] like Figure 4 The diagram illustrates a network topology according to an embodiment of the present invention. In one embodiment, a usage scenario of this invention is: a terminal at a branch office (i.e., company A or company B) with IP address 192.168.71.2 accesses the company headquarters with IP address 10.10.1.254. Using existing technology, traffic from the branch office terminal needs to pass through… Figure 4 The green path in the diagram leads to the enterprise headquarters via the metropolitan area network. When using the edge convergence method for secure access services in this embodiment of the invention, after reaching the business cloud gateway via the red path from the access network cloud gateway, it enters the VXLAN tunnel on the SD-WAN side to reach the SD-WAN vCPE LAN port 192.168.71.254, and then reaches the enterprise headquarters 10.10.1.254 via Layer 3 routing.

[0030] The core of the Software Defined Wide Area Network (SD-WAN) used in this embodiment of the invention is the VXLAN tunnel. VXLAN is a network virtualization technology that encapsulates raw Layer 2 Ethernet frames within User Datagram Protocol (UDP) packets, building a large-scale, scalable virtual Layer 2 network on top of the existing Layer 3 Internet Protocol (IP) network. VXLAN is a network virtualization technology that can improve the scalability issues during the deployment of large-scale cloud computing and is an extension of VLANs. VXLAN is a powerful tool that can extend Layer 2 networks through Layer 3 networks. It can overcome the portability limitations of virtual memory systems by encapsulating traffic and extending it to a Layer 3 gateway, allowing access to servers on external IP subnets. A Virtual Extensible Local Area Network (VXLAN) consists of "VNI + local IP address or peer IP address," and UDP uses a specific destination port 4789.

[0031] In one embodiment, such as Figure 4 As shown, the SD-WAN-based Virtual Customer Premise Equipment (vCPE) uses SD-WAN as the underlying transport protocol, combining with the vCPE to virtualize edge network functions. Each service cloud gateway transmits data with the SD-WAN vCPE's Local Area Network (LAN) port through a corresponding VXLAN tunnel. Each VXLAN tunnel corresponds to a VXLAN Network Identifier (VNI); the VNI is primarily used for tenant isolation and offers strong scalability. Figure 4 The VXLAN tunnel between the service cloud gateway and the LAN port of the SD-WAN vCPE has a VXLAN Tunnel End Point (VTEP) of 182.129.11.3 on the SD-WAN vCPE side and a VTEP of 182.129.10.3 on the service cloud gateway side.

[0032] This invention is based on SD-WAN tunnel optimization technology: it uses the UDP protocol to carry TCP traffic, avoiding the performance degradation caused by traditional TCP congestion control algorithms in cross-border environments. In an optional embodiment, data compression and deduplication technologies can be combined to effectively improve the transmission efficiency of the payload.

[0033] Step 20: The branch terminal sends the original message to the access cloud gateway; the access cloud gateway forwards the first message obtained based on the original message to the service cloud gateway.

[0034] For example, Company A's terminal (i.e., branch terminal) 192.168.71.2, through... Figure 4 The red path in the middle sends the original message to the access network cloud gateway, which performs corresponding network protocol conversion and other processing on it, and then sends the processed message to the service cloud gateway.

[0035] It's important to clarify that an access gateway, also known as an access server, is responsible for providing internet access and is the first node server for all incoming traffic. A business gateway is a server through which east-west MEC (Multi-access Edge Computing) services flow. A cloud gateway generally refers to an access forwarding device in existing technologies. The access gateway handles local traffic access, while the cloud gateway is responsible for directing traffic to cloud resources. Together, they construct an end-to-end "local-cloud" connection. The access gateway and cloud gateway together form the access layer from the local to the cloud, ensuring secure and efficient data transmission. The business gateway handles traditional monolithic applications or basic services, while the business cloud gateway is geared towards cloud-native scenarios such as microservices, providing more granular service governance (e.g., service discovery) and observability. Both the business gateway and cloud gateway provide service governance, security protection, and traffic management at the business layer, supporting the collaboration between traditional and cloud-native services.

[0036] Step 30: The service cloud gateway converts the first packet into a second packet, and forwards the second packet to the SD-WAN vCPE through the VXLAN tunnel.

[0037] After processing the received first packet, the service cloud gateway obtains a second packet that can be sent through the VXLAN tunnel; this process will be described in detail below and will not be repeated here. The VXLAN tunnel on the SD-WAN side reaches the SD-WAN vCPE LAN port 192.168.71.254.

[0038] Step 40: The SD-WAN vCPE processes the received second message to obtain a third message, and forwards the third message to the headquarters device to transmit the traffic of the branch terminal to the headquarters device.

[0039] The third packet is forwarded from the SD-WAN vCPE WAN port to the enterprise headquarters (10.10.1.254) via Layer 3 routing and NAT. The specific method by which the packet is forwarded via Layer 3 routing and NAT is determined by those skilled in the art based on the specific use case and is not limited here.

[0040] Existing technologies for remote networking employ MPLS VPN or L2TP. MPLS requires label switching, resulting in low efficiency and complex configuration; L2TP tunnels require at least one end to have a public IP address. This invention solves these two major problems by using SDWAN VXLAN tunnel networking. It offloads traffic that heavily relies on public network transmission in existing solutions to the business gateway, which then creates an SDWAN VXLAN tunnel between headquarters and branches, connecting the headquarters and branches. This solves the problems of low efficiency, high cost, and complex configuration of MPLS VPN remote networking solutions, as well as the large fluctuations in data transmission quality caused by the heavy reliance on public networks in virtual LAN remote networking solutions.

[0041] In one embodiment, such as Figure 5 As shown, in step 20, the access cloud gateway forwards the first message obtained based on the original message to the service cloud gateway, including: Step 201: Obtain the source MAC address and source IP address from the original message.

[0042] like Figure 4 As shown, in one embodiment, the Brige WAN where the branch terminal is located is connected to the access cloud gateway via a segment routing over IPv6 (SRv6) tunnel; the original packet is encapsulated into the SRv6 tunnel at the ingress node (e.g., PE device). Figure 6 and Figure 7 As shown, the access cloud gateway, as the SRv6 endpoint, first decapsulates the outer SRH and extracts the inner packet; then, based on the destination address, it looks up the local routing table or VPN instance routing table to determine the next hop (i.e., the target business cloud gateway) path.

[0043] Obtain the source MAC address and source IP address of the branch terminal from the original message.

[0044] Step 202: Determine the source MAC address as the destination MAC address and the source IP address as the destination IP address to generate the first packet.

[0045] In this configuration, the access cloud gateway retains the source Media Access Control Address (MAC) address from the original packet, modifying only the destination MAC address to match the next-hop device. At the network layer, the source IP address of the inner packet remains unchanged; however, in one embodiment, the outer IPv6 tunnel address may be replaced with the gateway's public IP address or VPN instance address. If NAT or VPN instance routing is configured, the source IP address may be mapped to the cloud gateway's interface address, but the original address can be retained via the RD / RT identifier.

[0046] Step 203: Forward the first message to the business cloud gateway.

[0047] In one embodiment, data can also be transmitted between the access cloud gateway and the service cloud gateway through a VXLAN tunnel, that is, the access cloud gateway forwards the first packet to the service cloud gateway through the VXLAN tunnel.

[0048] In one optional embodiment, the access cloud gateway can also support IP address allocation, that is, support dynamically allocating IP addresses to the SD-WAN vCPE LAN port; it can also support static IP address uploading to the SD-WAN vCPE LAN port. Multicast traffic from the MEC side needs to be copied and forwarded to the terminal side; multicast traffic from the terminal side needs to be copied and forwarded to the Mobile Edge Computing (MEC) side.

[0049] It should be noted that the specific method by which the access cloud gateway transmits packets via a VXLAN tunnel is determined by those skilled in the art based on the specific use case. In the access cloud gateway's processing flow, account information is identified from the inner packet using DPI combined with user authentication, session tracking, and other technologies. In the first packet, an outer S-VLAN (i.e., service VLAN) and an inner C-VLAN (i.e., customer VLAN) have already been assigned to the user's account, effectively assigning a QinQ tag. This achieves the mapping from account information to QinQ tags, enabling refined service classification.

[0050] In one embodiment, such as Figure 8 As shown, step 30 includes: Step 301: Obtain the QinQ tag on the LAN side of the access cloud gateway carried in the first message.

[0051] QinQ (i.e., 802.1Q-in-802.1Q) is a multi-layer Virtual Local Area Network (VLAN) encapsulation technology. It is an extension of 802.1Q. Its core idea is to encapsulate the user's private network VLAN tag onto the public network VLAN tag, and the packet carries two layers of tags to traverse the service provider's backbone network.

[0052] Step 302: Based on the first message, map the QinQ tag to VNI information on the MEC side to obtain the second message.

[0053] Obtain the QinQ tag on the LAN side of the access cloud gateway carried in the first message, and replace the QinQ tag with VNI information; wherein, the VNI information is the VNI of the VLAN tunnel between the current service cloud gateway and the LAN port of the SD-WAN vCPE.

[0054] Step 303: Forward the second message to the LAN port of the SD-WAN vCPE.

[0055] Therefore, the VNI information is used to locate the required VXLAN tunnel, and the second message is forwarded.

[0056] In one embodiment, such as Figure 9 As shown, step 302 includes: Step 3021: Determine the VXLAN tunnel required by the business cloud gateway according to the QinQ tag.

[0057] Step 3022: Obtain the VNI information of the VXLAN tunnel.

[0058] Step 3023: Use the VNI information to encapsulate the first message using VXLAN to map the QinQ tag to VNI information on the MEC side, thereby obtaining the second message.

[0059] In a specific instance, the processing of the business cloud gateway includes: receiving a first message with a QinQ tag; looking up the mapping table based on the QinQ tag to determine the corresponding VNI information; encapsulating the original inner message (i.e., the first message with the QinQ tag removed) into the VXLAN tunnel corresponding to the determined VNI information, with the corresponding VNI information carried in the VXLAN header, thereby generating a second message.

[0060] In one embodiment, the VXLAN encapsulation of the first packet using the VNI information further includes: determining the destination MAC address of the next-hop device as the LAN port MAC address of the SD-WAN vCPE. The next-hop device is the SD-WAN vCPE, which achieves correct packet transmission by modifying the destination MAC address in the packet.

[0061] In one embodiment, in step 40, the SD-WAN vCPE processes the received second packet to obtain a third packet, including: The WAN port of the SD-WAN vCPE performs NAT based on the second packet to obtain the third packet.

[0062] Network Address Translation (NAT) is a technique used to switch from using private addresses on a local network to using global IP addresses when connecting to the internet. NAT was actually developed to address the shortage of IPv4 addresses. It translates IP addresses by mapping an external IP address and port to a larger set of internal IP addresses. Essentially, NAT uses traffic tables to route traffic from an external (host) IP address and port number to the correct internal IP address associated with the endpoint on the network. The specific method of NAT implementation is determined by those skilled in the art based on the specific use case and is not limited here.

[0063] In existing technologies, VXLAN tunnels are often used by users to establish long-distance Layer 2 networks. The corresponding VXLAN protocol mainly includes the local IP, the peer IP, VNI, and VXLAN header VLAN, etc. Existing technologies are limited to introducing Layer 3 IP traffic into the VXLAN tunnel to enable communication between Layer 3 traffic and the peer. However, the embodiments of this invention cleverly utilize VNI information to map the account information of the inner packet, i.e., the internal link, to QinQ, and then map QinQ to the VNI of the outer tunnel. Since there are approximately 16 million VNIs, meaning that the logical network of VXLAN is very rich, the embodiments of this invention can use the mapping between QinQ and VNI to integrate and connect networks of the same company in different regions, and isolate networks of different companies in different regions.

[0064] like Figure 7As shown, this embodiment of the invention enables refined management of service classification based on user accounts through four-fold mapping, achieving a truly user-aware network. The four-fold mapping are: mapping account information to QinQ tags at the access cloud gateway, mapping QinQ tags to VNI information at the service cloud gateway, mapping VNI to service policies, and mapping VNI information to the target vCPE LAN port. Specifically, the QinQ tag identifies classified traffic from the access cloud gateway. By parsing the combination of S-VLAN and C-VLAN, it can be mapped to the corresponding VXLAN logical network according to the QinQ tag. This VXLAN logical network is identified using VNI information. At the service cloud gateway, the VNI information is used as the policy lookup key to find the service, security, and / or routing policies required by the corresponding VXLAN logical network. Based on the VNI information, different processing methods are located, i.e., the target vCPE LAN port is found. After the corresponding message reaches the target vCPE LAN port from the service cloud gateway through the VXLAN tunnel, the VNI information is obtained from the VXLAN header. The target vCPE LAN port is associated with a specific service VLAN or subnet, thereby realizing service offloading.

[0065] This invention utilizes a two-layer tagging system of QinQ tags and VNI information, enabling elastic expansion to support large-scale multi-tenancy; centralized policy control at the business cloud gateway avoids policy fragmentation on edge devices; and decoupling access layer classification from core layer forwarding. Tag mapping replaces complex routing policies, greatly simplifying operation and maintenance. This achieves strict isolation between different accounts and different service types, ensuring they do not interfere with each other.

[0066] Based on this, and considering security, this embodiment of the invention performs two layers of verification before the inner message interaction: First, when broadcasting a DHCP message to request an IP address pool, it must carry a string agreed upon by the company and the cloud gateway, and interact through Option60 encapsulation to obtain a specific IP address; Second, the cloud gateway must learn the gateway MAC address and internal link information from the broadcast message on the SD-WAN side and record it internally for unicast forwarding. Specifically, in one embodiment, in a scenario of remote networking, the method further includes: the access cloud gateway receiving a broadcast DHCP message from the SD-WANvCPE side.

[0067] The access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value; wherein, the Option60 field value is pre-agreed between the branch terminal and the access cloud gateway.

[0068] The Option 60 parameter is a key field in the Dynamic Host Configuration Protocol (DHCP) used to identify the terminal type. Its configuration method is determined by those skilled in the art based on the specific use case. Since terminals from different companies or branches may access the same broadcast domain in a shared cloud network environment, this embodiment of the invention uses the Option 60 field to achieve precise addressing. The cloud gateway can distinguish the Option 60 field and allocate corresponding address ranges to achieve address isolation and policy separation. Besides allocating specific address pools, different network policies can also be issued based on the Option 60 field. Only terminals carrying the correct agreed-upon string can obtain an address; unauthorized devices cannot obtain a valid address, thereby achieving access control.

[0069] In one embodiment, after the access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value, the method further includes: the access cloud gateway learning and recording the gateway MAC address and internal link information from the broadcast DHCP message for use in unicast forwarding when the headquarters device accesses the branch terminal.

[0070] In one embodiment, the service cloud gateway can also achieve SD-WAN tunnel convergence: because the SD-WAN vCPE does not support building too many VXLAN tunnels, the tunnel between the service cloud gateway and the edge node access cloud gateway is converged by using the service cloud gateway, and then the service cloud gateway and SD-WAN vCPE build VXLAN tunnels. By transforming the fully interconnected tunnel mesh structure into a star structure, the number of tunnels is reduced. The specific method of deploying the service cloud gateway and achieving decoupling and flexible forwarding through two layers of tunnels based on the architecture of edge nodes and cloud service network segments can be determined by those skilled in the art according to the specific use case, and is not limited here.

[0071] The embodiments of the present invention also provide the following specific examples in practical application scenarios: In one embodiment, in a unicast traffic forwarding scenario: like Figure 4 As shown, the handling of internet traffic (i.e., internet access) is exactly the same as that of home broadband, and the corresponding transmission path is "terminal → WAN side interface → internet". The traffic here does not enter the SD-WAN tunnel, but directly accesses the external network through the operator's internet exit. Standard NAT and routing policies are usually used. This solution is suitable for application scenarios such as employees accessing public websites.

[0072] Traffic accessing SD-WAN (i.e., internal enterprise access) is handled as follows: it is forwarded to the MEC side, with the corresponding transmission path being "branch terminal → MEC side → business cloud gateway → SD-WAN vCPE → enterprise headquarters". The source IP address and source MAC address remain unchanged, preserving the original terminal identifier for easy source tracing and security policy matching. To ensure accurate delivery to the target device in the Layer 2 network, the business cloud gateway modifies the destination MAC address to the SD-WAN vCPE LAN port MAC address. In an optional embodiment, if a VXLAN tunnel is used, the destination MAC address of the inner encapsulated frame is the vCPE LAN port MAC address.

[0073] Below is a specific example of forwarding traffic from branch terminals to the corporate headquarters: Scenario 1: Obtaining an IP address from the LAN port of the enterprise headquarters' SD-WAN vCPE: The SD-WAN vCPE LAN initiates a broadcast DHCP message, which enters the service gateway through the SD-WAN tunnel. The service gateway forwards the message to the access cloud gateway according to the LAN-side QinQ and VNI mapping. The access cloud gateway assigns a specific IP address based on the DHCP Option 60 field carried in the DHCP message, and also supports static IP address access. The Option 60 parameter is a key field in the DHCP protocol used to identify the terminal type. Its configuration method varies depending on the device manufacturer and is mainly used for IP address allocation policy control. Here, the Option 60 parameter indicates that the SD-WAN vCPE LAN will carry a specific Option 60 field, such as the vCPE string, to request an IP address from the DHCP server of the access cloud gateway. After receiving the DHCP request message, the access cloud gateway will reply with the specific IP address 192.168.71.254 to the SD-WAN vCPE LAN. It is worth noting that this embodiment of the invention uses the Option 60 field to achieve security optimization: ensuring that users, devices, or applications must be securely authenticated before accessing resources.

[0074] Scenario 2: Accessing the cloud gateway to generate a tunnel relationship table of source MAC addresses: In Scenario 1, the access cloud gateway can learn the MAC address of the enterprise headquarters SD-WAN vCPE LAN through broadcast DHCP or Address Resolution Protocol (ARP), forming a relationship table of "VNI + QinQ + MAC + Tunnel ID". The security optimization of this embodiment is further reflected in: when establishing secure communication between the enterprise branch and the enterprise headquarters, the first step is broadcast communication, i.e., broadcasting a DHCP message that specifies the enterprise's Option60 field, and learning the MAC address of the enterprise headquarters SD-WAN vCPE LAN through broadcast DHCP or ARP, recording it in the MAC tunnel table, and using it for the next step of unicast communication.

[0075] Scenario 3: Enterprise headquarters SD-WAN access to branch office broadcasts: When the access cloud gateway receives a broadcast message from the SD-WAN side (i.e., the enterprise headquarters side), it learns the source MAC address of the SD-WAN side, copies the message to the vCPE, and forwards it to the enterprise branch terminals through "evpn+LAN_QinQ", so that the branch terminals can also learn the SD-WAN side MAC address. Here, evpn refers to a specific instance of Ethernet Virtual Private Network (EVPN), or it can be evpn tunnel information; LAN_QinQ refers to the QinQ on the LAN side.

[0076] When an enterprise branch initiates a DHCP or ARP broadcast to the vCPE, the access cloud gateway will forward it to the SD-WAN side based on whether the account binding exit rules have been configured in advance (for example, using the account "VNI+QinQ and LAN side ecpn tunnel information" to find the exit tunnel).

[0077] Scenario 4: Enterprise headquarters SD-WAN access to enterprise branch unicast scenario: When the access cloud gateway receives a packet whose destination MAC address is the SD-WAN side MAC address in scenario 2, it forwards it to the business cloud gateway according to the MAC tunnel table. On the business cloud gateway, LAN_QinQ is converted to MEC side VNI and sent to the enterprise headquarters through the VXLAN tunnel.

[0078] After the enterprise headquarters initiates a unicast message to the business gateway, it restores the original "LAN_QinQ+VXLAN tunnel" of the enterprise branch user according to the business VNI and sends it to the access cloud gateway. The access cloud gateway queries the LAN_LAN forwarding rules based on the received message with the destination MAC of the enterprise branch terminal and returns it to the enterprise branch.

[0079] Scenario 5: Personalized bandwidth control for corporate branches and headquarters: Implement rate limiting based on different enterprise accounts on the business gateway. This involves configuring rate templates for different enterprise accounts, as well as rate limiting templates for broadcast storms. This allows enterprise accounts to be bound to personalized bandwidth control templates, based on the enterprise account's link information (i.e., "VNI+QinQ"), tunnel exit information (tunnel ID, i.e., VXLAN ID), control type (e.g., full message, broadcast type, or specific protocol), and rate template.

[0080] It should be noted that traffic from branch terminals accessing the public network needs to be diverted at the access gateway.

[0081] The following are specific examples of how the method of this invention is applied in the following four business scenarios: Business Scenario 1: Smart Home Hard Drive 1) After the message arrives at the access gateway, look up the destination IP tunnel forwarding rules.

[0082] 2) Then, based on the received and extracted “LANVNI+QinQ”, find the service forwarding rule (i.e., LANVNI+QinQ+action (forwarding) --> outgoing interface VXLAN tunnel group), and then determine the VXLAN tunnel based on the tunnel group.

[0083] 3) If a hit occurs, the connection is transferred to the service gateway, where a fixed NAT is performed based on the account's "VNI+QinQ". The connection then exits through the service gateway via a Layer 3 sub-interface to access the Smart Home Hard Drive server. Here, "exiting through the service gateway via a Layer 3 sub-interface" means that on network devices (e.g., routers, firewalls, or service gateways), a Layer 3 sub-interface is configured as the logical outgoing interface for different service traffic to achieve VLAN-based service isolation and routing forwarding.

[0084] Business Scenario 2: Server-wide Game Acceleration 1) After the message arrives at the access gateway, the destination IP is searched for and matched with the service.

[0085] 2) Then, based on the received and extracted "LANVNI+QinQ" information, find the service forwarding rules (i.e., LANVNI+QinQ+action (forwarding) --> outgoing interface VXLAN tunnel group), and then determine the VXLAN tunnel based on the tunnel group.

[0086] 3) If a connection is found, the connection is transferred to the service gateway. The service gateway assigns NAT (e.g., "natIP+natport") to the VPN based on the binding relationship between the tunnel and the VPN. The connection then exits through the service gateway via a Layer 3 sub-interface to access the dedicated server game.

[0087] Business Scenario 3: Cloud Security 1) After the message arrives at the access gateway, look up the tunnel forwarding rules for the destination IP (0.0.0.0).

[0088] 2) Then, based on the incoming LANVNI+QinQ information, find the service forwarding rules (i.e., LAN_VNI+QinQ+action (forwarding) --> outgoing interface VXLAN tunnel group), and determine the VXLAN tunnel based on the tunnel group.

[0089] 3) If a hit occurs, the connection is transferred to the service gateway. The tunnel rules transmitted from the service gateway to the local MEC side are "LAN_VNI+QinQ+tunnel group-->control network element".

[0090] 4) The tunnel rule from the business gateway to the cloud security pool adopts "WAN_VNI+vLAN+control network element-->security pool tunnel".

[0091] 5) Analyze the traffic from step 3) in business scenario 3 by mirroring it to the security pool.

[0092] 6) The security pool converts the controlled analysis results into command and control rules and sends them to the control network element of the service gateway.

[0093] 7) After the control network element cleans and controls the traffic, it switches back to the access gateway.

[0094] 8) If the access gateway determines that the destination MAC address is not the LAN-side MAC address, it will transmit the packet to the Internet through the WAN-side EVPN tunnel to enable Internet access.

[0095] Business Scenario 4: Remote Networking 1) Obtain an IP address from the LAN port of the SD-WAN vCPE at the enterprise headquarters.

[0096] 2) The cloud gateway generates a tunnel relationship table of source MAC addresses.

[0097] 3) Broadcast scenario where the corporate headquarters accesses a branch office via SD-WAN.

[0098] 4) Unicast scenario where the enterprise headquarters accesses the enterprise branch via SD-WAN.

[0099] 5) Personalized bandwidth control for corporate branches and corporate headquarters.

[0100] This invention is based on a large Layer 2 extension, spanning a Layer 3 IP network to construct a continuous virtual Layer 2 domain. Virtual machines can seamlessly migrate between different physical locations and IP subnets without changing their IP addresses. Using 24-bit VNIDs, it can support approximately 16 million logical networks. It perfectly adapts to the multi-tenant needs of cloud data centers, allocating an independent network for each customer or application. It fully utilizes existing networks, based on IP / UDP encapsulation, requiring only IP routing support from the underlying network. It eliminates the need to modify existing core network architectures, enabling smooth evolution through layered deployment. The underlying layer is a Layer 3 network, allowing for better load balancing using multi-path routing technologies such as ECMP. Traffic can be transmitted simultaneously through multiple paths, fully utilizing all link bandwidth and avoiding STP congestion issues. Furthermore, relying on real-time network telemetry data (e.g., BGP status, link latency, and load), intelligent algorithms dynamically calculate and select the optimal transmission path; typical systems can complete failover within milliseconds, ensuring business continuity.

[0101] Existing geographically dispersed networking solutions suffer from the following problems: data is scattered across multiple locations, including the cloud, making the protection of core data assets a challenge; access to applications and data from multiple locations and scenarios presents a dilemma between network security and convenience; access points are numerous and scattered, resulting in a large attack exposure surface, making unified security operations and maintenance difficult; application authentication is fragmented, permissions are chaotic, and internal risks are difficult to control. Branch deployment of existing technologies is also difficult, and current IT operations and maintenance capabilities are insufficient. This invention, however, employs a Secure Access Service Edge (SASE) architecture to solve these problems. The deep integration of SD-WAN and SASE architectures offers natural advantages. SD-WAN will serve as a high-quality, low-latency underlying transmission pipeline, forming an integrated secure access service edge together with zero-trust network access and cloud security services, meeting the dual demands of high performance and high security in industries such as finance and healthcare.

[0102] like Figure 10 The diagram shown is an architectural schematic of a secure access service edge fusion device according to an embodiment of the present invention. The secure access service edge fusion device of this embodiment includes one or more processors 21 and a memory 22. Figure 10 Take a processor 21 as an example.

[0103] Processor 21 and memory 22 can be connected via a bus or other means. Figure 10 Taking the example of a connection between China and Israel via a bus.

[0104] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the secure access service edge fusion method in Embodiment 1. The processor 21 executes the secure access service edge fusion method by running the non-volatile software programs and instructions stored in the memory 22.

[0105] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0106] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they execute the secure access service edge fusion method in Embodiment 1 above, for example, executing each step of the secure access service edge fusion method described above.

[0107] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0108] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0109] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for edge fusion of secure access services, characterized in that, include: Build a VXLAN tunnel between the business cloud gateway and the LAN port of the SD-WAN vCPE; The branch terminal sends the original message to the access cloud gateway; The access cloud gateway forwards the first message obtained based on the original message to the service cloud gateway; The service cloud gateway converts the first packet into a second packet, and forwards the second packet to the SD-WAN vCPE through the VXLAN tunnel; The SD-WAN vCPE processes the received second message to obtain a third message, and forwards the third message to the headquarters equipment to transmit the traffic of the branch terminal to the headquarters equipment.

2. The edge fusion method for secure access services according to claim 1, characterized in that, The access cloud gateway forwards the first message obtained based on the original message to the service cloud gateway, including: Obtain the source MAC address and source IP address from the original message; The source MAC address is determined as the destination MAC address, and the source IP address is determined as the destination IP address to generate the first packet; The first message is forwarded to the business cloud gateway.

3. The edge fusion method for secure access services according to claim 2, characterized in that, The service cloud gateway converts the first packet into a second packet, and forwards the second packet to the SD-WAN vCPE through the VXLAN tunnel, including: Obtain the QinQ tag on the LAN side of the access cloud gateway carried in the first message; Based on the first message, the QinQ tag is mapped to VNI information on the MEC side to obtain the second message; The second message is forwarded to the LAN port of the SD-WAN vCPE.

4. The edge fusion method for secure access services according to claim 3, characterized in that, The step of mapping the QinQ tag to VNI information on the MEC side based on the first message to obtain the second message includes: The VXLAN tunnel required by the business cloud gateway is determined according to the QinQ tag. Obtain the VNI information of the VXLAN tunnel; The first message is encapsulated using the VNI information to map the QinQ tag to VNI information on the MEC side, thus obtaining the second message.

5. The secure access service edge fusion method according to claim 4, characterized in that, The step of using the VNI information to perform VXLAN encapsulation on the first message further includes: The destination MAC address of the next-hop device is determined to be the LAN port MAC address of the SD-WAN vCPE.

6. The edge fusion method for secure access services according to claim 3, characterized in that, The SD-WAN vCPE processes the received second message to obtain the third message, which includes: The WAN port of the SD-WAN vCPE performs NAT based on the second packet to obtain the third packet.

7. The edge fusion method for secure access services according to claim 1, characterized in that, In the scenario of remote networking, the method further includes: The access cloud gateway receives a broadcast DHCP message from the SD-WAN vCPE side; The access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value; wherein, the Option60 field value is pre-agreed between the branch terminal and the access cloud gateway.

8. The edge fusion method for secure access services according to claim 7, characterized in that, After the access cloud gateway assigns a specified IP address only when the broadcast DHCP message carries the Option60 field value, it also includes: The access cloud gateway learns and records the gateway MAC address and internal link information from the broadcast DHCP message for use in unicast forwarding when the headquarters device accesses the branch terminal.

9. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the secure access service edge fusion method according to any one of claims 1-8.

10. A secure access service edge fusion device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the secure access service edge fusion method according to any one of claims 1-8.

Images