VPN resource dynamic scheduling method and device based on service strategy

Abstract

The invention relates to the technical field of resource scheduling, and provides a VPN resource dynamic scheduling method and device based on a service strategy. The method comprises the following steps: establishing a logic sub-interface of a service server on a service switch, and determining a unique identifier of the sub-interface; allocating a unique NAI-IP address for terminal access, and establishing a mapping relationship among a real source MAC address of the terminal, the unique NAI-IP address and the unique identifier of the sub-interface; the access switch receives an original message from the terminal, and converts the original message into a standardized message by using the mapping relation; and sending the standardized message to the service switch so as to forward the standardized message to the service server. According to the invention, the problems that the campus network user cannot be accurately traced and positioned and the practicability is poor in a dual-network and dual-speed scene in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology, and in particular to a method and apparatus for dynamic scheduling of VPN resources based on business policies. Background Technology

[0002] In traditional campus network architectures, student dormitories typically use a large network segment (e.g., 10.1.0.0 / 16), with hundreds or thousands of students sharing this Internet Protocol (IP) address pool. Students in dormitories can access both the public network and the school's intranet. Within the campus network environment, different network bandwidth policies and speed limits are often set for accessing the public network (i.e., the internet) and the intranet (i.e., the school's internal network), providing a dual-network, dual-speed service. However, in this dual-network, dual-speed access scenario, secure and reliable access is crucial, especially ensuring that the school can control, check, and trace students' intranet access.

[0003] However, when accessing the network through the campus network, tracing and authentication devices can only rely on IP addresses. But the IP address pool is too large to trace back to an individual. Specifically, when students access the internet through the campus network, network devices (such as firewalls, auditing systems, and tracing systems) only see individual IP addresses as the source of traffic, such as "10.1.2.3". If network address translation (NAT) is implemented at the exit point, all students accessing the public network may be displayed with the same or a few public IP addresses, making it impossible to distinguish individuals. Because IP addresses are often controlled using a coarse-grained strategy (e.g., "allow access to the academic affairs system from the 10.1.0.0 / 16 network segment"), fine-grained access control for individuals (e.g., "only allow Zhang San to access the course selection system during the course selection period") is not possible. Furthermore, student IP addresses may be dynamically assigned, for example, different today than tomorrow, making it impossible to stably bind them to a single person. Furthermore, IP addresses themselves do not carry user identity information (e.g., student ID numbers). When a security incident occurs and tracing is required, network administrators can only locate a specific IP address and then need to search through Dynamic Host Configuration Protocol (DHCP) logs, Address Resolution Protocol Tables (ARP tables), etc., which is time-consuming, labor-intensive, difficult to trace, inaccurate, and inefficient.

[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 VPN resource dynamic scheduling method and device based on business strategy. Its purpose is to solve the problem that the existing technology cannot accurately locate campus network users in dual-network dual-speed scenarios, resulting in poor practicality.

[0006] The present invention adopts the following technical solution: In a first aspect, the present invention provides a method for dynamic scheduling of VPN resources based on business policies, comprising: Establish a logical sub-interface for the service server on the service switch and determine a unique identifier for the sub-interface; Assign a unique NAI-IP address to the terminal access, and establish a mapping relationship between the terminal's real source MAC address, the unique NAI-IP address and the unique identifier of the sub-interface; The access switch receives the original message from the terminal and uses the mapping relationship to convert the original message into a standardized message; The standardized message is sent to the service switch for forwarding to the service server.

[0007] Further, the access switch receives the original packet from the terminal and converts the original packet into a standardized packet using the mapping relationship, including: After receiving the original message sent by the terminal to the service server, the target sub-interface identifier to be sent is learned through the control plane or policy. The original packet is MAC address standardized according to the mapping relationship to obtain a first packet; so that the first packet can be sent to the service switch corresponding to the target sub-interface identifier through VXLAN or SRv6 tunnel; The first message is standardized by IP address according to the mapping relationship to obtain a standardized message.

[0008] Further, the step of standardizing the MAC address of the original packet according to the mapping relationship to obtain the first packet includes: The target sub-interface identifier is used as the unique identifier of the sub-interface to find the unique NAI-IP address according to the mapping relationship, and then used as the target NAI-IP address. The real source MAC address of the terminal in the original message is replaced with the unique identifier of the sub-interface, and the source IP of the inner IP packet in the original message is replaced with the NAI-IP address to generate the first message and complete the tunnel encapsulation.

[0009] Further, the step of standardizing the IP address of the first packet according to the mapping relationship to obtain a standardized packet includes: Before the first message enters the Overlay network, the VPN device or the cloud gateway device connected to it obtains the real source MAC address of the terminal in the first message; The terminal is used to find the unique identifier of the sub-interface in the mapping relationship and use it as the target sub-interface identifier. The real source MAC address in the first message is replaced with the target sub-interface identifier to obtain a standardized message.

[0010] Furthermore, after sending the standardized message to the service switch for forwarding to the service server, the method further includes: Based on the mapping relationship, the target source MAC address of the corresponding terminal is obtained by using the sub-interface identifier to be checked and the NAI-IP address to be checked in the data packet; The specific terminal device, access switch, physical port, and user identity information are located based on the target source MAC address in order to trace the data packet.

[0011] Furthermore, the step of locating the specific terminal device, access switch, physical port, and user identity information based on the target source MAC address to complete the tracing of the data packet includes: The specific terminal device is determined based on the target source MAC address; Use the target source MAC address to query the access switch and / or physical port in the terminal MAC address table; Use the NAI-IP address to be queried to query the user's identity information in the authentication system.

[0012] Furthermore, the step of establishing a logical sub-interface for the service server on the service switch and determining the unique identifier of the sub-interface includes: Determine the physical interface on the service switch that connects to the service server; Based on the physical interface identifier and logical channel identifier of the physical interface, a globally unique sub-interface MAC address is generated as the unique identifier of the sub-interface. Based on the unique identifier of the sub-interface, a logical sub-interface is created on the service switch for the physical interface.

[0013] Furthermore, the step of allocating a unique NAI-IP address for terminal access and establishing a mapping relationship between the terminal's real source MAC address, the unique NAI-IP address, and the unique identifier of the sub-interface includes: When a terminal accesses the network through authentication, the VPN device assigns a unique NAI-IP address to the terminal from its own maintained NAI-IP address pool; The VPN device records and generates a mapping relationship, which is associated with: the terminal's real source MAC address, the unique NAI-IP address, and the unique identifier of the sub-interface of the service switch.

[0014] Secondly, the present invention also provides a VPN resource dynamic scheduling apparatus based on service policies, used to implement the VPN resource dynamic scheduling method based on service policies 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, the instructions being executed by the processor for performing the VPN resource dynamic scheduling method based on service policies as described in the first aspect.

[0015] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors to perform the VPN resource dynamic scheduling method based on service policies described in the first aspect.

[0016] To meet the precise tracing and positioning requirements in dual-network, dual-speed scenarios, this invention establishes a logical sub-interface on the service switch. The unique identifier of this sub-interface globally and uniquely identifies the service server connected to the service switch. A unique logical identifier pair for the user terminal is formed by the unique sub-interface identifier and the unique NAI-IP address. Through the mapping relationship established during access authentication, precise positioning from any network packet to the end user can be achieved, resulting in accurate and efficient tracing. After receiving the original packet from the user terminal, during packet forwarding, the mapping relationship is used to convert it into a standardized packet, thus completing the identification and conversion of the user's identity. This process does not rely on application layer information, and even traffic encryption does not affect the tracing capability. It has strong versatility and achieves lossless tracing at the network layer. After forwarding the original packet to the service server according to the method of this invention, because the standardized packet carries information from the mapping relationship, it can not only accurately trace the user's identity, such as obtaining the user's IP address or MAC address, but also trace back to the specific physical or logical access point (i.e., the sub-interface of the service switch) through the mapping relationship. This provides critical path information for network fault location and security event analysis, offering comprehensive information dimensions and strong practicality. 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 flowchart illustrating a VPN resource dynamic scheduling method based on business policies provided in an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating a specific example of a VPN resource dynamic scheduling method based on business policies provided in an embodiment of the present invention. Figure 3 This is a flowchart illustrating step 10 provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating step 20 provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating a specific example of obtaining a unique identifier for a sub-interface provided by an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating a specific example of establishing a mapping relationship provided by an embodiment of the present invention; Figure 7 This is a flowchart illustrating step 30 provided in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating a specific example of standardizing, encapsulating, and forwarding raw messages to a service server, as 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 flowchart illustrating step 40 provided in an embodiment of the present invention; Figure 11 This is a flowchart illustrating a traceability process provided in an embodiment of the present invention; Figure 12 This is a schematic diagram illustrating a specific example of a traceability process provided in an embodiment of the present invention; Figure 13 This is a schematic diagram illustrating a specific example of generating traceability results from a query mapping relationship provided in an embodiment of the present invention; Figure 14 This is a schematic diagram illustrating a specific example of a traceability system architecture for processing traceability results, provided by an embodiment of the present invention. Figure 15 This is a schematic diagram of the architecture of a VPN resource dynamic scheduling device based on business policies 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: In existing campus network portal authentication systems, for traffic requiring tracing, the corresponding data packets can only locate dynamic IP addresses, but cannot directly associate them with specific user identities and service switches. Because campus network portal authentication typically uses DHCP to dynamically allocate IP addresses, users may obtain different IP addresses each time they connect (e.g., private network 10.xxx / 192.168.xx), and may be reassigned public IP addresses after successful authentication (e.g., 20.xxx). IP addresses and user identities are decoupled. This non-fixed binding of IP addresses and user identities makes it impossible to directly trace user identities through IP addresses. Dynamic IP addresses may change with user disconnection, device hibernation, or DHCP lease expiration. Especially in containerized and high-concurrency scenarios, the frequent recycling and allocation of IP address pools further obscures the association between user identities and IP addresses.

[0025] Switches forward data by learning the mapping between source MAC addresses and ports. However, in dynamic IP address scenarios, user MAC addresses may be updated as devices move or IP addresses change. Furthermore, campus networks use a Layer 3 authentication mechanism for identity verification. Under this mechanism, switches may not learn user MAC addresses, but only identify users by their IP addresses. This means that the connection between a user terminal and the access device may span multiple layers of switches, and the devices only record IP-level routing information, not retaining fine-grained "user-port" associations, making it impossible to locate the port using the terminal's MAC address. Moreover, in dual-network, dual-speed scenarios, campus networks often use Network Address Translation (NAT) to map private IP addresses to public IP addresses. One public IP address may correspond to multiple private network user identities, further complicating tracing.

[0026] To solve the above problems, such as Figure 1 As shown, this embodiment of the invention provides a method for dynamic scheduling of VPN resources based on business policies, including: Step 10: Establish a logical sub-interface for the service server on the service switch and determine the unique identifier of the sub-interface.

[0027] The architecture of one application scenario for the service policy-based dynamic resource scheduling method for Virtual Private Networks (VPNs) according to an embodiment of the present invention is as follows: The user's terminal can be a mobile phone or a personal computer. The terminal user connects to an access switch, and a Virtual Extensible Local Area Network (VXLAN) tunnel is established between the access switch and the service switch. The interface on the service switch that connects to the server is configured with a sub-interface, and a unique Media Access Control (MAC) address (e.g., MAC_S) is generated for each sub-interface. The VPN device is connected in parallel or in series in the user's access area.

[0028] The applicable scenarios and purposes of the embodiments of the present invention are described below: The cloud gateway is deployed in the cloud to connect the university's intranet and cloud services. To enable traceable authentication of internet users, it's necessary to bind terminal MAC addresses to IP addresses, and this binding relationship can be released and reallocated under certain conditions. In one embodiment, the cloud gateway, in conjunction with traceable authentication within a university's intranet, needs to achieve the following: 1. For packets sent from the service cloud gateway, one terminal MAC address is assigned a fixed IP address. 2. The fixed IP address can be released to other terminal MAC addresses when there is no traffic within a preset time; the preset time is configured by those skilled in the art based on the specific use case; in one embodiment, the preset time is 7 days by default. 3. The configuration of one terminal MAC address per IP address is done on a campus-by-campus basis; this function is disabled by default.

[0029] In one embodiment, to achieve source tracing, the VPN device is configured as follows: 1. Add an address pool: Allocate different address ranges according to the service type, ensuring that addresses from the same server and service network element are not duplicated. 2. Set MAC address encapsulation method: Select different encapsulation methods according to different service types, including sub-interface MAC and terminal MAC; sub-interface MAC encapsulation refers to the terminal information to which the user account belongs when traffic is sent out through the service server; terminal MAC encapsulation refers to the terminal information to which the user account belongs when the user account performs potal authentication in a campus network scenario.

[0030] This invention implements dynamic scheduling of VPN resources based on a dual-network, dual-speed service strategy traceable to user accounts, enabling the tracing of original packets sent through the VPN device. To achieve dynamic resource scheduling, in one embodiment, for a service server connected to a service switch, a corresponding logical sub-interface is created on the service switch. This logical sub-interface is created based on a calculated sub-interface MAC address, which serves as the unique identifier for the sub-interface. This globally unique sub-interface MAC address is used for subsequent source tracing and other functions.

[0031] Step 20: Assign a unique NAI-IP address to the terminal access and establish a mapping relationship between the terminal's real source MAC address, the unique NAI-IP address and the unique identifier of the sub-interface.

[0032] like Figure 2As shown, when an end user accesses the network after authentication, a user access and identity conversion process is first performed: the VPN device dynamically assigns a unique NAI-IP address to the terminal from its maintained Network Access Identifier Internet Protocol (NAI-IP) address pool; when assigning a unique NAI-IP address, the VPN device obtains the unique identifier of the sub-interface of the logical sub-interface on the corresponding service switch. The VPN device records and generates a three-layer mapping relationship, namely the mapping relationship between the terminal's real source MAC address obtainable when accessing the network, the unique NAI-IP address assigned to the terminal by the VPN device, and the obtained unique identifier of the sub-interface. The method of user authentication is determined by those skilled in the art based on the specific use case; user authentication can be performed through 802.1X or Portal.

[0033] Step 30: The access switch receives the original message from the terminal and uses the mapping relationship to convert the original message into a standardized message.

[0034] After the mapping relationship is established, such as Figure 2 As shown, for raw packets from end users, the terminal MAC address (denoted as Src_MAC) and terminal IP address (denoted as Src_IP) in the raw packets are converted according to the addresses recorded in the corresponding mapping relationship to achieve traffic standardization. In one embodiment, the terminal MAC address in the raw packets is replaced with the sub-interface MAC address (i.e., the unique identifier of the sub-interface), and the terminal IP address is replaced with the unique NAI-IP address assigned to the terminal by the VPN device. The final standardized and converted packets are then obtained.

[0035] Step 40: Send the standardized message to the service switch for forwarding to the service server.

[0036] like Figure 2 As shown, the corresponding tunnel addressing and message forwarding process is performed on the standardized message, and it is finally transmitted to the business server. A specific implementation will be given below, and will not be described in detail here.

[0037] To meet the precise tracing and positioning requirements in dual-network, dual-speed scenarios, this invention establishes a logical sub-interface on the service switch. The unique identifier of this sub-interface globally and uniquely identifies the service server connected to the service switch. A unique logical identifier pair for the user terminal is formed by the unique sub-interface identifier and the unique NAI-IP address. Through the mapping relationship established during access authentication, precise positioning from any network packet to the end user can be achieved, resulting in accurate and efficient tracing. After receiving the original packet from the user terminal, during packet forwarding, the mapping relationship is used to convert it into a standardized packet, thus completing the identification and conversion of the user's identity. This process does not rely on application layer information, and even traffic encryption does not affect the tracing capability. It has strong versatility and achieves lossless tracing at the network layer. After forwarding the original packet to the service server according to the method of this invention, because the standardized packet carries information from the mapping relationship, it can not only accurately trace the user's identity, such as obtaining the user's IP address or MAC address, but also trace back to the specific physical or logical access point (i.e., the sub-interface of the service switch) through the mapping relationship. This provides critical path information for network fault location and security event analysis, offering comprehensive information dimensions and strong practicality.

[0038] This invention also provides a system for implementing the VPN resource dynamic scheduling method based on service policies, comprising: 1. Access and Service Switch Group: Includes access switches and service switches, supporting VXLAN or SRv6 tunnel encapsulation / decapsulation functions. The service switches are configured with logical sub-interfaces that generate globally unique sub-interface MAC addresses.

[0039] 2. VPN Device: Deployed at the user access boundary, it has a built-in NAI-IP address pool for authenticating terminals and assigning a unique NAI-IP address to successfully authenticated terminals. It also has a built-in mapping management module for establishing and maintaining a three-layer mapping table of the terminal's real MAC address, NAI-IP, and sub-interface MAC address.

[0040] 3. Address translation module: Located in the VPN device or a standalone cloud network management device, it is used to replace the source MAC address in the user packet from the terminal's real MAC address to the sub-interface MAC address according to the three-layer mapping table before the user packet enters the Overlay network.

[0041] 4. Network Management and Traceability System: This is a cloud network management device used to synchronize the Layer 3 mapping table from the VPN device. This system can capture network traffic and, based on the sub-interface MAC address and / or NAI-IP address in the traffic, query the mapping table to trace back the end-user information and access location.

[0042] The following section, in conjunction with the aforementioned system and architecture, further explains the VPN resource dynamic scheduling method based on business policies according to embodiments of the present invention: In one embodiment, such as Figure 3 As shown, step 10 includes: Step 101: Determine the physical interface on the service switch that connects to the service server.

[0043] On the business switch, determine the physical interface of the business server that needs to be included in the traceability scope.

[0044] Step 102: Based on the physical interface identifier and logical channel identifier of the physical interface, generate a globally unique sub-interface MAC address as the unique identifier of the sub-interface.

[0045] Based on its physical interface identifier (such as physical MAC) and logical channel identifier (such as the allowed VLAN ID for trunk), a globally unique sub-interface MAC address is generated using a preset algorithm. This sub-interface MAC address serves as a unique and stable logical identifier for this service server or service server group within the network, i.e., the unique identifier of the sub-interface.

[0046] In one embodiment, the physical interface G1 / 0 / 1 of the service switch has a factory-installed MAC address (denoted as BIA_MAC), and the physical MAC address of the service switch can be denoted in the form of "AA-BB-CC-DD-EE-FF". When a sub-interface G1 / 0 / 1.100 is created on it, a globally unique sub-interface MAC address MAC_S is generated using a specified algorithm. Sub-interface G1 / 0 / 1.100 corresponds to VLAN 100, meaning VLAN 100 refers to the virtual LAN numbered 100. This number is used to isolate different user groups, departments, or service traffic, improving network security and efficiency. Physical interface G1 / 0 / 1 is bound to VLAN 100 through sub-interface G1 / 0 / 1.100. After binding, sub-interface G1 / 0 / 1.100 acts as the gateway for VLAN 100, handling Layer 3 communication (e.g., IP routing) for devices within that VLAN. The preset algorithm is determined by those skilled in the art based on the specific application scenario. In one embodiment, the preset algorithm can be: performing a calculation between the last two bytes of BIA_MAC and the VLAN number; that is, sub-interface MAC address = physical MAC address + VLAN number offset. For example, for VLAN number 100, the sub-interface MAC address is calculated as AA-BB-CC-DD-EE-FF + 0x000000000064 = AA-BB-CC-DD-EF-63; sub-interface 1 is created as G1 / 0 / 1.100, VLAN number is 100, and the corresponding sub-interface MAC address is AA-BB-CC-DD-EF-63. For VLAN number 200, calculate the sub-interface MAC address as AA-BB-CC-DD-EE-FF+0x0000000000C8=AA-BB-CC-DF-58-C7; create sub-interface 2 as G1 / 0 / 1.200, VLAN number 200, and the corresponding sub-interface MAC address as AA-BB-CC-DF-58-C7.

[0047] Step 103: Create a logical sub-interface for the physical interface on the service switch according to the unique identifier of the sub-interface.

[0048] Use the unique identifier of the sub-interface generated in step 102 to create a logical sub-interface for the physical interface connecting to the business server.

[0049] Based on this, the embodiments of the present invention also provide a comparison table of generation methods. Both centralized allocation and random generation schemes are derived from the generation method based on physical MAC; as shown in Table 1 below.

[0050] Table 1 Comparison of Generation Methods

[0051] After obtaining the unique identifier of the sub-interface, in one embodiment, such as Figure 4 As shown, step 20 includes: Step 201: When a terminal accesses the network through authentication, the VPN device assigns a unique NAI-IP address to the terminal from its own maintained NAI-IP address pool.

[0052] like Figure 2 and Figure 5 As shown, when a user terminal initiates network access, user traffic processing is performed first: if the terminal user fails authentication, they cannot access the network. When the terminal user successfully accesses the network, the VPN device determines the unique identifier (i.e., the sub-interface MAC address) of the corresponding service switch's sub-interface by querying routes, etc. Then, for logical sub-interfaces that have not been assigned a unique NAI-IP address, the VPN device dynamically assigns a unique NAI-IP address to the terminal from its maintained NAI-IP address pool. In one embodiment, the VPN device records and generates a Layer 3 mapping table to store the Layer 3 mapping relationship, which at least associates: the terminal's real source MAC address, the NAI-IP address assigned by the VPN, and the sub-interface MAC address of the service switch. In one embodiment, the mapping relationship is synchronized to the network management system.

[0053] Step 202: The VPN device records and generates a mapping relationship, which is associated with: the terminal's real source MAC address, the unique NAI-IP address, and the unique identifier of the sub-interface of the service switch.

[0054] like Figure 6 As shown, after user traffic processing, the unique identifier of the sub-interface (i.e., the sub-interface MAC address) is obtained. Then, for that sub-interface MAC address, the unique NAI-IP address assigned to it (e.g., ...) is used. Figure 6 The "10.10.1.100" in the URL and the corresponding terminal's real source MAC address (e.g., "10.10.1.100") Figure 6 The mapping relationship between the three ("00-11-22-33-44-55") is established for subsequent queries. In one embodiment, a three-layer mapping table can also be used to record the established mapping relationship and the VLAN number corresponding to the MAC address of the sub-interface (e.g., ...). Figure 6 "100" in the middle), access port (such as Figure 6 The "G0 / 1" in the name and the allocation time of this unique NAI-IP address (e.g., Figure 6 (e.g., "2024-01-15 10:30:00"). In one embodiment, for each service switch, a corresponding Layer 3 mapping table is established for the corresponding switch port; alternatively, a unified Layer 3 mapping table can be maintained, recording the corresponding switch port in each record.

[0055] The embodiments of the present invention use a unique logical identifier pair consisting of a unique sub-interface identifier and a unique NAI-IP address, combined with a pre-established mapping relationship, to complete the accurate location from any network packet to the end user in constant time complexity (O(1)), which is fast and highly accurate.

[0056] In one embodiment, before portal authentication is performed, a mapping relationship can be established between the sub-interface MAC address, the physical interface identifier of the physical interface, and the terminal's real source MAC address, so that the mapping relationship can be directly traced back to the terminal and the corresponding physical port.

[0057] like Figure 6 As shown, after establishing the mapping relationship and synchronizing it to the cloud network management system, the system can begin receiving raw packets from the terminal and process them using the mapping relationship. In one embodiment, as... Figure 7 As shown, step 30 includes: Step 301: After receiving the original message sent by the terminal to the service server, the target sub-interface identifier to be sent is learned through the control plane or policy.

[0058] The target sub-interface identifier is a unique identifier for the sub-interface corresponding to the original packet (i.e., the sub-interface MAC address), used to identify the service switch to which the original packet needs to be sent. The target sub-interface identifier is also globally unique.

[0059] like Figure 8 As shown, after receiving the original packet, due to the need for tunnel addressing and packet forwarding, the access switch, upon receiving the traffic (i.e., the original packet) sent by the terminal to the service server, needs to learn through the control plane or policy whether to send the traffic to the service switch corresponding to the target sub-interface identifier via VXLAN or a Segment Routing Internet Protocol Version 6 (SRv6) tunnel. In one embodiment, the control plane can be an Ethernet Virtual Private Network (EVPN); the policy can be an SRv6 policy.

[0060] Step 302: Standardize the MAC address of the original packet according to the mapping relationship to obtain a first packet; standardize the IP address of the first packet according to the target sub-interface identifier and the mapping relationship to obtain a standardized packet.

[0061] The access switch uses the information recorded in the mapping relationship to standardize the MAC address and IP address of the original packet, resulting in a standardized packet.

[0062] Since the terminal's true source MAC address carries the terminal's physical information, to facilitate subsequent traceability, it needs to be converted into a unique sub-interface identifier of the logical interface created in this embodiment of the invention, and the IP address needs to be converted into a unique NAI-IP address allocated in this embodiment of the invention. After the replacement, the packets flowing into the Overlay core network have controllable, traceable, and easily traceable unique logical identifiers for both their source MAC address and source IP address. This decouples the terminal's uncontrollable physical address (i.e., the true source MAC address and source IP address) from the unified logical address (i.e., the unique sub-interface identifier and the unique NAI-IP address), thereby achieving network decoupling, controllability, and security.

[0063] Specifically, in one embodiment, such as Figure 9 As shown, step 302 includes: Step 3021: Replace the real source MAC address of the terminal in the original message with the unique identifier of the sub-interface to obtain the first message.

[0064] For example, the real source MAC address in the original message (i.e., Figure 8 The “00-11-22-33-44-55” in the code is replaced with the sub-interface MAC address (i.e., Figure 8 (AA-BB-CC-DD-EF-63 in the text).

[0065] Step 3022: Use the target sub-interface identifier as the unique identifier of the sub-interface to find the unique NAI-IP address according to the mapping relationship, and use it as the target NAI-IP address.

[0066] For example, the mapping relationship with the unique identifier of the sub-interface "AA-BB-CC-DD-EF-63" is found, and the unique NAI-IP address "10.10.1.100" in this mapping relationship is obtained and used as the target NAI-IP address. The target NAI-IP address is also globally unique.

[0067] Step 3023: Replace the source IP address in the first message with the target NAI-IP address to obtain a standardized message.

[0068] For example, the source IP address of the inner IP packet (i.e., Figure 8 The address “192.168.1.100” is replaced with the NAI-IP address “10.10.1.100”, resulting in... Figure 8The converted message (i.e., the standardized message) in the middle.

[0069] Before a packet enters the Overlay network, the VPN device or its connected cloud network management device performs MAC address and IP address conversion based on the mapping relationship established in step 20 above. At this point, the source addresses (MAC and IP) of packets flowing within the network have been standardized into unique logical identifiers (sub-interface MAC and NAI-IP) within the network.

[0070] This completes the standardization and conversion of traffic, resulting in standard packets, which are then forwarded to the access switch (i.e., Figure 8 The access switch (SW) in the middle. Then it is encapsulated and forwarded. In one embodiment, such as Figure 10 As shown, step 40 includes: Step 401: The access switch constructs an inner Ethernet frame and determines the destination MAC address of the inner Ethernet frame as the MAC address of the service server to complete the tunnel encapsulation of the standardized message and obtain the encapsulated message.

[0071] Among them, the destination MAC address of the inner Ethernet frame (i.e., Figure 8 In this context, "Dst_MAC" is set to the MAC address of the business server (i.e., Figure 8 (e.g., the "server MAC address" in the URL). Figure 8 The diagram illustrates a specific example of VXLAN encapsulation. The specific encapsulation method should be determined by those skilled in the art based on the specific application scenario, and is not limited here. Tunnel encapsulation is performed on standardized messages. The inner Ethernet frame is a logical, virtual Layer 2 frame, which will be used as the data payload and encapsulated within the outer tunneling protocol.

[0072] Step 402: Forward the encapsulated message to the service switch through the tunnel to obtain the decapsulated message.

[0073] For example, forwarding to the service switch via a VXLAN tunnel (i.e., Figure 8 In the service switch (SW), the service switch decapsulates the encapsulated packet according to the decapsulation rules corresponding to the encapsulation method to obtain the decapsulated packet.

[0074] Step 403: Send the decapsulated message to the service server according to the destination MAC address.

[0075] Once the decapsulated message is sent to the business server, the transmission of the original message is complete.

[0076] This invention deeply integrates with Overlay technology: it combines the generation of traceability identifiers (i.e., unique identifiers for sub-interfaces) with forwarding strategies (e.g., VXLAN or SRv6 addressing), making the traceability mechanism a native network capability rather than an external addition, thus simplifying the architecture. In one embodiment, the combination of VXLAN and Overlay networks enables network administrators to manage multi-tenant environments in campus network scenarios more efficiently, simplifying network configuration and improving network scalability and flexibility.

[0077] Below is a specific example of a user onboarding and first-package processing flow: 1. Once the terminal (MAC_T) comes online and passes authentication, the VPN device assigns it a NAI-IP (IP_N).

[0078] 2. The VPN device queries the route or policy to determine whether the service the terminal wants to access is provided by the sub-interface (MAC_S) on the service switch.

[0079] 3. The VPN device creates a record in its mapping table: {Terminal MAC: MAC_T, NAI-IP: IP_N, Sub-interface MAC: MAC_S}.

[0080] 4. The terminal sends the first message for accessing the service (source MAC_T, source IP_T).

[0081] 5. The VPN device or cloud network management device intercepts this packet and, according to the mapping table, replaces the source MAC address from MAC_T to MAC_S and the source IP address from IP_T to IP_N. The cloud network management device can be a network management and tracing system based on the method of this embodiment.

[0082] 6. The modified message is sent to the access switch. The access switch encapsulates the message through a VXLAN tunnel (with MAC_S as the key inner identifier) ​​based on the destination address and then sends it to the service switch.

[0083] The traffic transmitted through the above process can then be used to accurately locate and pinpoint campus network users in a dual-network, dual-speed scenario. To illustrate the tracing process, in one embodiment, such as... Figure 11 As shown, after step 40, the following steps are also included: Step 501: Based on the mapping relationship, use the sub-interface identifier to be checked and the NAI-IP address to be checked in the data packet to obtain the target source MAC address of the corresponding terminal.

[0084] like Figure 12As shown, in one embodiment, the triggering of tracing may include: triggering a security event through attack traffic detection, triggering an operation and maintenance requirement through performance problem investigation, and triggering a compliance audit due to the lack of access log auditing for images. After triggering tracing, the characteristics of the suspicious message are obtained, that is, the key information (e.g., unique identifier of sub-interface, unique NAI-IP address, timestamp, and IP of the target business server, etc.) are extracted.

[0085] When it is necessary to trace the traffic of access services, the network management system captures a data packet with a unique sub-interface identifier (i.e., the sub-interface MAC address) and a unique NAI-IP address as its source; this data packet is equivalent to the aforementioned original packet. The true source MAC address of the original terminal corresponding to this data packet can be immediately retrieved: the sub-interface identifier (i.e., the NAI-IP address) in the data packet is then used to trace the traffic. Figure 12 The "AA-BB-CC-DD-EF-63" in the code is used as the unique identifier for the sub-interface, and the NAI-IP address to be queried (i.e., Figure 12 The address “10.10.1.100” is used as the unique NAI-IP address. The corresponding mapping relationship is queried from the mapping relationship database established and synchronized in step 20, and the real source MAC address is obtained from this mapping relationship as the query result. In one embodiment, such as... Figure 13 As shown, if no query results are obtained, the query will be logged.

[0086] Step 502: Locate the specific terminal device, access switch, physical port, and user identity information based on the target source MAC address to complete the tracing of the data packet.

[0087] In one embodiment, step 50 includes: determining the specific terminal device according to the target source MAC address; querying the access switch and / or physical port in the terminal MAC address table using the target source MAC address; and querying the user identity information in the authentication system using the NAI-IP address to be queried.

[0088] like Figure 13 As shown, the system then combines the terminal MAC address table or authentication system logs to perform information correlation queries to locate the specific terminal device, access switch, physical port, and user identity information, achieving precise end-to-end tracing. The terminal MAC address table can be the content-addressable memory table (CAM) of the access switch. Finally, the content retrieved from multiple queries is output as the tracing result.

[0089] In existing technologies, tracing a single data packet requires finding user identity information in Portal logs (or other user authentication logs), obtaining the binding relationship between IP address and MAC address in DHCP logs, obtaining physical port information in the switch MAC table, and accessing the NAT table. This tracing process is extremely complex and has very low practicality in scenarios where network administrators need to trace a large number of data packets in a short period of time.

[0090] However, in addition to the aforementioned difficulties in tracing the source of dynamic IP addresses, in the real and complex scenarios of campus networks, even if all the data of DHCP and Portal servers are in hand, it is often impossible to accurately locate the user and the service switch. For example: (1) Since ordinary users can also modify their own computer's MAC address; in a specific instance, a user can first clone the MAC address of an authenticated legitimate other device, and then use their own original device to access the Internet. At this time, the Portal log shows a legitimate user, and the binding of MAC address and IP address in the DHCP log is also chaotic; the malicious traffic located during tracing comes from the MAC address of a legitimate user, leading to misjudgment. Even attackers can use completely random MAC addresses, using different MAC addresses for each connection, making the historical association based on MAC address completely invalid, resulting in almost no tracing. (2) The user who is the attacker continuously sends forged DHCP requests, exhausting the IP address pool; or, the attacker can also manually set an already assigned IP address, causing IP conflicts, resulting in network chaos, and real users cannot obtain IP addresses or frequently disconnect. The IP address of the malicious packets traced may appear in the log records of multiple devices at the same time, making it impossible to determine the real source. (3) When the campus network’s Portal authentication only forcibly intercepts Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) traffic, users can bypass authentication by using VPN proxy tunnels or special port protocols. Since an encrypted tunnel has been established before authentication, all traffic is transmitted through this tunnel and does not go through Portal authentication at all. Therefore, there are no internet access logs of the user on the Portal server. Only an IP address can be found to be sending encrypted traffic, but the user terminal cannot be located and the source cannot be traced.

[0091] In this embodiment of the invention, a logical sub-interface is created for each physical port on the service switch. Each sub-interface has a unique MAC address (i.e., the sub-interface MAC address) controlled by the network administrator. When a terminal authenticates through the Portal, the system not only assigns a NAI-IP but also dynamically binds the mapping relationship between the "terminal's real MAC address, sub-interface MAC address, and NAI-IP," recording it in a centralized Layer 3 mapping table. Any original packet sent by the terminal, upon entering the switch, has its Layer 2 source MAC address replaced with the corresponding logical sub-interface MAC address, and its Layer 3 source IP address replaced with the NAI-IP. All packets flowing through the network can directly look up all Layer 3 mapping tables using their sub-interface MAC address and NAI-IP to obtain the terminal's real MAC address and the specific port of the service switch.

[0092] Furthermore, it can overcome the technical bottlenecks that prevent traceability in the aforementioned three scenarios, specifically: (1) In the case of MAC address spoofing and randomization, the real source MAC address of the terminal can be quickly found by directly querying the three-layer mapping table using the sub-interface MAC address and NAI-IP, and the user identity can be located based on portal authentication. Even if the terminal changes its MAC address to other values, the terminal can still be found directly because all the original packets it sends are uniquely identified by the same sub-interface MAC address.

[0093] (2) Regarding the conflict between forged DHCP requests and IP addresses, since the source IP of the original packets sent by the same terminal is forcibly replaced with NAI-IP, the terminal cannot control its own valid IP address in the network. Therefore, even if the terminal forges DHCP packets, the source MAC and source IP of these packets will be modified by the switch. The truly valid IP address can only be obtained through Portal authentication, which makes all data packets in the network traceable through the three-layer mapping table. Even if the data packet to be traced was sent before portal authentication, since the unique identifier of the sub-interface (i.e., the globally unique sub-interface MAC address) is generated by a specific algorithm based on the physical interface identifier and logical channel identifier of the physical interface, and the mapping relationship of "sub-interface MAC address - physical port - terminal real source MAC address" is also stored for unauthenticated terminals, the physical port and the terminal's real MAC address can be directly located.

[0094] (3) In the case of using unauthenticated channels or protocol tunnels, since any traffic, whether encrypted or not, must be standardized by address as in step 30 of the present invention and forwarded by step 40 so that the outer encapsulation message of the tunnel is labeled with the sub-interface MAC address and NAI-IP, even if the tunnel content cannot be decrypted, the entity that establishes the tunnel (i.e., the terminal's real source MAC) can be accurately determined by querying the three-layer mapping relationship table.

[0095] When the root cause of a problem lies in the physical layer, Layer 2 protocols, or involves unauthenticated devices, or requires precise physical location for on-site handling, tracing back to the specific physical port of the service switch is necessary. Since the Layer 3 mapping table records the switch ports, or a corresponding Layer 3 mapping table is created for each switch port, the service switch can be quickly located by directly querying the Layer 3 mapping table using the sub-interface MAC address and NAI-IP. This eliminates the need for cumbersome, time-consuming, and sometimes unreliable existing technical methods.

[0096] Below is a specific example of a process for network administrators to trace back data: 1. A suspicious data packet was captured on the service switch or core link, with a source address of (MAC_S, IP_N).

[0097] 2. Submit MAC_S and IP_N as the join query keys to the network management and traceability system.

[0098] 3. The tracing system queries the mapping relationship database synchronized from the VPN device to immediately obtain the corresponding terminal's real MAC_T.

[0099] 4. The system then queries the IPAM (IP Address Management), authentication system, or access switch MAC table to obtain the user account, terminal hostname, and access switch IP and port number corresponding to MAC_T.

[0100] 5. The system integrates all information, generates a complete traceability report, and presents it to the network administrator.

[0101] This invention achieves lossless network layer tracing: user identity identification and conversion are completed during packet forwarding, without relying on application layer information. Even with traffic encryption, the tracing capability remains unaffected, demonstrating strong versatility. Furthermore, the tracing is precise and efficient: using a unique logical identifier pair consisting of a sub-interface unique identifier and a unique NAI-IP address, combined with a pre-established mapping table, accurate location from any network packet to the end user can be achieved in constant time complexity (O(1)), resulting in high speed and accuracy. It can not only trace the user's identity (i.e., IP address or MAC action), but also trace back to the specific physical or logical access point (i.e., the sub-interface of the service switch) through mapping relationships, providing critical path information for network fault location and security event analysis. The information obtained from tracing and location is relatively complete and highly practical.

[0102] In one embodiment, such as Figure 14 As shown, embodiments of the present invention can also implement a real-time query interface by implementing the method of step 50 above, and support the access of other application programming interfaces (APIs). This real-time query interface can support batch tracing functions and display the tracing results on a visual interface, thereby providing a tracing system. In addition, the tracing results can also be used for security processing, auditing records, and operation and maintenance optimization.

[0103] Example 2: like Figure 15 The diagram shown is an architectural schematic of a VPN resource dynamic scheduling device based on service policies according to an embodiment of the present invention. This embodiment of the VPN resource dynamic scheduling device based on service policies includes one or more processors 21 and a memory 22. Figure 15 Take a processor 21 as an example.

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

[0105] 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 VPN resource dynamic scheduling method based on service policies in Embodiment 1. The processor 21 executes the VPN resource dynamic scheduling method based on service policies by running the non-volatile software programs and instructions stored in the memory 22.

[0106] 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.

[0107] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they execute the VPN resource dynamic scheduling method based on service policies described in Embodiment 1 above, for example, executing each step of the VPN resource dynamic scheduling method based on service policies described above.

[0108] 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.

[0109] 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.

[0110] 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 dynamic scheduling of VPN resources based on business policies, characterized in that, include: Establish a logical sub-interface for the service server on the service switch and determine a unique identifier for the sub-interface; Assign a unique NAI-IP address to the terminal access, and establish a mapping relationship between the terminal's real source MAC address, the unique NAI-IP address and the unique identifier of the sub-interface; The access switch receives the original message from the terminal and uses the mapping relationship to convert the original message into a standardized message; The standardized message is sent to the service switch for forwarding to the service server.

2. The VPN resource dynamic scheduling method based on business policies according to claim 1, characterized in that, The access switch receives the original packet from the terminal and converts the original packet into a standardized packet using the mapping relationship, including: After receiving the original message sent by the terminal to the service server, the target sub-interface identifier to be sent is learned through the control plane or policy. The original packet is MAC address standardized according to the mapping relationship to obtain a first packet; the first packet is IP address standardized according to the target sub-interface identifier and the mapping relationship to obtain a standardized packet.

3. The VPN resource dynamic scheduling method based on business policies according to claim 2, characterized in that, The original packet is MAC address standardized according to the mapping relationship to obtain the first packet; Based on the target sub-interface identifier and the mapping relationship, the first packet is standardized by IP address to obtain a standardized packet, including: The real source MAC address of the terminal in the original message is replaced with the unique identifier of the sub-interface to obtain the first message; The target sub-interface identifier is used as the unique identifier of the sub-interface to find the unique NAI-IP address according to the mapping relationship, and then used as the target NAI-IP address. The source IP address in the first message is replaced with the target NAI-IP address to obtain a standardized message.

4. The VPN resource dynamic scheduling method based on business policies according to claim 2, characterized in that, Sending the standardized message to the service switch for forwarding to the service server includes: The access switch constructs an inner Ethernet frame and determines the destination MAC address of the inner Ethernet frame as the MAC address of the service server to complete the tunnel encapsulation of the standardized message and obtain the encapsulated message. The encapsulated message is forwarded to the service switch through a tunnel to obtain the decapsulated message; The decapsulated message is sent to the service server according to the destination MAC address.

5. The VPN resource dynamic scheduling method based on business policies according to claim 1, characterized in that, After sending the standardized message to the service switch for forwarding to the service server, the method further includes: Based on the mapping relationship, the target source MAC address of the corresponding terminal is obtained by using the sub-interface identifier to be checked and the NAI-IP address to be checked in the data packet; The specific terminal device, access switch, physical port, and user identity information are located based on the target source MAC address in order to trace the data packet.

6. The VPN resource dynamic scheduling method based on business policies according to claim 5, characterized in that, The step of locating the specific terminal device, access switch, physical port, and user identity information based on the target source MAC address to complete the tracing of the data packet includes: The specific terminal device is determined based on the target source MAC address; Use the target source MAC address to query the access switch and / or physical port in the terminal MAC address table; Use the NAI-IP address to be queried to query the user's identity information in the authentication system.

7. The VPN resource dynamic scheduling method based on business policies according to any one of claims 1-6, characterized in that, The step of establishing a logical sub-interface for the service server on the service switch and determining the unique identifier of the sub-interface includes: Determine the physical interface on the service switch that connects to the service server; Based on the physical interface identifier and logical channel identifier of the physical interface, a globally unique sub-interface MAC address is generated as the unique identifier of the sub-interface. Based on the unique identifier of the sub-interface, a logical sub-interface is created on the service switch for the physical interface.

8. The VPN resource dynamic scheduling method based on business policies according to any one of claims 1-6, characterized in that, The step of allocating a unique NAI-IP address to the terminal for access and establishing a mapping relationship between the terminal's real source MAC address, the unique NAI-IP address, and the unique identifier of the sub-interface includes: When a terminal accesses the network through authentication, the VPN device assigns a unique NAI-IP address to the terminal from its own maintained NAI-IP address pool; The VPN device records and generates a mapping relationship, which is associated with: the terminal's real source MAC address, the unique NAI-IP address, and the unique identifier of the sub-interface of the service switch.

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 VPN resource dynamic scheduling method based on service policies as described in any one of claims 1-8.

10. A VPN resource dynamic scheduling device based on business policies, 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 VPN resource dynamic scheduling method based on any one of claims 1-8.

Images