A netfilter connection tracking counting and limiting method and apparatus

Abstract

The application discloses a Netfilter connection tracking counting and limiting method and device, and belongs to the technical field of computer data processing. The method comprises the following steps: constructing tracking counting and limiting checking logic for an existing connection tracking module in a Netfilter framework, and triggering after a data packet enters a protocol stack of Linux. In the tracking counting and limiting checking logic, a connection tracking table in the framework is inquired. If the inquiry is not hit, it is judged whether the current system is provided with a counting and limiting function based on a namespace. If yes, corresponding +1 operation is performed on corresponding statistical parameters according to the namespace and a protocol type. The application realizes connection number counting and limiting in the namespace dimension by binding the namespace and the connection tracking depth.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and more specifically to a method and apparatus for Netfilter connection tracking counting and limiting based on namespaces. Background Technology

[0002] Netfilter, as the core framework of the Linux kernel network subsystem, is generally used to implement key network functions such as packet filtering, address translation, and connection tracking. It sets multiple hook points (such as NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_POST_ROUTING, etc.) in the critical paths of the kernel network protocol stack (such as packets entering / leaving the network interface, before and after routing decisions), allowing the registration of callback functions (hook functions) to intercept and process packets.

[0003] Among them, connection tracking (conntrack) is a submodule in the Netfilter framework used to track and maintain network connection states. Its core function is to associate a "connection record" with each packet passing through the firewall, recording the connection's five-tuple (source / destination IP, source / destination port, transport layer protocol), state (such as NEW, ESTABLISHED, RELATED, INVALID, UNTRACKED), and lifecycle information (such as timeout). Through connection tracking, Netfilter can identify whether a packet belongs to an existing connection or a new connection, thereby supporting advanced policies based on connection state (such as only allowing connections in the ESTABLISHED state to pass through the firewall).

[0004] In existing technologies, connection tracking functionality primarily relies on connection record tables, state machines, hook function integration, and timeout management. For traditional Linux kernels, the conntrack table is globally shared, resulting in connection records for all network namespaces being stored in the same global connection table, without distinguishing the network namespace to which the data packets belong. This means:

[0005] (1) Network traffic in multiple namespaces (such as communication between containers or communication between the host and the container) will be mixed and recorded in the same connection table, which makes it impossible to isolate connection state information by namespace;

[0006] (2) When it is necessary to limit the number of connections in a specific namespace (such as to prevent a container from occupying too many connection resources), it is not possible to directly count or control the connection tracking entries based on the namespace dimension. It can only be managed indirectly through global configuration (such as limiting the total number of connections), lacking fine-grained control capabilities.

[0007] At this point, the conntrack processing logic in Netfilter faces practical technical challenges, such as non-isolation of connection tracking records, excessively large granularity of counting and limiting, and insufficient dynamic management capabilities. Therefore, existing solutions either fail to distinguish between namespaces due to global sharing of connection tracking, or lack the ability to dynamically count and limit the number of connections (global threshold / coarse-grained rules), and thus cannot meet the needs of fine-grained management of multi-tenant network connection resources in modern cloud computing and containerization scenarios.

[0008] To address this issue, this application proposes a Netfilter connection tracking counting and limiting method. By binding the namespace with the connection tracking depth, it achieves connection counting and limiting by the namespace dimension, thereby solving the aforementioned technical problems. Summary of the Invention

[0009] The main objective of this invention is to provide a Netfilter connection tracking count and limitation method, which achieves the following: (1) maintaining an independent connection tracking count (or isolated connection table) for each network namespace to accurately distinguish the connection status of different namespaces; (2) supporting real-time statistics of connection counts by namespace dimension (e.g., container A currently has 50 active connections), and setting independent connection count thresholds based on namespaces (e.g., limiting container A to a maximum of 100 connections); (3) monitoring the connection count changes of each namespace in real time and dynamically adjusting the limitation strategy (e.g., adjusting the connection threshold in conjunction with the CPU / memory usage of the namespace), ultimately solving the technical problems mentioned in the background art.

[0010] The present invention solves the above-mentioned technical problems by adopting the following technical solutions:

[0011] A Netfilter connection tracking counting and limiting method involves executing corresponding steps on a computer device. Within the Linux Netfilter framework, tracking counting and limiting check logic is constructed on the existing connection tracking modules. This logic is triggered after a data packet arrives at the network interface card and enters the Linux protocol stack. Specifically, the tracking counting and limiting check logic includes:

[0012] Query the connection tracking table within the Netfilter framework:

[0013] If the query is successful, meaning the current connection is an established connection, then update the status data (such as refreshing the timeout) and mark the data packet as "tracked". If the current connection is a TCP type, then update the current TCP state connection count.

[0014] If the query fails to find a match, it indicates a new connection (such as a TCP SYN packet initiated by the client). It's necessary to determine if the current system has namespace-based counting and limiting capabilities.

[0015] If not, proceed with the traditional processing logic, determine whether the current total number of connections exceeds the maximum connection limit, and perform the usual subsequent processing. If it does, increment the corresponding statistical parameters by 1 according to the namespace and protocol type.

[0016] Preferably, the statistical parameter is incremented by 1 as follows:

[0017] Check if the namespace-based connection tracking limit function in the Netfilter framework is enabled. If it is not enabled, only check if the current total number of connections exceeds the maximum number of connections, and then proceed with the traditional processing logic to determine if the current total number of connections exceeds the maximum number of connections limit and perform the usual subsequent processing. If it is enabled, check if the number of connections in the corresponding namespace exceeds the set maximum total number of connections limit.

[0018] If the maximum total number of connections set by the namespace is exceeded and early_drop in Linux fails, the number of dropped connections will be incremented by 1. If the maximum total number of connections set by the namespace is not exceeded, or if the maximum total number of connections set by the namespace is exceeded but early_drop in Linux succeeds, then the system will continue to check whether the number of connections for the corresponding protocol under the current namespace exceeds the set protocol connection limit.

[0019] If the set protocol connection limit is exceeded and early_drop fails in Linux, the number of dropped protocol connections is incremented by 1; otherwise (if the set protocol connection limit is not exceeded, or if the set protocol connection limit is exceeded but early_drop succeeds in Linux), a new connection record is created and inserted into the connection table.

[0020] Preferably, the conventional processing logic for determining whether the current total number of connections exceeds the maximum connection limit and performing subsequent processing includes:

[0021] Treat the current query as a new connection (such as a TCP SYN packet initiated by the client). In this case, it is necessary to check whether the current number of connections being tracked exceeds the maximum number of connections limit.

[0022] If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly.

[0023] If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a new connection record (status=NEW) is created and inserted into the connection table.

[0024] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0025] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0026] As can be seen from the above technical solution, the present invention provides a method for Netfilter connection tracking counting and limiting. Compared with the prior art, the present invention has the following advantages:

[0027] 1. This invention maintains an independent connection tracking count (or isolated connection table) for each network namespace, which can accurately distinguish the connection status of different namespaces, and ultimately realize connection tracking records based on namespace isolation.

[0028] 2. This invention supports real-time counting of connections by namespace dimension (e.g., container A currently has 50 active connections), and sets independent connection thresholds based on namespace (e.g., limiting container A to a maximum of 100 connections), which can refine the counting and limiting to the namespace granularity.

[0029] 3. This invention achieves connection count statistics and limits at the namespace level by deeply binding namespaces with connection tracking. It can monitor the connection count changes of each namespace in real time, which facilitates dynamic adjustment of the limit strategy (such as adjusting the connection threshold in conjunction with the CPU / memory usage of the namespace).

[0030] It should be understood that the descriptions in this section are not intended to identify key or essential features of embodiments of the invention, nor are they intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Of course, implementing any product of the invention does not necessarily require achieving all of the advantages described above simultaneously. Attached Figure Description

[0031] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0032] Figure 1 This is a schematic diagram of the overall processing logic of the method of the present invention;

[0033] Figure 2 This is a schematic diagram of the Netfilter framework, the logical operating system of the method of the present invention;

[0034] Figure 3 This is a schematic diagram of the processing logic of the conntrack module in the existing netfilter framework. Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] For details in the embodiments, please refer to Figures 1 to 3 .

[0037] The Netfilter connection tracking counting and limiting method proposed in this invention aims to extend the connection counting and limiting functions of the conntrack module based on the network namespace of the Linux kernel's Netfilter conntrack subsystem. It executes corresponding steps on the computer device based on the namespace, builds tracking counting and limiting check logic for the existing connection tracking modules within the Linux Netfilter framework, and triggers it after the data packet arrives at the network card and enters the Linux protocol stack.

[0038] The functionality of the connection tracking module conntrack mainly depends on the following kernel components:

[0039] (a) Conntrack table: Stores the status information of all active connections. It is usually organized in the form of a hash table. The key is a five-tuple (or an extended tuple, such as including the address behind NAT) of the connection, and the value contains the connection's metadata (such as status, timeout, reference count, etc.).

[0040] (b) State machine: Defines the possible states of the connection (e.g., NEW represents the first packet to appear, ESTABLISHED represents an established bidirectional communication connection), and updates the connection state according to the direction of the packets (inbound / outbound) and protocol rules (e.g., TCP three-way handshake);

[0041] (c) Hook function integration: Register conntrack-related processing functions at multiple hook points in netfilter (such as NF_INET_PRE_ROUTING and NF_INET_POST_ROUTING). When a packet passes through these hooks, the conntrack module checks the connection table: if the packet matches an existing connection record, the status is updated and marked as "tracked"; if no matching record is found, a new connection record is created and marked as NEW.

[0042] (d) Timeout Management: Each connection record is associated with a timeout period (which is dynamically adjusted according to the protocol type, such as the ESTABLISHED state timeout for TCP connections is usually 5 days, and for UDP connections it is 30 seconds). The kernel periodically cleans up timeout invalid connections through a timer mechanism to release resources.

[0043] In the traditional Linux kernel (before namespace optimization), the conntrack table is globally shared—connection records for all network namespaces are stored in the same global connection table, regardless of the network namespace to which the data packet belongs.

[0044] The principle of the conntrack function of netfilter in the traditional Linux kernel is as follows: Figure 3 As shown, the specific logic is described below:

[0045] After the data packet arrives at the network card, it enters the Linux protocol stack;

[0046] After entering the Netfilter framework, the inspection logic of the conntrack module (nf_conntrack_in) is triggered within the framework;

[0047] Query the connection tracking table (based on the 5-tuple lookup) to determine if the connection exists;

[0048] If a hit occurs (connection exists), meaning the current connection is already established, update the existing connection state (e.g., refresh the timeout) and mark the packet as "tracked".

[0049] If a connection is not found (the connection does not exist), it indicates a new connection (such as a TCP SYN packet initiated by the client). It is necessary to check whether the current number of connections being tracked exceeds the maximum number of connections.

[0050] If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly.

[0051] If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a connection tracking entry is allocated, a new connection record (state=NEW) is created, the technologist is updated, and finally, the connection is inserted into the hash table.

[0052] Here, `early_drop` is a connection tracking entry pre-cleaning mechanism provided by the Linux kernel. It releases connection table resources by deleting timed-out and inactive connection tracking entries. The triggering command is `echo1> / proc / sys / net / netfilter / nf_conntrack_early_drop`. After execution, the kernel prioritizes cleaning up connection entries with a timeout period exceeding 50%.

[0053] Compared with the existing conntrack module's inspection logic, this application further proposes a namespace-based Netfilter connection tracking counting and limiting method in its implementation. The execution logic is as follows: Figure 1 As shown, it includes:

[0054] <1> Call the conntrack module (nf_conntrack_in) and look up the connection tracking table based on the 5-tuple information;

[0055] <2> Determine if the connection corresponding to the connection tracking table exists. If the connection already exists, update the existing connection (including updating the TCP connection state count nf_conntrack_ns_tcp_state_count) and proceed to the namespace connection count limit check process.

[0056] <3> If the connection does not exist, a global connection count check is performed. Specifically, this checks whether connection count statistics for the namespace are enabled and determines whether CONFIG_NF_CT_PERNS_COUNT is enabled. If enabled, it first checks whether the current total number of connections tracked (ct_count) exceeds nf_conntrack_max.

[0057] If the total number of current connected tracks, ct_count, exceeds nf_conntrack_max, then attempt early_drop. If early_drop fails, return immediately and print an alarm log.

[0058] If the current total number of connection tracks, ct_count, exceeds or does not exceed nf_conntrack_max, or exceeds but early_drop succeeds, then a connection track entry is directly allocated, the counter is updated, and the entry is inserted into the hash table.

[0059] If CONFIG_NF_CT_PERNS_COUNT is not enabled, check if namespace connection count is enabled. Then, based on the namespace and protocol, increment the connection tracking count by 1 and perform the following operations:

[0060] <3-1> Check whether the namespace connection limit is enabled to determine if nf_conntrack_ns_max_enable is enabled:

[0061] <3-1-a> If not enabled, check if the total number of connections tracked exceeds nf_conntrack_max (the kernel already has this function). If it does, decrement the number of connections that have been added by 1.

[0062] <3-1-b>If enabled, check the total number of connections for the namespace and determine if it exceeds nf_conntrack_ns_max:

[0063] <3-1-b-1> If the limit is exceeded, try early_drop. If successful, increase the drop count for the corresponding namespace.

[0064] <3-1-b-2>If the total number of connections in the namespace does not exceed nf_conntrack_ns_max, or exceeds nf_conntrack_ns_max but early_drop fails, then check the connection limit for the specific protocol and determine if it exceeds nf_conntrack_ns_*_max:

[0065] <3-1-b-2-a> If the limit is exceeded, try early_drop. If successful, increase the drop count for the corresponding namespace.

[0066] <3-1-b-2-b>If the connection limit for a specific protocol does not exceed nf_conntrack_ns_*_max, or exceeds nf_conntrack_ns_*_max but early_drop succeeds, then a connection tracking entry is allocated, the counter is updated, and the entry is inserted into the hash table.

[0067] In practical use, the above process is implemented as follows:

[0068] (1) After the data packet arrives at the network card, it enters the Linux protocol stack;

[0069] (2) In the Netfilter framework, trigger the inspection logic of the connection tracing module conntrack;

[0070] (3) Query the connection tracking table within the frame, and you will find:

[0071] (3-1) If the query hits, that is, the current connection is an established connection, then update the status data (such as refresh the timeout time) and mark the data packet as "tracked". If the current connection is of TCP type, then update the current TCP state connection count (nf_conntrack_ns_tcp_state_count).

[0072] Specifically, if the current connection is of type TCP, the nf_conntrack_ns_tcp_state_count field in struct netns_ct is updated. This field is an array structure, with the index corresponding to the TCP connection state (SYN_SENT=1, ESTABLISHED=2, TIME_WAIT=6, etc., following the definition of RFC 793), and the array element value is the number of connections in the corresponding state.

[0073] (3-2) If the query fails, it indicates a new connection (such as a TCP SYN packet initiated by the client). It is necessary to determine whether the current system has namespace-based counting and limiting capabilities:

[0074] (3-2-1) If the counting and limiting function based on namespace is not available, then the traditional processing logic is entered, and it is determined whether the current total number of connections ct_count exceeds the maximum number of connections limit (nf_conntrack_max), and then the corresponding processing is performed in the usual way.

[0075] The standard follow-up processing is as follows:

[0076] Treat the current query as a new connection (such as a TCP SYN packet initiated by the client). In this case, it is necessary to check whether the current number of connections being tracked exceeds the maximum number of connections limit.

[0077] If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly.

[0078] If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a new connection record (status=NEW) is created and inserted into the connection table.

[0079] (3-2-2) If available, then according to the namespace to which the data packet belongs (obtained via skb->dev->nd_net) and the transport layer protocol type (TCP / UDP / ICMP / SCTP), perform an increment operation on the corresponding statistical parameter in the struct netns_ct data structure. The increment operation occurs after the connection tracking table query fails and confirms a new connection, but before the connection record is created. This increment operation specifically includes:

[0080] Check whether the namespace-based connection tracking limitation feature (nf_conntrack_ns_max_enable) is enabled within the framework;

[0081] (3-2-2-1) If the connection tracking limit function based on namespace (nf_conntrack_ns_max_enable) is not enabled, then the traditional processing logic is entered, it is determined whether the current total number of connections ct_count exceeds the maximum number of connections (nf_conntrack_max), and then the normal subsequent processing is performed.

[0082] The standard follow-up processing is as follows:

[0083] Treat the current query as a new connection (such as a TCP SYN packet initiated by the client). In this case, it is necessary to check whether the current number of connections being tracked exceeds the maximum number of connections limit.

[0084] If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly.

[0085] If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a new connection record (status=NEW) is created and inserted into the connection table.

[0086] (3-2-2-2) If the connection tracking limit function based on the namespace (nf_conntrack_ns_max_enable) is enabled, then check whether the number of connections in the corresponding namespace exceeds the set maximum total number of connections limit (nf_conntrack_ns_max).

[0087] (3-2-2-2-1) If the maximum total number of connections set by the namespace is exceeded (nf_conntrack_ns_max), and early_drop fails in Linux, the corresponding number of dropped connections (nf_conntrack_ns_max_drop) is incremented by 1;

[0088] (3-2-2-2-2) If the maximum total number of connections set by the namespace is not exceeded (nf_conntrack_ns_max), or if the maximum total number of connections set by the namespace is exceeded (nf_conntrack_ns_max) but early_drop is successful in Linux, then continue to check whether the number of connections for the corresponding protocol under the current namespace exceeds the set protocol connection limit (nf_conntrack_ns_*_max, where * represents the protocol type);

[0089] (3-2-2-2-2-a) If the set protocol connection limit (nf_conntrack_ns_*_max) is exceeded and early_drop fails in Linux, then the corresponding number of dropped protocol connections (nf_conntrack_ns_*_drop) is increased by 1;

[0090] (3-2-2-2-2-b) If the set protocol connection limit (nf_conntrack_ns_*_max) is not exceeded, or if the set protocol connection limit (nf_conntrack_ns_*_max) is exceeded but early_drop in Linux is successful, then a new connection record (state=NEW) is created and inserted into the connection table;

[0091] In one specific embodiment, the new connection record generally contains the following core fields: 5-tuple information (source IP, destination IP, source port, destination port, protocol type), namespace identifier (netns_id), connection status (NEW / ESTABLISHED, etc.), creation timestamp, timeout, and spinlock protection is used when inserting into the connection table (hash table, where the hash key is a combination of the 5-tuple and the namespace identifier) ​​to avoid concurrent conflicts.

[0092] This logic achieves connection count statistics and limits at the namespace level by deeply binding namespaces with connection tracking. It can monitor the connection count changes of each namespace in real time, which facilitates dynamic adjustment of the limiting strategy (such as adjusting the connection threshold in conjunction with the CPU / memory usage of the namespace).

[0093] In summary, this invention aims to extend the network namespace-based connection counting and limiting functionality of the Netfilter conntrack subsystem in the Linux kernel. This method can not only perform fine-grained statistics on the number of connections and the distribution of connection states (such as ESTABLISHED, TIME_WAIT, etc.) within each namespace, but also provide namespace-aware connection limiting mechanisms (such as maximum number of connections, connection table quotas, and protocol / port limits). Furthermore, it can provide more accurate network connection monitoring and control capabilities for upper-layer applications such as cloud platforms, container orchestration systems (such as Kubernetes CNI), and security group policy engines. Therefore, its enhanced system also possesses stability, controllability, and observability in multi-tenant, high-density connection scenarios. This method can effectively solve the challenges of resource isolation and fine-grained governance in current connection tracking systems in multi-tenant, containerized, and multi-network environments, laying a kernel-level foundation for building a more secure, efficient, and controllable cloud-native network infrastructure.

[0094] On the other hand, the present invention also discloses a system architecture for executing the Netfilter connection tracking counting and limiting method in the above embodiments, such as... Figure 2 As shown, in this system architecture:

[0095] (a) Core layer, nf_conntrack_core.c, which is used to implement the core logic of counting and limiting;

[0096] Specifically, it is used for: (1) connection allocation and release; (2) counting and limiting the maximum number of connections and the number of dropped connections for each namespace; (3) counting and limiting the maximum number of connections and the number of dropped connections for each namespace specific protocol.

[0097] (b) Protocol layer, nf_conntrack_proto_tcp.c, is used for additional processing for special TCP protocols, updating the TCP protocol and recording the number of different TCP connection states;

[0098] (c) Data structure definition layer, used to serve the core layer and protocol layer, defines namespace-based counting and limit parameters;

[0099] (d) Interface layer, nf_conntrack_standalone.c --> sysctl / proc interface, provides an interface for querying and setting configuration parameters, allowing administrators to query and configure for different namespaces, including:

[0100] -Sysctl: / proc / sys / net / netfilter / nf_conntrack_ns_;

[0101] -proc: / proc / net / netfilter / nf_conntrack_ns_.

[0102] In the core layer and protocol layer, the data structure is defined as: conntrack.h --> struct netns_ct, with the following specific definitions:

[0103] Define the namespace and the maximum number of connections for the protocol;

[0104] Define the namespace and protocol for connection count statistics;

[0105] Define the drop count statistics for namespaces and protocols;

[0106] Define the namespace and TCP protocol connection status statistics.

[0107] At this point, in addition to the existing data structure netns_ct in the Linux kernel netfilter submodule, the following attributes (Table 1) have been added:

[0108] Table 1: Attribute Table

[0109]

[0110] The above attributes can achieve the following functions:

[0111] (1) Connection restriction function

[0112] a. Supports enabling and disabling namespace connection restrictions;

[0113] b. Supports setting the maximum total number of connections per namespace;

[0114] c. Supports setting the maximum number of connections for a specific protocol in each namespace;

[0115] (2) Connection counting function

[0116] a. Count the total number of connections for each namespace;

[0117] b. Count the number of connections for each protocol in each namespace;

[0118] c. Count the number of TCP connections in each state for each namespace;

[0119] d. Cumulative statistics on total connections and connections for each protocol;

[0120] (3) Monitoring function

[0121] a. When the number of connections reaches the limit, record the corresponding warning message;

[0122] b. Provide a clear error message indicating which resource in the namespace is subject to the limitation.

[0123] The system supports real-time connection count statistics by namespace dimension (e.g., container A currently has 50 active connections), and allows setting independent connection count thresholds based on namespace (e.g., limiting container A to a maximum of 100 connections), enabling the counting and limiting to be refined to the namespace granularity.

[0124] In a further embodiment, the system provides comprehensive test scripts (using network_namespace.py, a common test script), wherein:

[0125] The test environment has deployed a Linux system that supports the Netfilter framework. The system has enabled the network namespace function and created and configured the server namespace (for starting the UDP server), the router namespace (for configuring connection tracking limit parameters and recording connection tracking counts), and the client namespace (for sending ICMP messages, initiating TCP connections, and initiating UDP connections).

[0126] The system has loaded the Netfilter connection tracing related kernel modules to ensure that the nf_conntrack series of limit parameters, count parameters, TCP connection tracing count parameters, and UDP connection tracing count parameters can be configured, read, and updated normally;

[0127] Furthermore, historical configurations and temporary resources in the test environment were cleared before the test to ensure that the initial test environment was free from interference.

[0128] Based on the above testing environment, the following specific tests were performed:

[0129] (1) test_icmp_count.py, tests the ICMP connection count.

[0130] Disable connection tracking limitation by configuring the system parameter: net.netfilter.nf_conntrack_ns_max_enable=0;

[0131] Record initial connection tracking count:

[0132] In the router namespace, read and record the initial count parameters related to ICMP connection tracking under the Netfilter framework. The specific initial counts are as follows:

[0133] - Total namespace connection track count (nf_conntrack_ns_total): 0;

[0134] - Global connection tracking count (nf_conntrack_count): 0;

[0135] - Namespace ICMP connection real-time count (nf_conntrack_ns_icmp_count): 0;

[0136] -Namespace ICMP connection total count (nf_conntrack_ns_icmp_total): 0;

[0137] After the ICMP message is sent, the counting parameters related to ICMP connection tracking under the Netfilter framework are read and recorded again in the router namespace. The specific counts after testing are as follows:

[0138] - Total namespace connection track count (nf_conntrack_ns_total): 100;

[0139] - Global connection tracking count (nf_conntrack_count): 100;

[0140] - Namespace ICMP connection real-time count (nf_conntrack_ns_icmp_count): 100;

[0141] -Namespace ICMP connection total count (nf_conntrack_ns_icmp_total): 100.

[0142] Count verification: Compare the expected test results with the actual test results. The expected total number of connections (i.e., the expected value of ICMP connection tracking count) is 100, and the actual measured total number of connections (i.e., the global connection tracking count nf_conntrack_count) is 100.

[0143] Resource cleanup: After the test verification is completed, a comprehensive cleanup is performed on the network namespaces, related configuration parameters and temporary test resources created during the test to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0144] In this test, the actual measured total ICMP connection trace count was exactly the same as the expected total number of connections, both being 100. This indicates that the ICMP connection trace counting function under the Netfilter framework is operating normally and counting accurately. It can accurately record the connection trace information generated during ICMP message transmission, meeting the design requirements.

[0145] (2) test_icmp_limit.py, tests ICMP connection limits.

[0146] In the router namespace, enable the connection tracking limitation feature and configure the relevant limitation parameters as follows:

[0147] - Enable namespace connection tracking limits: net.netfilter.nf_conntrack_ns_max_enable=1;

[0148] - Configure the maximum limit threshold for ICMP connection tracking in the namespace: net.netfilter.nf_conntrack_ns_icmp_max=50;

[0149] - Configure the maximum limit threshold for total connection tracking in the namespace: net.netfilter.nf_conntrack_ns_max=100.

[0150] In the router namespace, read and record the initial count parameters related to ICMP connection tracking under the Netfilter framework to ensure that the initial state is free from interference from historical connection counts. The specific initial counts are as follows:

[0151] - Total namespace connection track count (nf_conntrack_ns_total): 0;

[0152] - Global connection tracking count (nf_conntrack_count): 0;

[0153] - Namespace ICMP connection real-time count (nf_conntrack_ns_icmp_count): 0;

[0154] -Namespace ICMP connection total count (nf_conntrack_ns_icmp_total): 0.

[0155] In the client namespace, send 100 ICMP EchoRequest messages (i.e., ICMP ping messages) to the target address corresponding to the router namespace. Ensure that the message sending process is normal, without any interruption or error. The final number of ICMP ping messages successfully sent is 100.

[0156] After the ICMP message is sent, the counting parameters related to ICMP connection tracking under the Netfilter framework are read and recorded again in the router namespace. The count is observed to see if it is limited to a preset threshold range. The specific counts after testing are as follows:

[0157] - Total namespace connection track count (nf_conntrack_ns_total): 50;

[0158] - Global connection tracking count (nf_conntrack_count): 50;

[0159] - Namespace ICMP connection real-time count (nf_conntrack_ns_icmp_count): 50;

[0160] -Namespace ICMP connection total count (nf_conntrack_ns_icmp_total): 50.

[0161] In the router namespace, the ICMP connection tracking count is verified to confirm whether the count meets the limit requirements. Specifically, based on the preset maximum limit threshold for ICMP connection tracking (50), the expected total number of connections (i.e., the expected limit value for ICMP connection tracking count) is 50; the actual measured total number of connections (i.e., the global connection tracking count nf_conntrack_count) is 50, and the actual count is consistent with the expected limit value.

[0162] After the test verification is completed, a comprehensive cleanup is performed on the network namespaces created during the test, the configured connection tracking limit parameters, and temporary test resources to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0163] In this test, after configuring the maximum ICMP connection tracing limit threshold of 50 and the total connection tracing limit threshold of 100 in the router namespace, 100 ICMP ping packets were sent to it. The actual measured total connection tracing count was 50, which is completely consistent with the preset ICMP connection tracing limit threshold (expected total number of connections).

[0164] The test results above show that the ICMP connection tracking limitation function under the Netfilter framework operates normally and limits accurately. When the number of ICMP packets sent exceeds the preset threshold, it can stably limit the connection tracking count within the threshold range, effectively achieving the limitation effect of ICMP connection tracking and meeting the design requirements.

[0165] (3) test_tcp_count.py, tests the TCP connection count.

[0166] Create the network namespace required for testing, complete the basic configuration of the namespace, and ensure that the namespace can function properly;

[0167] Enable the system IP forwarding function and configure the system parameter: net.ipv4.ip_forward=1 to ensure network connectivity between different network namespaces;

[0168] A network namespace connectivity test was performed, and the test result showed that connectivity was successful, confirming that the namespaces can communicate normally over the network, meeting the prerequisites for establishing a TCP connection.

[0169] Configure the connection tracking limit threshold to 1000 in the router namespace to ensure that the connection tracking function can operate normally without interference exceeding the threshold, providing stable conditions for TCP connection tracking count testing.

[0170] Within the router namespace, all initial count parameters related to TCP connection tracing under the Netfilter framework are read and recorded to define the initial test state. The specific initial counts are as follows:

[0171] - Total namespace connection track count (nf_conntrack_ns_total): 1;

[0172] - Namespace TCP connection total count (nf_conntrack_ns_tcp_total): 0;

[0173] - Global connection tracking count (nf_conntrack_count): 1;

[0174] - Namespace TCP connection real-time count (nf_conntrack_ns_tcp_count): 0;

[0175] - Namespace TCP established connection count (nf_conntrack_ns_tcp_established_count): 0;

[0176] - Namespace TCP time-wait connection count (nf_conntrack_ns_tcp_time_wait_count): 0.

[0177] Initiate 500 TCP connection requests from the client namespace to the target address corresponding to the router namespace, ensuring that the TCP connection establishment process is normal and there are no connection failures, interruptions or other abnormalities. In the end, the number of TCP connections successfully established is 500.

[0178] After the TCP connection is established, read and record all the counting parameters related to TCP connection tracking under the Netfilter framework in the router namespace again, and observe the changes in the counting parameters. The specific counts after the TCP connection are as follows:

[0179] - Total namespace connection track count (nf_conntrack_ns_total): 501;

[0180] - Namespace TCP connection total count (nf_conntrack_ns_tcp_total): 500;

[0181] - Global connection tracking count (nf_conntrack_count): 501;

[0182] - Namespace TCP connection real-time count (nf_conntrack_ns_tcp_count): 500;

[0183] - Namespace TCP established connection count (nf_conntrack_ns_tcp_established_count): 0;

[0184] - Namespace TCP time-wait state connection count (nf_conntrack_ns_tcp_time_wait_count): 500.

[0185] In the router namespace, the accuracy of TCP connection tracking counts was verified by comparing the expected test results with the actual test results. The specific verification results are as follows:

[0186] The actual test results were completely consistent with the expected results, and the TCP connection trace count was accurate.

[0187] - Expected total number of TCP connections (i.e., expected cumulative count of TCP connections in the namespace): 500;

[0188] - Expected total number of connections (i.e., expected total connection trace count for the namespace): 501;

[0189] - Actual total number of TCP connections (i.e., measured cumulative count of TCP connections in the namespace): 500;

[0190] - Actual total number of connections (i.e., the measured total connection trace count for the namespace): 501.

[0191] After the TCP connection trace count verification is completed, a comprehensive cleanup is performed on the network namespaces created during the test, the configured system parameters, the established TCP connections and temporary test resources to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0192] In this test, after enabling IP forwarding and confirming normal network namespace connectivity, 500 TCP connections were initiated from the client namespace. The actual measured total number of TCP connections was 500, and the total number of connections was 501, which was completely consistent with the preset expected results. At the same time, the detailed counting parameters of each TCP connection tracking (established connection count, time-waiting state connection count) all conformed to the state characteristics of TCP connections.

[0193] The test results above show that the TCP connection tracking and counting function under the Netfilter framework operates normally and counts accurately. It can accurately record the number of TCP connections established and the connection status under different states, fully meeting the design expectations and achieving accurate counting of TCP connection tracking.

[0194] (4) test_tcp_limit.py, tests TCP connection limits.

[0195] Create the network namespace required for testing, complete the basic configuration of the namespace, and ensure that the namespace can function properly;

[0196] Enable the system IP forwarding function and configure the system parameter: net.ipv4.ip_forward=1 to ensure network connectivity between different network namespaces;

[0197] A network namespace connectivity test was performed, and the test result showed that connectivity was successful, confirming that the namespaces can communicate normally over the network, meeting the prerequisites for establishing a TCP connection.

[0198] Configure the connection tracking limit threshold to 1000 in the router namespace to ensure that the connection tracking function can operate normally without interference exceeding the threshold, providing stable conditions for TCP connection tracking count testing.

[0199] Within the router namespace, all initial count parameters related to TCP connection tracing under the Netfilter framework are read and recorded to define the initial test state. The specific initial counts are as follows:

[0200] - Total namespace connection track count (nf_conntrack_ns_total): 1;

[0201] - Namespace TCP connection total count (nf_conntrack_ns_tcp_total): 0;

[0202] - Global connection tracking count (nf_conntrack_count): 1;

[0203] - Namespace TCP connection real-time count (nf_conntrack_ns_tcp_count): 0;

[0204] - Namespace TCP established connection count (nf_conntrack_ns_tcp_established_count): 0;

[0205] - Namespace TCP time-wait connection count (nf_conntrack_ns_tcp_time_wait_count): 0.

[0206] Initiate 500 TCP connection requests from the client namespace to the target address corresponding to the router namespace, ensuring that the TCP connection establishment process is normal and there are no connection failures, interruptions or other abnormalities. In the end, the number of TCP connections successfully established is 500.

[0207] After the TCP connection is established, read and record all the counting parameters related to TCP connection tracking under the Netfilter framework in the router namespace again, and observe the changes in the counting parameters. The specific counts after the TCP connection are as follows:

[0208] - Total namespace connection track count (nf_conntrack_ns_total): 501;

[0209] - Namespace TCP connection total count (nf_conntrack_ns_tcp_total): 500;

[0210] - Global connection tracking count (nf_conntrack_count): 501;

[0211] - Namespace TCP connection real-time count (nf_conntrack_ns_tcp_count): 500;

[0212] - Namespace TCP established connection count (nf_conntrack_ns_tcp_established_count): 0;

[0213] - Namespace TCP time-wait state connection count (nf_conntrack_ns_tcp_time_wait_count): 500.

[0214] In the router namespace, the accuracy of TCP connection tracking counts was verified by comparing the expected test results with the actual test results. The specific verification results are as follows:

[0215] The actual test results were completely consistent with the expected results, and the TCP connection trace count was accurate.

[0216] - Expected total number of TCP connections (i.e., expected cumulative count of TCP connections in the namespace): 500;

[0217] - Expected total number of connections (i.e., expected total connection trace count for the namespace): 501;

[0218] - Actual total number of TCP connections (i.e., measured cumulative count of TCP connections in the namespace): 500;

[0219] - Actual total number of connections (i.e., the measured total connection trace count for the namespace): 501.

[0220] After the TCP connection trace count verification is completed, a comprehensive cleanup is performed on the network namespaces created during the test, the configured system parameters, the established TCP connections and temporary test resources to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0221] In this test, after enabling IP forwarding and confirming normal network namespace connectivity, 500 TCP connections were initiated from the client namespace. The actual measured total number of TCP connections was 500, and the total number of connections was 501, which was completely consistent with the preset expected results. At the same time, the detailed counting parameters of each TCP connection tracking (established connection count, time-waiting state connection count) all conformed to the state characteristics of TCP connections.

[0222] The test results above show that the TCP connection tracking and counting function under the Netfilter framework operates normally and counts accurately. It can accurately record the number of TCP connections established and the connection status under different states, fully meeting the design expectations and achieving accurate counting of TCP connection tracking.

[0223] (5) test_udp_count.py, tests the UDP connection count.

[0224] The test scenario was clearly defined as having the connection tracking limitation function disabled. The system core parameter was configured as net.netfilter.nf_conntrack_ns_max_enable=0 to ensure that the connection tracking limitation function was turned off and would not affect the accuracy of the UDP connection tracking count.

[0225] Start the UDP server in the server namespace, complete the server initialization configuration, and ensure that the server can listen for UDP connection requests normally, providing receiving end support for subsequent UDP connection initiation in the client namespace.

[0226] Within the router namespace, read and record all initial count parameters related to UDP connection tracking under the Netfilter framework to define the initial test state and ensure no interference from historical connection counts. The specific initial counts are as follows:

[0227] - Total namespace connection track count (nf_conntrack_ns_total): 0;

[0228] - Global connection tracking count (nf_conntrack_count): 0;

[0229] - Namespace UDP connection real-time count (nf_conntrack_ns_udp_count): 0;

[0230] -Namespace UDP connection total count (nf_conntrack_ns_udp_total): 0.

[0231] In the client namespace, initiate 100 UDP connection requests to the UDP server that has been started in the server namespace. Ensure that the UDP connection initiation process is normal and there are no abnormal situations such as connection failure or interruption. The final number of successfully established UDP connections is 100.

[0232] After the UDP connection is established, read and record all UDP connection tracking parameters related to the Netfilter framework in the router namespace again, and observe the changes in the counting parameters. The specific UDP connection counts are as follows:

[0233] - Total namespace connection track count (nf_conntrack_ns_total): 100;

[0234] - Global connection tracking count (nf_conntrack_count): 100;

[0235] - Namespace UDP connection real-time count (nf_conntrack_ns_udp_count): 100;

[0236] - Namespace UDP connection total count (nf_conntrack_ns_udp_total): 100.

[0237] In the router namespace, the accuracy of UDP connection tracking counts was verified by comparing the expected test results with the actual test results. The specific verification results are as follows:

[0238] The actual test results were completely consistent with the expected results, and the UDP connection trace count was accurate.

[0239] - Expected total number of connections (i.e., expected total connection trace count for the namespace): 100;

[0240] - Expected total number of UDP connections (i.e., expected cumulative count of namespace UDP connections): 100;

[0241] - Actual total number of connections (i.e., measured total connection trace count for the namespace): 100;

[0242] - Actual total number of UDP connections (i.e., the measured cumulative count of namespace UDP connections): 100.

[0243] After the UDP connection tracking count verification is completed, stop the UDP server in the server namespace, and thoroughly clean up the network namespaces created during the test, the configured system parameters, the established UDP connections and temporary test resources to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0244] In this test, without enabling the connection tracking limit function, after starting the UDP server, 100 UDP connections were initiated from the client namespace. The actual measured total number of connections and the total number of UDP connections were both 100, which was completely consistent with the preset expected results. All UDP connection tracking count parameters could accurately match the number of UDP connections established.

[0245] The test results above show that the UDP connection tracking and counting function under the Netfilter framework operates normally and counts accurately. It can accurately record the establishment of UDP connections, is not affected by the connection tracking limitation function (in the off state), fully meets the design expectations, and can achieve accurate counting of UDP connection tracking.

[0246] (6) test_udp_limit.py, tests UDP connection limits

[0247] The test scenario is clearly defined as enabling the UDP connection tracing limit feature. The core configuration is a namespace UDP connection tracing maximum limit threshold of 50. The specific parameter configurations are as follows (all configured in the router namespace):

[0248] - Enable namespace connection tracking limits: net.netfilter.nf_conntrack_ns_max_enable=1;

[0249] - Configure the maximum limit threshold for namespace UDP connection tracking: net.netfilter.nf_conntrack_ns_udp_max=50;

[0250] - Configure the maximum limit threshold for total connection tracking in the namespace: net.netfilter.nf_conntrack_ns_max=100.

[0251] Start the UDP server in the server namespace, complete the server initialization configuration, and ensure that the server can listen for UDP connection requests normally, providing stable receiving end support for subsequent UDP connections initiated by the client namespace.

[0252] Within the router namespace, read and record all initial count parameters related to UDP connection tracking under the Netfilter framework to define the initial test state and ensure no interference from historical connection counts. The specific initial counts are as follows:

[0253] - Total namespace connection track count (nf_conntrack_ns_total): 0;

[0254] - Global connection tracking count (nf_conntrack_count): 0;

[0255] - Namespace UDP connection real-time count (nf_conntrack_ns_udp_count): 0;

[0256] -Namespace UDP connection total count (nf_conntrack_ns_udp_total): 0.

[0257] In the client namespace, initiate 100 UDP connection requests to the UDP server that has been started in the server namespace, ensuring that the UDP connection initiation process is normal, without interruption, abnormal error, or other issues, and complete all UDP connection initiation operations.

[0258] After the UDP connection is initiated, read and record all UDP connection tracking parameters related to the Netfilter framework in the router namespace again, and observe whether the counting parameters are limited to the preset threshold range. The specific UDP connection counts are as follows:

[0259] - Total namespace connection track count (nf_conntrack_ns_total): 50;

[0260] - Global connection tracking count (nf_conntrack_count): 50;

[0261] - Namespace UDP connection real-time count (nf_conntrack_ns_udp_count): 50;

[0262] - Namespace UDP connection total count (nf_conntrack_ns_udp_total): 50.

[0263] The effectiveness and counting accuracy of the UDP connection tracking and limiting function were verified within the router namespace. The expected test results were compared with the actual test results. The specific verification results are as follows:

[0264] The actual test results were completely consistent with the expected limits, and the UDP connection tracking and limiting function worked normally and the counts were accurate.

[0265] - Expected total number of connections (i.e., expected limit of total namespace connection trace count): 50;

[0266] - Expected total number of UDP connections (i.e., expected limit for cumulative namespace UDP connection count): 50;

[0267] - Actual total number of connections (i.e., measured total namespace connection trace count): 50;

[0268] - Actual total number of UDP connections (i.e., the measured cumulative count of namespace UDP connections): 50.

[0269] After verifying the UDP connection tracking and limiting function, stop the UDP server in the server namespace, and thoroughly clean up the network namespaces created during the test, the configured connection tracking and limiting parameters, the initiated UDP connections, and temporary test resources to ensure that the test environment is restored to its initial state and to avoid interference with subsequent tests.

[0270] In this test, after configuring the router namespace namespace UDP connection tracking maximum limit threshold to 50 and the total connection tracking maximum limit threshold to 100, 100 UDP connection requests were initiated from the client namespace to the UDP server. The actual measured total number of connections and the total number of UDP connections were both limited to 50, which was completely consistent with the preset expected limit values.

[0271] The test results above show that the UDP connection tracking limitation function under the Netfilter framework operates normally and limits accurately. When the number of UDP connection initiations exceeds the preset limit threshold, it can stably limit the UDP connection tracking count and the total connection tracking count within the threshold range, effectively achieving the limitation effect of UDP connection tracking and fully meeting the design expectations.

[0272] At this point, by maintaining an independent connection tracking count (or isolated connection table) for each network namespace, the connection status of different namespaces can be accurately distinguished, ultimately achieving connection tracking records isolated based on namespaces.

[0273] In summary, this method effectively solves the technical challenges of non-isolated connection records, excessively coarse granularity of counting and limiting, and insufficient dynamic management capabilities in existing Netfilter framework connection tracking technologies. By deeply binding network namespaces with connection tracking and maintaining independent connection tracking counts (or isolated connection tracking tables) for each network namespace, it not only achieves namespace-level isolation of connection tracking records, ensuring that connection records in different namespaces are independent and do not interfere with each other, accurately distinguishing the connection states of different namespaces and improving the accuracy and clarity of connection state management, but also enables fine-grained connection counting and limiting based on the namespace dimension. It can accurately count the number of various types of connections under different transport layer protocols in each namespace and supports independently configuring connection limit thresholds for each namespace, breaking through the limitations of coarse-grained control in existing technologies and effectively avoiding the abuse of connection resources.

[0274] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0275] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0276] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the Netfilter connection tracking counting and limiting methods described in the above embodiments.

[0277] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0278] This application also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, communication interface, and memory communicate with each other via the communication bus.

[0279] Memory, used to store computer programs;

[0280] The processor, when executing a program stored in memory, implements the Netfilter connection tracking counting and limiting method described above.

[0281] The communication bus mentioned in the above-mentioned electronic devices can be a standard bus for interconnecting peripheral components or an extended industrial standard structure bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0282] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0283] The memory may include random access memory or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0284] The processors mentioned above can be general-purpose processors, including central processing units, network processors, etc.; they can also be digital signal processors, application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0285] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0286] 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, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0287] Furthermore, it should be noted that the technical solutions proposed in the above embodiments are implemented based on the Linux kernel (version 5.14.0) and the Netfilter framework (version 1.8.7). All functional extensions are completed through conventional kernel module programming methods, without modifying the core kernel logic or relying on undisclosed kernel interfaces. The core function of "namespace-based counting and limiting" in the technical solution is implemented through standardized kernel development processes such as extending the struct netns_ct data structure, registering Netfilter hook functions, and implementing the sysctl configuration interface. The relevant data structure definitions (such as nf_conntrack_ns_max, nf_conntrack_ns_tcp_count) and function call logic (such as the nf_conntrack_in hook function extension) are all explicitly disclosed. The ICMP / TCP / UDP connection counting and limiting tests provided in the embodiments are all completed in the network namespace environment of a Kubernetes cluster (version 1.24.0). The core logic of the test script (network_namespace.py) is implemented through conventional network programming and can be reproduced by running it in a standard Python environment. For aspects not elaborated in detail in this invention, such as the "triggering conditions of the early_drop mechanism" and the "hash query logic of the connection tracking table," the native implementation logic of the Linux kernel is adopted, which is common knowledge to those skilled in the art and can be clearly understood without additional limitations. This invention ensures that the implementation logic of the technical solution is clear and unambiguous by defining the functional boundaries of the core layer, protocol layer, data structure definition layer, and interface layer in a layered manner.

[0288] Furthermore, those skilled in the art should understand that in the actual use of the embodiments of this application, there may be preset thresholds used as the basis for judging the corresponding technical solutions. These thresholds are conventional technical means commonly used in the field to implement functions such as state judgment, condition recognition, and control logic switching. The specific values, setting basis, value selection methods, determination methods, and adjustment rules of the thresholds involved in this technical solution are all conventional technical choices that can be reasonably determined by those skilled in the art based on conventional technical factors such as actual application scenarios, system working states, characteristics of the detection object, hardware performance parameters, and functional requirements, through conventional experiments, calibrations, and debugging. The specific setting and adjustment of the aforementioned thresholds will not cause this technical solution to be unimplementable as a whole, nor will it affect the realization of the core concept and the achievement of the technical effects of this technical solution.

[0289] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, in the embodiments of this invention, "multiple" refers to two or more. Moreover, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

Claims

1. A Netfilter connection tracking counting and limiting method, comprising constructing tracking counting and limiting check logic on the existing connection tracking module within the Netfilter framework, and triggering it after the data packet enters the Linux protocol stack, characterized in that, In the aforementioned logic, the connection tracking table within the Netfilter framework is queried. If the query fails, it is determined whether the current system has namespace-based counting and limiting capabilities. If it does, the corresponding statistical parameters are incremented by 1 according to the namespace and protocol type. The specific operations include: Check if the namespace-based connection tracking limit function in the Netfilter framework is enabled. If enabled, check if the number of connections in the corresponding namespace exceeds the set maximum total number of connections limit. If the maximum total number of connections set by the namespace is not exceeded, or if the maximum total number of connections set by the namespace is exceeded but early_drop is successful, then check whether the number of connections for the corresponding protocol under the current namespace exceeds the set protocol connection limit; If the set protocol connection limit is exceeded and early_drop fails, the corresponding number of dropped protocol connections is incremented by 1; otherwise, a new connection record is created and inserted into the connection table. During the connection tracking table query process within the Netfilter framework, if the query is successful, the status data, including the refresh timeout, is updated, and the data packet is marked as tracked.

2. The Netfilter connection tracking counting and limiting method as described in claim 1, characterized in that, During the connection tracking table lookup process within the Netfilter framework, if the query is successful and the current connection is of TCP type, the current TCP state connection count is updated.

3. The Netfilter connection tracking counting and limiting method as described in claim 1, characterized in that, If the current system does not have namespace-based counting and limiting capabilities, then check whether the current number of connections being tracked exceeds the maximum connection limit: If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly. If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a new connection record is created and inserted into the connection table.

4. The Netfilter connection tracking counting and limiting method as described in claim 1, characterized in that, If the namespace-based connection tracking limit feature within the Netfilter framework is not enabled, then check whether the current number of connections being tracked exceeds the maximum connection limit: If the maximum number of connections is exceeded and early_drop fails, the connection will not be recorded, an alarm log will be printed, and the process will return directly. If the maximum number of connections is not exceeded, or if the maximum number of connections is exceeded but early_drop is successful, a new connection record is created and inserted into the connection table.

5. The Netfilter connection tracking counting and limiting method as described in claim 1, characterized in that, If the number of connections to the corresponding namespace exceeds the set maximum total number of connections, and early_drop fails in Linux, the number of dropped connections will be incremented by 1.

6. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the Netfilter connection tracking counting and limiting method as described in any one of claims 1 to 5.

Images