Traffic speed limiting method and device, electronic equipment and storage medium

Abstract

The invention discloses a traffic speed limiting method and device, electronic equipment and a storage medium, and belongs to the technical field of network security. The method comprises the steps of determining a port type of a to-be-configured port under the condition that a port configuration message sent by a control node in the virtual network is received; the port type comprises whether the port belongs to a virtual machine; under the condition that the port type is a virtual machine, determining whether the identifier of the to-be-configured port belongs to a preset white list chain or not; under the condition that the to-be-configured port belongs to the white list chain, adding a permission rule in the white list chain, and releasing the broadcast traffic of the to-be-configured port; and under the condition that the to-be-configured port does not belong to the white list chain, limiting the flow rate of the to-be-configured port according to a speed-limiting chain table rule. The problems that an existing network security technology is not completely suitable for a virtual network environment and is not high in efficiency can be solved.

Description

Technical Field

[0001] This application belongs to the field of network security technology, and specifically relates to a traffic rate limiting method, device, electronic device and storage medium. Background Technology

[0002] Due to design flaws in virtual networks, there is no effective way to prevent malicious tenants from launching scanning attacks using virtual machines within the virtual network. This can impact the overall performance of the virtual network, causing packet loss and increased latency for other legitimate virtual machines within the network, severely affecting the user experience of legitimate tenants, and in severe cases, even causing virtual network failures or crashes.

[0003] Existing network security technologies are not entirely suitable for virtual network environments. Most security technologies for virtual network environments rely on traffic collection and monitoring, which are not very efficient. Summary of the Invention

[0004] The purpose of this application is to provide a traffic limiting method, device, electronic device, and storage medium that can solve the problem that existing network security technologies are not fully applicable to virtual network environments and are inefficient.

[0005] In a first aspect, embodiments of this application provide a traffic limiting method applied to computing nodes in a virtual network, the method comprising: Upon receiving a port configuration message from the control node in the virtual network, the port type of the port to be configured is determined; the port type includes whether the port belongs to a virtual machine. In the case where the port type is a virtual machine. Determine whether the identifier of the port to be configured belongs to a preset whitelist chain; If the port to be configured belongs to the whitelist chain, add an allow rule to the whitelist chain to allow the broadcast traffic of the port to be configured; If the port to be configured is not in the whitelist chain, the traffic rate of the port to be configured is limited according to the rate limiting chain rules.

[0006] Optionally, before determining the port type of the port to be configured upon receiving a port configuration message from the control node in the virtual network, the method further includes: Read the configuration file of the virtual network to determine whether the global rate limiting function of the virtual network is enabled; With the rate limiting function enabled, create the whitelist chain and the rate limiting list rules; Configure the redirection rules for the local traffic processing chain and the security group core chain in the virtual network so that the traffic of the virtual machine is filtered sequentially through the whitelist chain and the rate limiting chain rules.

[0007] Optionally, after configuring the redirection rules for the local traffic processing chain and the security group core chain in the virtual network, the method further includes: Upon receiving a command to disable the rate limiting function, delete the jump rules from the local traffic processing chain and the security group core chain that point to the whitelist chain and the rate limiting list rules; Clear the whitelist chain and the rate-limiting chain, and delete the whitelist chain and the rate-limiting chain.

[0008] Optionally, when the port type is a virtual machine, after limiting the traffic of the port to be configured according to the preset whitelist chain and rate-limiting chain rules, the method further includes: Upon receiving a command to stop the rate limiting function, the rate limiting list rules are cleared to pause the execution of the current rate limiting rules, while the whitelist and the jump rules are retained. When a command to re-enable overall speed limiting is received, the global broadcast speed limiting rule is re-added to the speed limiting list rules.

[0009] Optionally, when the port to be configured is not in the whitelist chain, limiting the traffic rate of the port to be configured according to the rate limiting list rules includes: If the port to be configured does not belong to the whitelist chain, add a marking rule to the outgoing chain of the security group corresponding to the port to be configured. Add a rate limiting rule to the rate limiting chain to limit the broadcast traffic rate of the port to be configured.

[0010] Optionally, the port configuration message includes the port creation message or the port update message. Upon receiving a port creation message or port update message from the control node, determining the port type of the port to be configured includes: Upon receiving the port creation message or the port update message, determine the device owner attribute of the port to be configured based on the port creation message or the port update message; The port type of the port to be configured is determined based on the device owner attribute of the port to be configured.

[0011] Optionally, the whitelist chain and the rate-limiting list rules are created using firewall tools that utilize the security group function in the virtual network.

[0012] Secondly, embodiments of this application provide a traffic limiting device applied to computing nodes in a virtual network, the device comprising: The port determination module is used to determine the port type of the port to be configured when receiving a port configuration message sent by the control node in the virtual network; the port type includes whether the port belongs to a virtual machine; The list recognition module is used to determine whether the identifier of the port to be configured belongs to a preset whitelist chain; The traffic allowance module is used to add an allow rule to the whitelist chain when the port to be configured belongs to the whitelist chain, thereby allowing the broadcast traffic of the port to be configured. The traffic rate limiting module is used to limit the traffic rate of the port to be configured according to the rate limiting list rules when the port to be configured is not in the whitelist chain.

[0013] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the traffic limiting method as described in the first aspect.

[0014] Fourthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the traffic limiting method as described in the first aspect.

[0015] In this embodiment, upon receiving a port configuration message from a control node in the virtual network, the port type of the port to be configured is determined, and subsequent operations are performed only on the virtual machine. This avoids meaningless rate limiting or whitelist verification of traffic for infrastructure services, reduces the rule matching overhead of computing nodes, and improves network processing efficiency. Furthermore, a preset whitelist chain and rate limiting chain rule are used to control broadcast traffic in a hierarchical manner. Broadcast traffic is allowed for virtual machines on the whitelist, ensuring that the broadcast function of trusted traffic in the virtual network is unrestricted. Rate limiting is applied to the broadcast traffic of virtual machines not on the whitelist to prevent malicious or excessive broadcasts from occupying network bandwidth and avoid overall network congestion. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of an application scenario provided in an embodiment of this application.

[0017] Figure 2 This is a flowchart of a traffic limiting method provided in an embodiment of this application.

[0018] Figure 3 This is a flowchart illustrating the specific steps of a traffic limiting method provided in an embodiment of this application.

[0019] Figure 4 This is a schematic diagram of a traffic path provided in an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of another traffic limiting method provided in the embodiments of this application.

[0021] Figure 6 This is a block diagram of a flow rate limiting device provided in an embodiment of this application.

[0022] Figure 7 This is a block diagram of an electronic device provided in an embodiment of this application.

[0023] Figure 8 This is a block diagram of another electronic device provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0026] The OpenStack cloud platform is a cloud platform management project. It is not a single software, but rather an open-source project composed of several main components that provide software for the construction and management of public, private, and hybrid clouds. Neutron (the network service in OpenStack) is the component in the OpenStack project responsible for providing network services. Based on the concept of software-defined networking, it implements resource management under network virtualization.

[0027] Due to design flaws in virtual networks, there is no effective way to prevent malicious tenants from launching scanning attacks using virtual machines within the virtual network. This can impact the overall performance of the virtual network, causing packet loss and increased latency for other legitimate virtual machines within the network, severely affecting the user experience of legitimate tenants, and in severe cases, even causing virtual network failures or crashes.

[0028] Existing network security technologies are not entirely suitable for virtual network environments. Most security technologies for virtual network environments rely on traffic collection and monitoring, which are not very efficient.

[0029] To address the aforementioned problems, this application provides a traffic limiting method, apparatus, electronic device, and storage medium. The traffic limiting method provided by this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0030] First, an application scenario involving an embodiment of this application will be described.

[0031] See Figure 1 The traffic limiting method provided in this application embodiment can be applied to, for example, Figure 1 The system architecture shown is an example of a deployment architecture based on OpenStack to build a virtual network. The system architecture uses an Open vSwitch (OVS), Neutron control nodes (Servers), and Neutron agent nodes (Agents) to realize network connectivity and traffic management for virtual machines within the cluster.

[0032] In some embodiments, vm1 represents a virtual machine (VM) instance running on kernel-based virtual machine (KVM), which is the most common virtual machine carrier in OpenStack, and its lifecycle is managed by the Nova service. Within the virtual machine, eth0 is typically the default network interface name, used to connect the virtual machine to the host machine or other virtual machines for network communication.

[0033] In some embodiments, multiple devices such as qbr, qvb, and qvo represent virtual devices created by Neutron to implement security groups and network isolation. qbr is used to interface with security group rules, implementing traffic filtering via iptables. qvb and qvo are virtual Ethernet pairs connecting qbr and the OVS bridge, enabling traffic forwarding between different network devices. The numbers in multiple devices such as qbr, qvb, and qvo, for example... Figure 1The numbers 12345678-90 and 22345678-90 are unique identifiers for virtual network devices, used to identify the lifecycle of virtual machine ports and network components in OpenStack.

[0034] In one possible implementation, a port ID is generated based on OpenStack Neutron, or a unique identifier (Universally Unique Identifier, or UUID) is extracted and used as the port ID.

[0035] In one possible implementation, the port ID is used to ensure that devices such as tap, qbr, qvb, and qvo belong to the same virtual machine port; when the virtual machine port is created, updated, or deleted, these devices with a unified numerical identifier will perform the operation synchronously to ensure the consistency of network configuration.

[0036] In some embodiments, br-int (OVS bridge) is an internal bridge of OVS, responsible for Layer 2 forwarding of virtual networks, and is a key component for Neutron to implement multi-tenant network isolation.

[0037] In some embodiments, Figure 1 The gray area represents the Virtual Router and Dynamic Host Configuration Protocol (DHCP) services, which are network functions provided by Neutron. They are responsible for inter-subnet routing and Internet Protocol (IP) address allocation, respectively.

[0038] The following is a detailed description of the network configuration method for smart home devices provided in the embodiments of this application.

[0039] Figure 2 This is a flowchart of a traffic limiting method provided in an embodiment of this application. The method is applied to computing nodes in a virtual network and includes the following steps.

[0040] Step 101: Upon receiving a port configuration message from the control node in the virtual network, determine the port type of the port to be configured.

[0041] In this application embodiment, the port type includes whether the port belongs to a virtual machine.

[0042] In some embodiments, the computing nodes in the virtual network can be Figure 1The agent node is shown. For example, in Neutron, it is divided into a server and an agent. The server is located on the control node and receives commands, while the agent is located on the compute node, receives messages from the server and actually creates the port.

[0043] In some embodiments, port configuration messages are used to create new ports or update the configuration of existing ports, and are messages sent by the control node (Server).

[0044] In some embodiments, the device owner attribute of the port to be configured is extracted from the port configuration message; and the port type of the port to be configured is determined based on the device owner attribute of the port to be configured.

[0045] In this embodiment, the port is first identified as belonging to a virtual machine by the device owner attribute. Subsequent control logic is only executed on virtual machine ports, while non-virtual machine ports are skipped.

[0046] Step 102: If the port type is virtual machine, determine whether the identifier of the port to be configured belongs to the preset whitelist chain.

[0047] In this embodiment, the whitelist chain is used to allow trusted traffic.

[0048] In some embodiments, the whitelist chain includes identifiers of multiple trusted ports.

[0049] In some embodiments, the identifier can be a prefix. In the case of a virtual machine port, the prefix of the port to be configured is extracted from the port creation message or port update message; it is then determined whether the prefix of the port to be configured belongs to the prefix in the whitelist chain rules.

[0050] For example, if the port-id is trusted-service-789 and contains a whitelist prefix, and the port-id is detected to match the whitelist rule containing trusted-service-, it is determined that the port belongs to the whitelist chain.

[0051] Step 103: If the port to be configured is in the whitelist chain, add an allow rule in the whitelist chain to allow broadcast traffic of the port to be configured.

[0052] In this embodiment of the application, the allow rule is a rule created in the whitelist that allows broadcast traffic.

[0053] When the port to be configured is in the whitelist chain, the Address Resolution Protocol (ARP) broadcasts, service discovery broadcasts and other traffic sent by the virtual machine corresponding to the port to be configured will be directly allowed by the whitelist chain without being subject to rate limits, thus avoiding being blocked by the overall virtual machine's traffic rate limit rules.

[0054] For example, the Agent executes iptables commands to add a rule to the whitelist chain that allows broadcast traffic for that port.

[0055] Step 104: If the port to be configured is not in the whitelist chain, limit the traffic rate of the port to be configured according to the rate limiting chain rules.

[0056] In this embodiment, the rate-limiting list rule is used to enforce broadcast traffic rate limiting.

[0057] In some embodiments, the rate limiting list rule refers to the rate limiting rule for a specific virtual machine. In other words, the rate limiting list rule refers to the rate limiting rule for the virtual machine corresponding to the port to be configured.

[0058] In some embodiments, if the port to be configured is not in the whitelist chain, the security group creates a broadcast traffic rate limiting rule in the outgoing list to which the port to be configured belongs.

[0059] In one possible implementation, the rate-limiting list rules are used to add rate-limiting rules to outbound broadcast traffic for the virtual machine corresponding to the port to be configured.

[0060] In one possible implementation, the rate-limiting list rules include a single-port security chain sub-chain. If the port to be configured is not in the whitelist chain, a broadcast traffic rate-limiting rule is created for the port to be configured in the single-port security chain sub-chain.

[0061] For example, a single-port security chain subchain is neutron-openvswi-(port-id).

[0062] In some embodiments, the whitelist chain and rate-limiting chain rules are created using firewall tools that utilize the security group functionality in the virtual network.

[0063] Among them, iptables is a firewall tool in Linux systems used to manage network traffic, implemented based on the Netfilter framework in the kernel.

[0064] It's worth noting that Neutron network services include an important feature called Security Groups, which are used to ensure network security within virtual network instances. Tenants can define custom rules within Security Groups to allow or deny specific network traffic, providing additional protection for instances in the cloud environment and preventing virtual machines from being attacked from the outside.

[0065] In some embodiments, single-port security chain subchains are also created using firewall tools that utilize security group functionality within a virtual network.

[0066] In some embodiments of OpenStack, virtual machines restrict their communication with the outside world by binding security groups. OpenStack security groups are implemented using Linux iptables, which allows or denies traffic to and from the virtual machine by issuing corresponding iptables rules. The default rule for the whitelist is to drop all traffic, which has the lowest priority. Traffic that meets the specific rule is allowed by issuing higher-priority accept rules.

[0067] In one possible implementation, security groups can precisely control network access permissions for instances by configuring inbound / outbound rules, similar to a virtual firewall.

[0068] In summary, in this embodiment, upon receiving a port configuration message from the control node in the virtual network, the port type of the port to be configured is determined, and subsequent operations are performed only on the virtual machine. This avoids meaningless rate limiting or whitelist verification of traffic for infrastructure services, reduces the rule matching overhead of computing nodes, and improves network processing efficiency. Furthermore, a preset whitelist chain and rate limiting chain rule are used to control broadcast traffic in a hierarchical manner. Broadcast traffic is allowed for virtual machines on the whitelist, ensuring that the broadcast function of trusted traffic in the virtual network is unrestricted. Rate limiting is applied to the broadcast traffic of virtual machines not on the whitelist to prevent malicious or excessive broadcasts from occupying network bandwidth and avoid overall network congestion.

[0069] Figure 3 This is a flowchart illustrating the specific steps of a traffic limiting method provided in an embodiment of this application. (See also...) Figure 3 This method is applied to computing nodes in a virtual network and includes the following steps.

[0070] Step 201: Read the configuration file of the virtual network to determine whether the global rate limiting function of the virtual network is enabled.

[0071] In some embodiments, the configuration file of the virtual network is read to obtain the fields associated with the global rate limiting function; based on the fields associated with the global rate limiting function, it is determined whether the global rate limiting function of the virtual network is enabled.

[0072] For example, when the Agent starts, it parses openvswitch_agent.ini and reads key configuration items; since global_broadcast_limit_enabled=true, it determines that the global rate limiting function is enabled and executes subsequent configuration.

[0073] Step 202: With the rate limiting function enabled, create a whitelist chain and a rate limiting chain rule.

[0074] In this embodiment, the whitelist chain is used to allow trusted traffic, and the rate-limiting list rules are used to enforce broadcast traffic rate limiting. Here, the rate-limiting list rules refer to the rate-limiting chain and the rules related to using the rate-limiting chain for traffic rate limiting.

[0075] For example, the whitelist chain is neutron-openvswi-whitelist, and the rate-limiting chain is neutron-openvswi-limit.

[0076] In some embodiments, the firewall tool iptables is used to create whitelist chains and rate-limiting lists of rules. iptables is a firewall tool in Linux systems used to manage network traffic, implemented based on the Netfilter framework in the kernel.

[0077] For example, the Agent creates a custom chain locally on the compute node using the iptables command; the whitelist chain is initially empty, and allowed rules will be dynamically added later based on the port whitelist; the rate limiting chain has preset global default rules as a fallback control.

[0078] Step 203: Configure the redirection rules for the local traffic processing chain and the security group core chain in the virtual network, so that the traffic of the virtual machine is filtered by the whitelist chain and the rate limiting chain rule in sequence.

[0079] In this embodiment, both the local traffic processing chain and the security group core chain are iptables chains. For example, the local traffic processing chain is neutron-openvswi-local, and the security group core chain is neutron-openvswi-sg-chain.

[0080] In some embodiments, the local traffic processing chain is an iptables chain on the compute node used to handle the interaction between the local virtual machine and the external network, and is used for forwarding rules and basic filtering of local virtual network traffic.

[0081] For example, when a virtual machine needs to access the DHCP service on the host machine to obtain an IP address, the traffic will first pass through the local traffic processing chain, which allows such local services to communicate through rules while blocking abnormal traffic.

[0082] In some embodiments, the security group core chain is the core iptables chain of Neutron security group functionality, used to enforce virtual machine access control list (ACL) rules to determine which traffic can enter and exit the virtual machine.

[0083] For example, if a virtual machine's security group is configured to only allow ICMP (ping) traffic from the 192.168.1.0 / 24 network segment, the security group core chain will contain the rules corresponding to that configuration.

[0084] In one possible implementation, the Agent modifies the Neutron native chains (neutron-openvswi-local and neutron-openvswi-sg-chain) to add redirection rules to the custom chain.

[0085] In one possible implementation, traffic originating from the virtual machine passes through a chain of filters in the following order: virtual machine network interface card (tap device) → neutron-openvswi-sg-chain (security group rules) → neutron-openvswi-whitelist (whitelist allowance) → neutron-openvswi-limit (rate limiting control) → neutron-openvswi-local (local forwarding) In one possible implementation, if the traffic belongs to a broadcast packet of a whitelisted port, it is ACCEPTed in the whitelist chain and skips the rate limiting chain directly; if the traffic belongs to a broadcast packet of a non-whitelisted port, it is not matched by the whitelist chain and enters the rate limiting chain to perform rate limiting.

[0086] The above technical solution dynamically determines whether to enable the rate limiting function by reading the global rate limiting switch in the configuration file, thus avoiding resource waste. By using independent whitelist chains and rate limiting chains, a layered filtering logic is constructed that first allows trusted traffic and then restricts ordinary traffic, balancing functionality and security. The jump rules of the whitelist chains and rate limiting chains are bound to the local traffic processing chain and the security group core chain to ensure that all virtual machine traffic must go through the filtering process, thus avoiding the vulnerability of some traffic bypassing the rate limiting rules.

[0087] In some embodiments, after step 203, the above-described flow rate limiting method further includes sub-steps A1 to A2.

[0088] Sub-step A1: Upon receiving a command to disable rate limiting, delete the jump rules that point the local traffic processing chain and the security group core chain to the whitelist chain and rate limiting list rules.

[0089] Sub-step A2: Clear the whitelist chain and the rate-limiting chain, and delete the whitelist chain and the rate-limiting chain.

[0090] In one possible implementation, the administrator issues a command to disable the global rate limiting function through the OpenStack Application Programming Interface (API).

[0091] In one possible implementation, the local traffic processing chain and the security group core chain retain only their native functions (such as security group filtering and local forwarding) and are no longer associated with any rate-limiting-related redirects. The whitelist chain and rate-limiting chain and their rules are completely removed, and compute nodes no longer consume resources to maintain these chains. The broadcast traffic of virtual machines is no longer restricted by whitelists and rate-limiting rules and is forwarded directly according to OpenStack's native logic.

[0092] For example, when the agent receives a command to disable the rate limiting function, it deletes the jump rules of neutron-openvswi-local and neutron-openvswi-sg-chain, clears the neutron-openvswi-whitelist and neutron-openvswi-limit chain rules, and deletes the chain.

[0093] By using the above technical solution, the connection between virtual machine traffic and rate limiting logic is completely severed by deleting the jump rules pointing to the whitelist chain and rate limiting chain in the local traffic processing chain and security group chain; clearing the rules of the whitelist chain and rate limiting chain and deleting the chain releases the resource occupation of the iptables rule set.

[0094] Step 204: Upon receiving a port configuration message from the control node in the virtual network, determine the port type of the port to be configured.

[0095] The method for this step has been explained in step 101 above, and will not be repeated here.

[0096] In some embodiments, before step 204, the above-mentioned traffic limiting method may further include: reading the configuration file of the virtual network to obtain the field associated with the global rate limiting function; and determining whether the global rate limiting function of the virtual network is enabled based on the field associated with the global rate limiting function.

[0097] In some embodiments, step 204 may include: Sub-step 2041: Upon receiving a port creation message or a port update message, determine the device owner attribute of the port to be configured based on the port creation message or port update message.

[0098] Sub-step 2042: Determine the port type of the port to be configured based on the device owner attribute of the port to be configured.

[0099] In this embodiment, the port creation message or port update message is the key data carrier for transmitting virtual network port configurations between the control node (NeutronServer) and the computing node (Neutron Agent).

[0100] For example, when a user creates a virtual machine or a virtual network port in OpenStack, NeutronServer generates a port creation message and sends it to the Agent of the target compute node.

[0101] For example, when the network configuration of a virtual machine changes, such as modifying the security group, updating the Quality of Service (QoS) policy, or migrating a node, Neutron Server will generate a port update message and synchronize it to the Agent of the compute node.

[0102] In this embodiment of the application, the device owner attribute can be an attribute value extracted from the device_owner field.

[0103] In one possible implementation, the port creation message or port update message is parsed, and the attribute value of compute:node-01 is extracted from the device_owner field.

[0104] In one possible implementation, the port type of the port to be configured is determined based on the prefix of the device owner attribute.

[0105] For example, if `device_owner` is prefixed with "compute:", it indicates that the port belongs to a virtual machine; if `device_owner` has other values, it belongs to a non-virtual machine port. These other values ​​include: "network:router_interface" indicating a router interface, and "network:dhcp" indicating a DHCP service port.

[0106] In some embodiments, after step 204, the above traffic limiting method may further include: not performing any processing if the port type does not belong to a virtual machine.

[0107] By using the above technical solution, virtual machine ports and non-virtual machine ports can be accurately distinguished based on the device owner's attributes. This ensures that the traffic control policy only applies to virtual machines, avoids ineffective interference with network infrastructure ports, reduces the number of rule matching times and resource consumption of computing nodes, and improves the overall processing efficiency of the virtual network.

[0108] Step 205: If the port type is virtual machine, determine whether the identifier of the port to be configured belongs to the whitelist chain.

[0109] The method for this step has already been explained in step 102 above, and will not be repeated here.

[0110] Step 206: If the port to be configured is in the whitelist chain, add an allow rule in the whitelist chain to allow broadcast traffic to the port to be configured.

[0111] The method for this step has already been explained in step 103 above, and will not be repeated here.

[0112] Step 207: If the port to be configured is not in the whitelist chain, limit the traffic rate of the port to be configured according to the rate limiting chain rules.

[0113] The method for this step has been explained in step 104 above, and will not be repeated here.

[0114] By using the above technical solution and adding allow rules to the whitelist chain, the critical broadcast traffic of trusted virtual machines can be ensured to be unrestricted, thus protecting core business functions.

[0115] In some embodiments, step 207 may include: Sub-step 2071: If the port to be configured is not in the whitelist chain, add a marking rule in the outgoing chain of the security group corresponding to the port to be configured. Sub-step 2072: Add a rate limiting rule to the rate limiting chain to limit the broadcast traffic rate of the port to be configured.

[0116] In one possible implementation, sub-step 2071 may include: marking broadcast traffic in the security group sub-chain corresponding to the port to be configured if the port to be configured does not belong to the whitelist chain.

[0117] In one possible implementation, sub-step 2072 may include: adding a rate-limiting rule for the marked traffic in the rate-limiting chain to limit the broadcast traffic rate of the port to be configured.

[0118] By employing the above technical solution, when the port to be configured is not in the whitelist chain, the broadcast traffic of ordinary virtual machines can be precisely limited through the linkage of traffic marking and rate limiting rules, thus preventing network storms.

[0119] Step 208: Upon receiving a command to stop the rate limiting function, clear the rate limiting list rules to suspend the execution of the current rate limiting rules, while retaining the whitelist list and jump rules.

[0120] In this embodiment, the command to stop the rate limiting function is used to pause the traffic rate limiting function. After receiving a subsequent command to enable overall rate limiting, the traffic rate limiting function can be rewritten to enable it.

[0121] In some embodiments, administrators may temporarily lift broadcast traffic limits due to temporary business needs, such as batch migration of virtual machines, and issue a command to stop global rate limiting through the OpenStack Command Line Interface (CLI).

[0122] In some embodiments, the Agent clears all rate-limiting rules in the neutron-openvswi-limit chain using iptables commands, but does not delete the rate-limiting list rules, making the rate-limiting list an empty chain with no rate-limiting rules in effect.

[0123] For example, upon receiving a command to stop rate limiting, the rules in the `neutron-openvswi-limit` chain are cleared; the rules in the `neutron-openvswi-whitelist` chain remain unchanged, still allowing broadcast traffic on the `trusted-xxx` port. The redirection rules in the local traffic processing chain and the security group core chain that point to the whitelist chain or the rate limiting chain are also left unchanged. In this way, only the rate limiting chain rules are cleared, while the chain structure and redirection relationships are preserved, avoiding the need to reconfigure link associations during subsequent recovery. Simultaneously, the whitelist function remains effective, ensuring that trusted traffic is not affected.

[0124] In some embodiments, the overall rate limit includes: if the traffic emitted by a virtual machine does not exceed its own rate limit, but the traffic emitted by all virtual machines in the virtual network exceeds the overall rate limit, the traffic will still be dropped.

[0125] Step 209: Upon receiving a command to re-enable overall speed limiting, re-add the global broadcast speed limiting rule to the speed limiting list rules.

[0126] In some embodiments, when a temporary service ends, the administrator issues a command to re-enable global rate limiting via the OpenStack CLI.

[0127] In one possible implementation, after receiving the command, the Agent re-adds the global broadcast rate limiting rule to an empty rate limiting chain.

[0128] For example, when the agent receives a command to re-enable overall rate limiting, a new rate limiting rule is added to neutron-openvswi-limit. This allows for quick recovery by adding rules directly to the existing empty chain, without needing to rebuild the chain or modify redirects, thus minimizing network interference.

[0129] With the above technical solution, when a command to stop the rate limiting function is received, only the rate limiting chain rules are cleared while the whitelist chain and jump rules are retained, ensuring that critical functions are not affected during the pause. Pausing and resuming the overall rate limiting function only involves clearing the rate limiting chain rules and re-adding the rules, without rebuilding the chain or modifying the jump relationship. The operation cost is extremely low, which improves the flexibility of the traffic rate limiting method.

[0130] Figure 4 This is a schematic diagram of a traffic path provided in an embodiment of this application. See also... Figure 4 , Figure 4 The document demonstrates OpenStack Neutron's virtual network traffic processing path based on iptables chains, which uses whitelist chains, security group chains, and rate limiting chains to perform layered control over virtual machine traffic, including filtering, policy enforcement, and rate limiting.

[0131] in, Figure 4 The chain is divided into two categories: the system native chain and the Neutron custom chain. The Neutron custom chain includes whitelist chain, security group chain and rate-limited chain.

[0132] For example, the system's native chains include: raw, prerouting, filter, and forward, which are built-in chains of Linux iptables and are responsible for basic traffic forwarding control.

[0133] In this embodiment, the raw chain belongs to the raw table of iptables and is used to handle traffic that does not need to be tracked by the conntrack (connection tracking) mechanism. For example, Figure 4 The combination of raw chains and prerouting primarily serves to mark specific traffic (such as management traffic of OpenStack virtual networks) as "untracked connections" in the early stages of traffic entering a node, thereby improving processing efficiency.

[0134] In this embodiment, the filter chain belongs to the iptables filter table and is the most commonly used chain type for implementing traffic filtering and forwarding control. For example, Figure 4 The filter chain, combined with the forward chain, is responsible for handling forwarding traffic between virtual machines. Meanwhile, Neutron's custom chains (such as whitelist chains, security group chains, and rate limiting chains) are also built on the filter table to implement fine-grained policies for virtual networks.

[0135] For example, Neutron custom chains include neutron-openvswi-PREROUTING, neutron-openvswi-whitelist, neutron-openvswi-local, neutron-openvswi-(port-id), neutron-openvswi-sg-chain, and neutron-openvswi-limit.

[0136] In this embodiment, neutron-openvswi-PREROUTING represents the preprocessing of incoming traffic to the node; neutron-openvswi-whitelist represents the whitelist chain, used to allow broadcast traffic from trusted virtual machines; neutron-openvswi-local represents the local traffic processing chain, used to manage communication between virtual machines and local services; neutron-openvswi-(port-id) represents a single-port security chain sub-chain (one for each virtual machine port), used to process the security group rules for that port; neutron-openvswi-sg-chain represents the security group core chain, used to aggregate the security group rules for all ports; and neutron-openvswi-limit represents the rate-limiting chain, which enforces rate limiting on broadcast traffic.

[0137] It should be noted that the gray part in the figure is a custom chain created by Open Stack Neutron in iptables. The traffic rate limiting method provided in this application provides a new linked list to achieve fine-grained traffic control of the virtual network, as detailed below.

[0138] 1. neutron-openvswi-whitelist: Responsible for allowing broadcast traffic from trusted virtual machines, ensuring that critical broadcast functions of core services (such as cluster nodes) are not restricted.

[0139] 2. neutron-openvswi-(port-id) (single-port security chain sub-chain): Each virtual machine port corresponds to one such chain, which is used to handle the security group rules of that port.

[0140] 3. neutron-openvswi-limit (rate limiting chain): applies rate limits to broadcast traffic from non-whitelisted virtual machines to prevent broadcast storms from consuming network bandwidth.

[0141] In some embodiments, the processing path of virtual machine traffic on the compute node includes: entering the system native chain, whitelist verification, local traffic processing, security group filtering, entering the security chain sub-chain of the corresponding virtual machine port first, broadcast traffic rate limiting, and traffic forwarding and termination.

[0142] For example, Figure 4 The traffic path in the data is shown below: 1. Traffic first enters the raw and prerouting chains, triggering preprocessing in the neutron-openvswi-PREROUTING chain; 2. Traffic enters the whitelist chain. If it belongs to a trusted virtual machine, it is allowed to pass directly, skipping subsequent rate limits. 3. If it does not belong to the category, proceed to the next step; 4. Handle communication between the virtual machine and local services, ensuring the forwarding logic of local interactive traffic; then jump to the security group core chain to execute the security group rules configured by the user; 5. Traffic filtered by the security group enters the rate limiting chain, which applies rate limits to the broadcast traffic of non-whitelisted virtual machines; 6. Once the traffic from all chains is successfully forwarded, the process ends.

[0143] In summary, in this embodiment, by reading the global rate-limiting switch in the configuration file, the system dynamically determines whether to enable the rate-limiting function, avoiding resource waste. Through independent whitelist chains and rate-limiting chains, a layered filtering logic is constructed that first allows trusted traffic and then restricts ordinary traffic, balancing functionality and security. The jump rules of the whitelist chains and rate-limiting chains are bound to the local traffic processing chain and the security group core chain, ensuring that all virtual machine traffic undergoes the filtering process, preventing vulnerabilities where some traffic bypasses the rate-limiting rules. Furthermore, based on the device owner attributes, virtual machine ports and non-virtual machine ports are accurately distinguished, ensuring that the traffic control policy only applies to virtual machines, avoiding impact on network infrastructure. First, it avoids ineffective intervention by reducing the number of rule matches and resource consumption on computing nodes, thereby improving the overall processing efficiency of the virtual network. Second, it adopts a hierarchical rate limiting strategy for traffic. By adding allow rules to the whitelist chain, it ensures that the critical broadcast traffic of trusted virtual machines is not restricted, thus protecting core business functions. When the port to be configured is not in the whitelist chain, the broadcast traffic of ordinary virtual machines is precisely restricted through the linkage of traffic marking and rate limiting rules to prevent network storms. Finally, pausing and resuming the overall rate limiting function only involves clearing the rate limiting chain rules and re-adding the rules. There is no need to rebuild the chain or modify the jump relationship, resulting in extremely low operation costs and improving the flexibility of the traffic rate limiting method.

[0144] Figure 5 This is a schematic diagram of another traffic limiting method provided in an embodiment of this application, as shown below. Figure 5As shown, this method is applied to computing nodes in a virtual network, and the method includes the following steps.

[0145] Step 301: Received a port creation or update message.

[0146] Step 302: Determine if the port belongs to a virtual machine. If the port belongs to a virtual machine, proceed to step 303; otherwise, the process ends.

[0147] Step 303: Determine if the port is in the whitelist. If the port is in the whitelist, proceed to step 304; if the port is not in the virtual machine's whitelist, proceed to step 305.

[0148] Step 304: Create a rule in the whitelist that allows all broadcast traffic.

[0149] Step 305: Create a broadcast traffic rate limiting rule for the single-port security chain subchain of this port.

[0150] In summary, the method and approach combined with security groups adopted in this application embodiment are applicable to the Neutron virtual network environment and have strong practicality. Furthermore, the design method and approach of rule-based linked lists are adopted and implemented using iptables, without introducing additional components and resulting in low performance loss; effectively reducing the possibility of attacks on the virtual network.

[0151] Figure 6 This is a block diagram of a flow rate limiting device provided in an embodiment of this application, such as... Figure 6 As shown, the traffic limiting device is applied to computing nodes in a virtual network, and the traffic limiting device 400 includes the following modules.

[0152] The port determination module 401 is used to determine the port type of the port to be configured when it receives a port configuration message sent by the control node in the virtual network; the port type includes whether the port belongs to a virtual machine. The list recognition module 402 is used to determine whether the identifier of the port to be configured belongs to the preset whitelist chain; The traffic allowance module 403 is used to add an allow rule to the whitelist chain when the port to be configured is in the whitelist chain, and allow the broadcast traffic of the port to be configured. The traffic rate limiting module 404 is used to limit the traffic rate of the port to be configured according to the rules of the rate limiting list when the port to be configured is not in the whitelist chain.

[0153] Optionally, the flow rate limiting device 400 also includes: The configuration reading module is used to read the configuration file of the virtual network and determine whether the global rate limiting function of the virtual network is enabled; The linked list creation module is used to create whitelisted linked lists and rate-limiting linked list rules when the rate-limiting function is enabled. The rule configuration module is used to configure the jump rules of the local traffic processing chain and the security group core chain in the virtual network, so that the traffic of the virtual machine passes through the whitelist chain and the rate limiting chain rule filtering in sequence.

[0154] Optionally, the flow rate limiting device 400 also includes: The rule deletion module is used to delete the jump rules that point to the whitelist chain and rate limit chain rules in the local traffic processing chain and security group core chain when a command to disable rate limiting is received.

[0155] The Clear & Delete module is used to clear whitelisted chains and rate-limited chains, and delete whitelisted chains and rate-limited chains.

[0156] Optionally, the flow rate limiting device 400 also includes: The rule clearing module is used to clear the rate limiting list rules when a command to stop the rate limiting function is received, so that the execution of the current rate limiting rule is suspended, while the whitelist chain and jump rules are retained. The rule-adding module is used to re-add the global broadcast rate limiting rule to the rate limiting list rules when a command to re-enable overall rate limiting is received.

[0157] Optionally, port configuration messages include port creation messages or port update messages, and in the port determination module 401, these include: The first port determination submodule is used to determine the device owner attribute of the port to be configured based on the port creation message or port update message received. The second port determination submodule is used to determine the port type of the port to be configured based on the device owner attribute of the port to be configured.

[0158] Optional, the traffic limiting module 404 includes: The first addition submodule is used to add marking rules in the outgoing chain of the security group corresponding to the port to be configured when the port to be configured does not belong to the whitelist chain; The second submodule is used to add rate limiting rules to the rate limiting chain, thereby limiting the broadcast traffic rate of the port to be configured.

[0159] Optionally, whitelist chains and rate-limiting chains are created using firewall tools that utilize the security group functionality within the virtual network.

[0160] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0161] Optionally, such as Figure 7 As shown, this application embodiment also provides an electronic device 500, including a processor 501 and a memory 502. The memory 502 stores a program or instructions that can run on the processor 501. When the program or instructions are executed by the processor 501, they implement the various steps of the above-described traffic limiting method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0162] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0163] Figure 8 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0164] The electronic device 600 includes, but is not limited to, components such as: radio frequency unit 601, network module 602, audio output unit 603, input unit 604, sensor 605, display unit 606, user input unit 607, interface unit 608, memory 609, and processor 610.

[0165] Those skilled in the art will understand that the electronic device 600 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 610 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0166] The processor 610 is used to implement the above-mentioned traffic limiting method.

[0167] It should be understood that, in this embodiment, the input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042. The GPU 6041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 606 may include a display panel 6061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 607 includes at least one of a touch panel 6071 and other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include a touch detection device and a touch controller. Other input devices 6072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0168] The memory 609 can be used to store software programs and various data. The memory 609 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs, or instructions required for functions (such as sound playback functions, image playback functions, etc.). Furthermore, the memory 609 may include volatile memory or non-volatile memory, or it may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM). The memory 609 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0169] Processor 610 may include one or more processing units; optionally, processor 610 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 610.

[0170] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described traffic limiting method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0171] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0172] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described traffic limiting method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0173] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0174] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0175] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0176] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for limiting traffic flow, characterized in that, The method, applied to computing nodes in a virtual network, includes: Upon receiving a port configuration message from the control node in the virtual network, the port type of the port to be configured is determined; the port type includes whether the port belongs to a virtual machine. If the port type is a virtual machine, determine whether the identifier of the port to be configured belongs to a preset whitelist chain; If the port to be configured belongs to the whitelist chain, add an allow rule to the whitelist chain to allow the broadcast traffic of the port to be configured; If the port to be configured is not in the whitelist chain, the traffic rate of the port to be configured is limited according to the rate limiting chain rules.

2. The method according to claim 1, characterized in that, Before determining the port type of the port to be configured upon receiving a port configuration message from the control node in the virtual network, the method further includes: Read the configuration file of the virtual network to determine whether the global rate limiting function of the virtual network is enabled; With the rate limiting function enabled, create the whitelist chain and the rate limiting chain rules; Configure the redirection rules for the local traffic processing chain and the security group core chain in the virtual network so that the traffic of the virtual machine is filtered sequentially through the whitelist chain and the rate limiting chain rules.

3. The method according to claim 2, characterized in that, After configuring the redirection rules for the local traffic processing chain and the security group core chain in the virtual network, the method further includes: Upon receiving a command to disable the rate limiting function, delete the jump rules from the local traffic processing chain and the security group core chain that point to the whitelist chain and the rate limiting list rules; Clear the whitelist chain and the rate-limiting chain, and delete the whitelist chain and the rate-limiting chain.

4. The method according to claim 2, characterized in that, When the port type is a virtual machine, after limiting the traffic of the port to be configured according to the preset whitelist chain and rate-limiting chain rules, the method further includes: Upon receiving a command to stop the rate limiting function, the rate limiting list rules are cleared to pause the execution of the current rate limiting rules, while the whitelist and the jump rules are retained. When a command to re-enable overall speed limiting is received, the global broadcast speed limiting rule is re-added to the speed limiting list rules.

5. The method according to claim 1, characterized in that, When the port to be configured is not in the whitelist chain, limiting the traffic rate of the port to be configured according to the rate limiting list rules includes: If the port to be configured does not belong to the whitelist chain, add a marking rule to the outgoing chain of the security group corresponding to the port to be configured. Add a rate limiting rule to the rate limiting chain to limit the broadcast traffic rate of the port to be configured.

6. The method according to claim 1, characterized in that, The port configuration message includes either the port creation message or the port update message. Upon receiving a port creation message or port update message from the control node, determining the port type of the port to be configured includes: Upon receiving the port creation message or the port update message, determine the device owner attribute of the port to be configured based on the port creation message or the port update message; The port type of the port to be configured is determined based on the device owner attribute of the port to be configured.

7. The method according to any one of claims 1 to 6, characterized in that, The whitelist chain and the rate-limiting list rules are created using firewall tools that utilize the security group function in the virtual network.

8. A flow rate limiting device, characterized in that, The device, used as a computing node in a virtual network, includes: The port determination module is used to determine the port type of the port to be configured when receiving a port configuration message sent by the control node in the virtual network; the port type includes whether the port belongs to a virtual machine; The list recognition module is used to determine whether the identifier of the port to be configured belongs to a preset whitelist chain; The traffic allowance module is used to add an allow rule to the whitelist chain when the port to be configured belongs to the whitelist chain, thereby allowing the broadcast traffic of the port to be configured. The traffic rate limiting module is used to limit the traffic rate of the port to be configured according to the rate limiting list rules when the port to be configured is not in the whitelist chain.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the traffic limiting method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the traffic limiting method as described in any one of claims 1-7.

Images