Multi-load balancing device path backtracking control method and device and electronic device

Abstract

The application provides a multi-load balancing device path backtracking control method and device and electronic equipment, relates to the field of network transmission control, and can save the entry source address in the entry direction of the application firewall, and replace the exit source address with the entry source address in the exit direction of the application firewall, so that the request message and the response message always pass through the same load balancing device without depending on the related configuration tool, the connection tracking module and the policy routing, and the connection state consistency and the service stability of the application firewall system are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of network transmission control, and in particular to a method, apparatus, and electronic device for path backtracking control of multiple load balancing devices. Background Technology

[0002] In some current network architectures, Web Application Firewalls (WAFs) are used for security inspection and protection of HTTP / HTTPS traffic. These WAFs are deployed between load balancers and backend servers. Client request packets are forwarded from the load balancer to the WAF, which then inspects the request and forwards it to the backend server. The backend server's response packet is then returned to the WAF, which needs to correctly forward the response packet back to the original load balancer.

[0003] However, because application firewalls may connect to multiple different load balancers through multiple interfaces, and routing decisions only select the appropriate exit point based on the destination IP without considering the source interface of the request packet, response packets may be forwarded to another load balancer. Since the corresponding connection state information does not exist on that load balancer, this can lead to session mismatches, causing serious problems such as connection failures and service interruptions.

[0004] Existing technologies mainly rely on a combination of configuration tools, connection tracking modules, and policy routing to redirect traffic when solving such problems. However, these technologies still suffer from drawbacks such as high complexity, high performance overhead, and long paths, making it difficult to meet the needs of high-performance firewalls. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a multi-load balancing device path backtracking control method, device and electronic device, which can save the ingress source address in the ingress direction of the application firewall and replace the egress source address with the ingress source address in the egress direction of the application firewall. Thus, without relying on related configuration tools, connection tracking modules and policy routing, request packets and response packets always pass through the same load balancing device, which greatly improves the connection state consistency and service stability of the application firewall system.

[0006] In a first aspect, embodiments of the present invention provide a multi-load balancing device path backtracking control method, applied to an application firewall system containing multiple load balancing devices, wherein the application firewall system is positioned between the client and the server; the method includes: When a client's request message is detected to have arrived at the first interface of the application firewall via the first load balancer, the first source address of the first load balancer is saved to the preset site table. When the response message after the server responds to the request message arrives at the second interface in the application firewall, the second source address of the second load balancing device corresponding to the second interface is obtained, and the second source address is updated to the first source address through the site table. The response message, controlled by the first source address, is returned to the client after passing through the first load balancer.

[0007] Optionally, the step of saving the first source address of the first load balancer to a preset site table after detecting that a client's request packet has passed through the first load balancer and arrived at the first interface of the application firewall includes: The protocol type and flag bits of the request messages arriving at the first interface are identified; Only when the request message is a TCP synchronization message, extract the five-tuple identifier, the first source address of the first load balancer, and the index information of the first interface corresponding to the message; The first source address and index information are saved to the preset site table using the 5-tuple identifier as the retrieval key.

[0008] Optionally, before saving the first source address of the first load balancer to a preset site table, a site traffic matching step is also included: After performing prefix matching on the target address of the request message using a preset prefix matching strategy, the bitmap array index corresponding to the target address is obtained; Match the target port number of the request message using the bitmap array index; The first source address saving operation is performed only if both the target address and the target port number match successfully.

[0009] Optionally, the target port number of the request message can be matched using a bitmap array index, including: Active index tags for target addresses are constructed based on a prefix matching strategy, and inactive index tags for target addresses are constructed based on the site table. After matching the bitmap array index with the request message using the inactive index flag, the active index flag controls the matching of the bitmap array index with the target port number of the request message.

[0010] Optionally, obtain the second source address of the second load balancing device corresponding to the second interface, and update the second source address to the first source address through the site table, including: Real-time acquisition of the connection table associated with the site table based on the 5-tuple identifier; When the inbound interface recorded in the connection table is different from the second interface, the corresponding second load balancer is determined based on the second interface in the application firewall. Obtain the second source address of the second load balancer. If the second source address is different from the first source address, update the second source address to the first source address through the site table.

[0011] Optionally, the step of controlling the response message to return to the client after passing through the first load balancer via the first source address includes: The response message is redirected to the send queue of the first interface according to the first source address; The application firewall sends a queue control response message to the first load balancer. The first load balancer controls the response message to be returned to the client according to the callback format of the request message.

[0012] Optionally, after saving the first source address of the first load balancing device to a preset site table, the method further includes: Scan all connection records in the site table at preset time intervals and obtain the message type corresponding to each target connection record; If the message type of the target connection record is a reset message type, then delete the target connection record; If the message type of the target connection record is an end message type, then delete the target connection record after the first timeout period; If the target connection record's message type is a synchronization message type, then the target connection record will be deleted after the second timeout period.

[0013] Optionally, this method is implemented based on the flow control framework of the extended Berkeley packet filter; The application firewall system attaches the same inbound processing policy of the filter to the inbound direction of each business interface through the inbound hook point, which is used to execute the address recording logic of the request packet; The application firewall system attaches the same outbound processing policy of the filter to the outbound direction of each business interface through outbound hook points, which is used to execute the address update and forwarding control logic of the response packet; All business interfaces share the same kernel-mode site table.

[0014] In a second aspect, the present invention provides a multi-load balancing device path backtracking control device, applied to an application firewall system comprising multiple load balancing devices, wherein the application firewall system is positioned between the client and the server; the device includes: Inbound control module: When a client's request packet is detected to have passed through the first load balancer and reached the first interface of the application firewall, the first source address of the first load balancer is saved to a preset site table. Outbound control module: When the response packet after the server response request packet arrives at the second interface in the application firewall, it obtains the second source address of the second load balancer corresponding to the second interface and updates the second source address to the first source address through the site table; Path backtracking module: used to control the response message to return to the client after passing through the first load balancer via the first source address.

[0015] Thirdly, embodiments of the present invention also provide an electronic device, which includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the multi-load balancing device path backtracking control method provided in the first aspect.

[0016] This invention provides a method, apparatus, and electronic device for path backtracking control of multiple load balancing devices, applied to an application firewall system containing multiple load balancing devices, with the application firewall system positioned between the client and server. During the backtracking control of the packet path between the client and server, when a client's request packet is detected to have reached the first interface of the application firewall via the first load balancing device, the first source address of the first load balancing device is saved to a preset site table. When a response packet from the server responding to the request packet is detected to have reached the second interface of the application firewall, the second source address of the second load balancing device corresponding to the second interface is obtained, and the second source address is updated to the first source address through the site table. Finally, the first source address is used to control the response packet to return to the client after passing through the first load balancing device. This method can save the ingress source address in the ingress direction of the application firewall and replace the egress source address with the ingress source address in the egress direction, thereby ensuring that request and response packets always pass through the same load balancing device without relying on related configuration tools, connection tracking modules, and policy routing, significantly improving the connection consistency and service stability of the application firewall system.

[0017] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 A flowchart of a multi-load balancing device path backtracking control method provided in an embodiment of the present invention; Figure 2 A flowchart of another multi-load balancing device path backtracking control method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating a path backtracking control method for multiple load balancing devices provided in an embodiment of the present invention; Figure 4 This is a connection state transition diagram in a multi-load balancing device path backtracking control method provided in an embodiment of the present invention; Figure 5 This is a configuration hot update timing diagram in a multi-load balancing device path backtracking control method provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a multi-load balancing device path backtracking control device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0021] icon: 100 - Inbound control module; 200 - Outbound control module; 300 - Path backtracking module; 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. 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.

[0023] To facilitate understanding of this embodiment, a multi-load balancing device path backtracking control method disclosed in this embodiment of the invention will first be introduced. This method is applied to an application firewall system containing multiple load balancing devices, and the application firewall system is set between the client and the server; specifically, the method is as follows: Figure 1 As shown, it includes: Step S101: When it is detected that the client's request message has arrived at the first interface of the application firewall through the first load balancer, the first source address of the first load balancer is saved to the preset site table.

[0024] When a request message sent by a client is forwarded by the first load balancer and enters the first network interface of the application firewall, site traffic matching is first performed at the ingress of that interface. After the matching is successful, the protocol flag of the message is identified. When the message is determined to be a synchronous connection message, the five-tuple information of the message, the source MAC address (i.e., the first source address) corresponding to the first load balancer, and the index information of the first interface are extracted. Using the five-tuple as a unique retrieval key, the above-mentioned ingress-related information is written into the preset kernel-mode site table, completing the connection initialization and retention of ingress path information, providing a basis for path backtracking of subsequent response messages.

[0025] Step S102: When the response packet after the server responds to the request packet arrives at the second interface in the application firewall, the second source address of the second load balancing device corresponding to the second interface is obtained, and the second source address is updated to the first source address through the site table.

[0026] The backend server generates a response message in response to the aforementioned request. After the response message is routed through the kernel's native routing decision, it is forwarded to the outbound (egress) hook point of the second network interface of the application firewall. The server extracts the five-tuple information corresponding to the response message and uses this five-tuple as the search key to query the site table to obtain the first source address and inbound interface information in the corresponding connection record. At the same time, the server obtains the second interface to which the current response message is to be sent and the destination address information of the second load balancer that the message is currently pointing to. When it is determined that the current outbound interface is inconsistent with the recorded inbound interface, the server replaces the destination MAC address of the response message with the address of the corresponding second load balancer and replaces it with the first source address stored in the site table, thus completing the correction of the message forwarding address.

[0027] Step S103: The response message is controlled by the first source address and returned to the client after passing through the first load balancing device.

[0028] After the destination address is corrected, the response message is directly delivered to the sending queue of the first interface recorded in the site table, skipping the kernel's regular routing table lookup and rule matching process. This allows the response message to be sent directly to the first load balancer via the first interface, and the first load balancer will then forward the response message to the corresponding client. This ensures that the request message and response message are always transmitted through the same load balancer, ensuring that the session connection state matches and avoiding connection failures and service interruptions caused by asymmetric routing.

[0029] Optionally, when a client's request packet is detected to have arrived at the first interface of the application firewall via the first load balancer, step S101, which saves the first source address of the first load balancer to a preset site table, includes the following steps: Step S201: Identify the protocol type and flag bits of the request message arriving at the first interface.

[0030] When a client request packet is forwarded to the first interface of the application firewall via the first load balancer, the packet first triggers the ingress hook of that interface. The eBPF (extended Berkeley Packet Filter) then performs layered parsing: First, based on the dual-active configuration mechanism of LPM longest prefix matching combined with port bitmap, it matches whether the destination IP address and destination port of the packet belong to the preset protected site traffic range. If a match is found, it further parses the layer 2 Ethernet header, layer 3 IP header, and layer 4 TCP (Transmission Control Protocol) header information of the packet to confirm the transport layer protocol type of the packet. At the same time, it reads the flag field of the TCP header and identifies the packet through the flag field.

[0031] Step S202: Only when the request message is a TCP synchronization message, extract the five-tuple identifier, the first source address of the first load balancer, and the index information of the first interface corresponding to the message.

[0032] The entry information collection is performed only when the current request message is identified as a TCP SYN message (the first packet of connection establishment): the source IP address, destination IP address, source port number, destination port number and transport layer protocol number of the message are extracted and combined to generate a five-tuple identifier that can uniquely identify the TCP connection; at the same time, the source MAC address corresponding to the first load balancer is extracted from the Ethernet header of the message as the first source address, and the interface index information of the first interface receiving the message is read from the kernel message buffer.

[0033] For non-SYN (Synchronize) TCP packets, the connection activity status is updated only if a corresponding connection record already exists in the preset site table, and no new connection entries are added; entry information recording is not performed for non-TCP packets, IP fragmented non-first packets, and forwarded traffic with source ports rewritten by proxies.

[0034] Step S203: Save the first source address and index information to the preset site table using the 5-tuple identifier as the retrieval key.

[0035] Using the extracted 5-tuple identifier as the retrieval key, the connection information, including the first source MAC address, the first interface index, the connection initialization state flag FLOW_SYN_SEEN, and the packet arrival timestamp, is written as corresponding values ​​into a pre-defined kernel-mode site connection table implemented using the BPF_MAP_TYPE_HASH type. This completes the persistent storage of connection initialization and ingress path information. The site connection table is shared by all service interfaces of the application firewall, uniformly storing all connection records across interfaces, providing core data for subsequent path consistency verification and redirection of outbound response packets.

[0036] Optionally, before saving the first source address of the first load balancer to a preset site table, a site traffic matching step is also included, specifically including: Step S301: After performing prefix matching on the target address of the request message using the preset prefix matching strategy, the bitmap array index corresponding to the target address is obtained.

[0037] In real-world scenarios, the ActiveLpmIndex active configuration index in the site table can be read to determine the currently effective site configuration branch. In the LPM (Longest Prefix Match) prefix tree corresponding to this branch, the longest prefix match operation is performed on the destination IP address of the request packet. IPv4 packets and IPv6 packets are matched with independent ipv4_lpm prefix trees and ipv6_lpm prefix trees, respectively.

[0038] If the destination IP address matches any of the pre-set site IP prefixes, the bitmap array index corresponding to that IP prefix is ​​output. The LPM prefix tree and the bitmap array jointly store two sets of configurations that are backups of each other, supporting the coexistence of old and new configurations and providing underlying support for uninterrupted hot updates of configurations.

[0039] Step S302: Match the target port number of the request message using the bitmap array index.

[0040] Based on the bitmap array index obtained in step S301, locate the corresponding port bitmap array in the site table, use the destination port number of the request message as the offset, verify the status of the flag bit at the corresponding position in the bitmap array, and determine whether the current destination port belongs to the preset protected site service port range.

[0041] Step S303: Only if the target address and the target port number both match successfully, perform the subsequent first source address saving operation.

[0042] Only when the destination IP address prefix is ​​successfully matched and the destination port number is matched in the bitmap array is the current request packet determined to be protected site service traffic, triggering subsequent TCP packet flag identification, automatic path backtracking processing logic for saving the source address and inbound interface information of the first load balancer device; if the IP address does not match the corresponding site prefix, or the port number does not match, it is determined to be non-site traffic, and the packet is directly allowed to pass without performing any path backtracking related connection record and correction operations.

[0043] Optionally, matching the target port number of the request message using a bitmap array index includes the following steps: Step S401: Construct active index tags for the target address based on the prefix matching strategy, and construct inactive index tags for the target address based on the site table.

[0044] Two independent, backup sets of IP prefix matching rules and port bitmap arrays are pre-defined in the kernel-mode site table, defined as the active configuration index and the inactive configuration index, respectively. A global ActiveLpmIndex active index flag variable is set to point to the currently effective configuration branch. IPv4 packets and IPv6 packets correspond to independent dual-active longest prefix matching trees and bitmap arrays, respectively. The two configuration branches share completely consistent matching logic, differing only in the stored site IP prefix and port bitmap data. This allows the old and new site configurations to coexist in the site table for a long time, providing underlying data support for uninterrupted configuration updates.

[0045] Step S402: After matching the bitmap array index with the request message using the inactive index flag, control the bitmap array index to match the target port number of the request message using the active index flag.

[0046] When it is necessary to update the site IP and port configuration, the new site IP prefix rules and port bitmap data are first written to the configuration branch corresponding to the inactive index mark. The existing configuration data pointed to by the active index is not modified throughout the process, ensuring that the site matching logic of the current business traffic continues to run normally and is not affected by the configuration update operation.

[0047] After all the new configurations have been written and verified to be correct, the value of ActiveLpmIndex is modified through an atomic operation, switching the original inactive index to the new active configuration index. After the switch is completed, all subsequent request packets will be executed based on the new active configuration branch for target address prefix matching and target port number bitmap matching. The old configuration corresponding to the original active index is synchronously converted to an inactive state and will be delayed for recycling after all existing connections have completed their lifecycles. This achieves zero packet loss and uninterrupted service during the entire hot update of site configurations.

[0048] Optionally, obtain the second source address of the second load balancing device corresponding to the second interface, and update the second source address to the first source address through the site table, including the following steps: Step S501: Obtain the connection table associated with the site table in real time based on the 5-tuple identifier.

[0049] When the response message returned by the backend server is forwarded via the kernel's native routing and flows to the egress hook point of the second network interface of the application firewall, the Layer 2 Ethernet header, Layer 3 IP header, and Layer 4 TCP header of the message are first parsed to extract the five-tuple identifier (source IP address, destination IP address, source port number, destination port number, and transport layer protocol number) corresponding to the request message. Using this five-tuple identifier as the search key, the kernel-mode connection table (flow_map, implemented using BPF_MAP_TYPE_HASH type) shared by all business interfaces is queried to obtain the inbound interface index, the first source MAC address of the first load balancer, and other entry information stored in the corresponding connection record, providing data basis for subsequent path consistency verification.

[0050] Step S502: When it is detected that the inbound interface recorded in the connection table is different from the second interface, the corresponding second load balancer is determined according to the second interface in the application firewall.

[0051] Read the interface index of the second interface to which the current response message is to be sent, and compare it with the inbound interface index recorded in the connection table. If they match, it means that the kernel routing result matches the request entry point, and no path correction is required. The message is directly allowed to be sent from the current interface. If they do not match, it is determined to be an asymmetric routing scenario. The response message will be forwarded to the second load balancer device that is not the original entry point. The connection will fail because the device has no corresponding session state, thus triggering the subsequent address correction and interface redirection process.

[0052] Step S503: Obtain the second source address of the second load balancing device. If the second source address is different from the first source address, update the second source address to the first source address through the site table.

[0053] Extract the current destination MAC address of the response message (i.e., the second source address corresponding to the second load balancer), and compare it with the first source MAC address of the first load balancer recorded in the connection table. If they match, skip the address modification operation and directly execute the subsequent interface redirection. If they do not match, call the eBPF kernel helper function bpf_skb_store_bytes() to directly modify the original byte content of the message in the kernel message buffer (sk_buff) and replace the destination MAC address of the response message with the first source MAC address.

[0054] This step employs a "compare first, modify later" performance optimization strategy, triggering auxiliary function calls only when MAC addresses do not match. This avoids unnecessary kernel-mode operations, reduces CPU overhead in packet processing, and adapts to the high-performance forwarding requirements of high-throughput WAFs.

[0055] Optionally, step S103, in which the response message is returned to the client after passing through the first load balancing device via the first source address, includes the following steps: Step S601: Redirect the response message to the sending queue of the first interface according to the first source address.

[0056] In specific scenarios, after conditionally correcting the destination MAC address of the response packet, the eBPF kernel helper function `bpf_redirect()` can be called. Using the first interface index recorded in the connection table as the target parameter, the response packet to be sent is directly redirected to the kernel sending queue corresponding to the first interface. This process skips the entire link of Linux kernel's native routing table lookup, policy routing matching, and iptables rule traversal. Forwarding decisions are completed solely by the eBPF program in kernel space, significantly shortening the packet processing path, reducing single-packet forwarding latency, and adapting to the high-throughput forwarding requirements of high-performance application firewalls.

[0057] Step S602: Send a queue control response message from the application firewall to the first load balancer device.

[0058] After the kernel sending queue of the first interface obtains the redirected response message, it executes the message transmission based on the Ethernet Layer 2 forwarding mechanism. Since the destination MAC address of the response message has been corrected to the first source MAC address of the first load balancer, the message will be accurately delivered from the first physical interface of the application firewall to the corresponding first load balancer, avoiding the problem of the response message being missent to the second load balancer due to the kernel's native routing.

[0059] Step S603: Use the first load balancing device to control the response message to return to the client according to the callback format of the request message.

[0060] After receiving the response message, the first load balancer matches the original request connection record initiated by the corresponding client in its locally maintained TCP connection session table. Following the original forwarding path and session callback rules of that request, it forwards the response message to the client terminal that initiated the request. This ensures that the request and response messages are transmitted entirely through the same load balancer, guaranteeing a complete match between the session states at both ends. This fundamentally solves problems such as session mismatch, connection failure, and service interruption caused by asymmetric routing in multi-load balancer deployment scenarios.

[0061] Optionally, after saving the first source address of the first load balancing device to a preset site table, the method further includes the following steps: Step S701: Scan all connection records in the site table at preset time intervals and obtain the message type corresponding to each target connection record.

[0062] The kernel-mode shared connection table (flow_map) is scanned at preset time intervals. The connection state field, TCP packet type flag, and corresponding activity timestamp stored in each connection record are read one by one to identify the lifecycle stage of each target connection record, which serves as the basis for subsequent differentiated recycling processing.

[0063] Step S702: If the message type of the target connection record is a reset message type, then delete the target connection record.

[0064] If a TCP reset (RST) message type corresponding to the target connection record is identified, it indicates that the TCP connection has been forcibly terminated abnormally and there is no subsequent legitimate interaction data. Therefore, the target connection record is immediately deleted from the connection table to release the corresponding kernel memory resources in a timely manner and avoid the invalid connection state from lingering and occupying storage resources for a long time.

[0065] Step S703: If the message type of the target connection record is an end message type, then delete the target connection record after the first timeout period.

[0066] If a TCP FIN packet type corresponding to the target connection record is detected, indicating that the connection has entered the normal closing process, the first timeout period is started for that connection. During the first timeout period (configurable to 5 seconds), the connection activity status is continuously monitored. Once the timeout expires and no subsequent interaction packets are received, the target connection record is deleted. This short-term waiting mechanism ensures that the other end receives the final acknowledgment packet, preventing the normal closing process from being unexpectedly interrupted.

[0067] Step S704: If the message type of the target connection record is a synchronization message type, then delete the target connection record after the second timeout period.

[0068] If a TCP synchronization (SYN) packet type corresponding to the target connection record is identified, meaning the connection has only observed a connection establishment request and has not entered a half-open connection state (not yet in the bidirectional normal communication stage), a second timeout is started for that connection. After the second timeout period (configurable to 5 seconds) expires, the target connection record is deleted. This mechanism can effectively clean up invalid half-open connections generated by SYN scans, connection establishment failures, etc., preventing them from occupying connection table resources for a long time, and improving system memory utilization and anti-attack capabilities.

[0069] Optionally, this multi-load balancing device path backtracking control method is implemented based on the traffic control (tc) framework of the extended Berkeley Packet Filter (eBPF). It adopts a pure kernel-mode closed-loop processing architecture that separates the control plane and data plane, and can complete the automatic last-hop backtracking function without relying on iptables configuration tools, conntrack connection tracking modules, and policy routing systems. Its program mounting and data sharing mechanism is as follows: The application firewall system mounts the same eBPF inbound processing program on the inbound hook point of the TC framework on the inbound direction of all business interfaces. This program uniformly executes the logic of recording request packet entry information, such as site traffic matching, TCP SYN packet identification, five-tuple identifier construction, collection of load balancer source MAC address and inbound interface index, and connection state initialization writing, to ensure that the inbound traffic of each business interface follows completely consistent processing rules.

[0070] The application firewall system mounts the same eBPF outbound processing program on the outbound hook point of the TC framework in the outbound direction of all business interfaces. This program uniformly executes the logic of response packet address update and forwarding control, such as connection table lookup, consistency verification between outbound and inbound interfaces, conditional correction of destination MAC address, and cross-interface packet redirection and delivery, so as to realize standardized path backtracking processing of outbound traffic across all interfaces.

[0071] All business interfaces share the same site connection table stored in the Linux kernel. The site connection table is implemented using an eBPF Map of type BPF_MAP_TYPE_HASH, with the TCP connection 5-tuple as the unique retrieval key. It uniformly stores information such as the source MAC address, inbound interface index, connection lifecycle status, and activity timestamp of all connections. This enables unified connection tracking, state management, and differentiated garbage collection control for cross-interface asymmetric routing traffic, providing core data support for consistent matching of request and response paths in scenarios with multiple load balancing devices.

[0072] Based on this, such as Figure 2 The flowchart shown is another method for path backtracking control of multiple load balancing devices. This method is implemented based on the eBPF tc traffic control framework and is executed entirely in a closed loop in the Linux kernel space. It does not rely on iptables configuration tools, conntrack connection tracking modules, or policy routing. The overall process is divided into two main stages: ingress packet processing and egress packet processing. The specific process logic is as follows: I. Ingress message processing stage.

[0073] This phase is executed by the eBPF inbound processing program mounted on the inbound hooks of each business interface. Its core functions are to identify site traffic, record inbound path information, and initialize connection status. The process steps are as follows: 1. Site Traffic Matching. After the process starts, the first step is to match the site IP and port of the request packets arriving at the inbound interface. The matching adopts an LPM prefix tree + Bitmap dual-active mechanism: the destination IP address of the packet is matched by the longest prefix matching algorithm, and if a match is found, the port bitmap is matched with the corresponding index to confirm whether the packet belongs to the protected site business traffic; the dual-active mechanism is used to support hot configuration updates and ensure that business traffic is not interrupted during the update process.

[0074] 2. TCP SYN packet determination. After completing site matching, the TCP flag bits of the packet are identified to determine whether the current packet is a TCP SYN connection establishment packet: If it is a non-SYN packet: only the status of the corresponding connection that already exists in the connection table is updated, the connection activity time is refreshed, and then the packet is allowed to continue to be forwarded to the backend server. This design avoids the repeated creation of connection entries for non-first packets, saving kernel storage and computing resources.

[0075] If it is a TCP SYN packet: extract the source MAC address of the packet (i.e., the MAC address of the first upstream load balancer) and the inbound interface index, use the packet 5-tuple as the search key, create a connection entry in the kernel-mode shared connection table (flow_map), update the connection state from the initial NONE state to the SYN_SEEN state, and complete the connection initialization; then allow the packet to continue to be forwarded to the backend server.

[0076] II. Outbound (Egress) Message Processing Stage.

[0077] This phase is executed by the eBPF outbound processing program mounted on the outbound hooks of each business interface. Its core function is to verify path consistency, perform path correction, and ensure that the response message returns to the corresponding load balancer along the original request entry point. The process steps are as follows: 1. Connection table lookup. After the response packet returned by the backend server arrives at the outbound interface, the five-tuple identifier of the packet is extracted first. Using this five-tuple as the search key, the kernel-mode shared connection table is queried to obtain the inbound interface index, the source MAC address of the upstream original load balancer, and other entry information from the corresponding connection record.

[0078] 2. Egress / Ingress Interface Consistency Check. Compare whether the egress interface of the current response message is consistent with the ingress interface in the connection record: If the two match, it means that the kernel's native routing result matches the request entry point. There is no need to perform path correction; the packet can be sent directly from the current interface.

[0079] If the two are inconsistent: it is determined to be an asymmetric routing scenario, and the response packet will be missent to a non-original second load balancer, triggering a path correction process: first, compare the current destination MAC address of the packet with the source MAC address of the original load balancer stored in the connection record; if the MAC addresses are inconsistent, call the bpf_skb_store_bytes() kernel helper function to modify the destination MAC address of the packet, replacing it with the source MAC address of the original load balancer; this "compare first, then modify" optimization design can avoid unnecessary kernel operations and reduce the performance overhead of packet processing; call the bpf_redirect() kernel helper function to directly redirect the response packet to the sending queue of the inbound interface, skipping the kernel's regular routing decision and rule matching across the entire link, and achieving accurate forwarding across interfaces.

[0080] 3. Connection State Maintenance. After completing packet forwarding or redirection, the connection state in the connection table is updated synchronously: the first response packet updates the connection state to ESTABLISHED (connection established); upon receiving a TCP FIN packet, the state is updated to FIN_SEEN (close waiting); upon receiving a TCP RST packet, the connection entry is directly deleted, thereby achieving state management throughout the entire lifecycle of the TCP connection.

[0081] 4. The single message path backtracking process ends.

[0082] This process significantly shortens the packet processing path through pure kernel-mode closed-loop processing, a lightweight design with only SYN connection establishment, and conditional MAC correction and direct redirection mechanisms. At the same time, it is combined with a dual-active site matching mechanism to achieve hot updates of site configurations without service interruption. This fundamentally solves the problems of session mismatch, connection failure, and service interruption caused by asymmetric routing in multi-load balancer deployment scenarios, and adapts to the high throughput and low latency service requirements of high-performance web application firewalls.

[0083] The above method is described below with a specific implementation plan, running on a Linux kernel environment of version 4.19.90 and above, supporting x86 and ARM architectures. The ALH function is configured as a global switch for the application firewall, affecting all configured site IPs and ports. Currently, it supports WAF (Application Firewall) route redirection and reverse proxy modes, and is disabled by default.

[0084] This method employs a design that separates the control plane and data plane during implementation. The data plane runs entirely in eBPF kernel mode, achieving pure kernel-mode closed-loop processing. Its flowchart is as follows: Figure 3 As shown.

[0085] The control plane (corresponding to user space) includes: The eBPF application loading / attach module is responsible for loading, compiling, and attaching eBPF applications to the ingress / egress hooks of various business interfaces, as well as detaching and managing the application's lifecycle.

[0086] Site configuration distribution / hot update module: responsible for distributing site IP and port configurations to eBP Map, and implementing hot updates of configurations through LPM prefix tree + Bitmap dual-active mechanism, without interrupting current traffic during the update process.

[0087] Connection GC recycling / cleanup module: responsible for periodically scanning the connection table (flow_map), recycling timed-out connections according to multi-level timeout policies, and controlling the size of the eBPF Map.

[0088] The data plane (corresponding to eBPF kernel mode) includes: Ingress Hook (tc ingress): Mounted on the inbound direction of the network interface card, responsible for matching site traffic, learning request entry information (source MAC, inbound interface), and creating and updating connection status.

[0089] Site table (LPM+Bitmap dual-active configuration): Stores site IP and port matching rules, supports IPv4 / IPv6 dual stack, and achieves dual-active index switching through ActiveLpmIndex.

[0090] Egress Hook (tc egress): Mounted on the outgoing side of the network interface card, responsible for querying the connection table, determining the consistency between the outgoing and incoming interfaces, performing path correction (bpf_redirect redirection + MAC modification), and maintaining the connection state.

[0091] The flow map is of type BPF_MAP_TYPE_HASH, with a 5-tuple as the key, and stores information such as connection status, MAC address, interface index, and timestamp.

[0092] Debug control table (debug_map): of type BPF_MAP_TYPE_ARRAY, stores global control information such as debug switches.

[0093] External components include: F5 load balancer: Connects to application firewalls through multiple interfaces to provide load balancing functionality.

[0094] Backend server: Receives request traffic that has passed through the application firewall.

[0095] The core design principle of this framework is that all business interfaces are mounted with the same set of eBPF programs, sharing a unified connection table (Map) to achieve unified connection tracking and recycling control for cross-interface asymmetric traffic. The specific functions and implementation details of each module are as follows: 1. Data plane - Connecting state machine.

[0096] The connection state machine defines four states that drive the complete lifecycle of a connection: FLOW_NONE: The initial state where no connection has been established.

[0097] FLOW_SYN_SEEN: SYN packet detected, source MAC and ingress interface recorded, awaiting response.

[0098] FLOW_ESTABLISHED: Bidirectional communication has started and the connection is working properly.

[0099] FLOW_FIN_SEEN: FIN packet seen, entering the decay phase, awaiting final recycling.

[0100] State transition rules: NONE → (Ingress receives SYN) → SYN_SEEN - SYN_SEEN → (First Egress packet) → ESTABLISHED - ESTABLISHED → (Receive FIN) → FIN_SEEN - ESTABLISHED → (Receive RST) → Delete connection - FIN_SEEN → (FIN timeout) → Delete connection; the specific connection state transition relationship is as follows: Figure 4 As shown, no further details will be provided.

[0101] 2. Data plane - Join table (flow_map) data structure.

[0102] The join table uses the BPF_MAP_TYPE_HASH type, with a 5-tuple as the key (flow_key) and join information as the value (flow_info): The flow_key structure contains: ip_version (4 or 6), proto (protocol type), source / destination IP address (supports IPv4 and IPv6), and source / destination port number.

[0103] The flow_info structure contains: state (connection state), fin_seen (FIN flag), client_mac[ETH_ALEN] (client MAC address), ingress_ifindex (SYN ingress index), egress_ifindex (first request egress index), last_seen_ns (last activity timestamp), and fin_seen_ns (FIN timestamp).

[0104] Connection table specifications: Maximum number of connections 3,000,000, memory usage approximately 200MB.

[0105] 3. Data plane - site traffic matching mechanism.

[0106] Site traffic matching uses an LPM prefix tree + Bitmap dual-active mechanism: IP matching: For IPv4 and IPv6, the longest prefix matching is performed using the ipv4_lpm and ipv6_lpm prefix trees respectively. Once found, the corresponding Bitmap array index is obtained.

[0107] Port matching: Based on the Bitmap index obtained from the IP address, match the port number in the Bitmap.

[0108] Active-active mechanism: The active configuration index is found through ActiveLpmIndex, and the old and new configurations coexist. When the configuration is updated, the new configuration is first written to the inactive index, and then ActiveLpmIndex is atomically switched to point to the new configuration, so as to achieve uninterrupted flow during the configuration update process.

[0109] Configure hot update process as follows Figure 4 As shown, Figure 4 The complete process of hot update of dual-active configuration is shown in the form of a sequence diagram, from Figure 4 As can be seen, the configuration switch is a single atomic operation, and traffic matching will not fail during the coexistence of the old and new configurations.

[0110] 4. Data plane - Egress path correction and MAC modification strategy.

[0111] The core of Egress path correction is the bpf_redirect() function call, which directly redirects data packets to the sending queue of the target interface without going through the regular routing decision.

[0112] The MAC modification strategy employs a "compare first, then modify" optimization: before modifying the destination MAC, it compares the current destination MAC with the recorded source MAC; only if they do not match is bpf_skb_store_bytes() called to modify it. This strategy avoids unnecessary eBPF helper function calls and reduces performance overhead.

[0113] 5. Control plane - eBPF program loading and attach.

[0114] The control plane is responsible for loading, mounting, and lifecycle management of eBPF (filter) programs. By mounting the same set of eBPF programs on the ingress / egress of multiple interfaces and sharing a unified map, unified connection tracking and recycling control for cross-interface, asymmetric traffic is achieved.

[0115] 6. Control plane - Linkage garbage collection (GC) strategy.

[0116] The control plane employs a multi-level differentiated timeout recovery strategy, with recovery priorities ranging from high to low: RST packet (abnormal termination): Upon receiving a TCP RST packet, the connection is immediately deleted. RST indicates that the connection has been forcibly terminated, and there will be no further valid data. Data is immediately recycled to avoid leaving any invalid state residue.

[0117] FIN packet (normal closure): Upon receiving a FIN packet, it is not deleted immediately. Instead, it is marked as entering the closure phase, and a fast timeout mechanism is enabled, with a timeout period of 5 seconds. The brief wait after the FIN ensures that the other end receives the final ACK.

[0118] SYN-only connection (not established): Only when SYN packets are observed not entering the normal data stage, a short timeout of 5 seconds is used to reclaim the connection, preventing half-open connections from being occupied for a long time due to SYN scanning, connection failures, etc.

[0119] Normal idle connection: Based on the time of the most recent data activity, the timeout is 60 seconds. While ensuring connection availability, the number of idle connections is limited, and the size of the eBPF Map is controlled.

[0120] 7. Control plane - Commissioning and observability.

[0121] The debug_map of type BPF_MAP_TYPE_ARRAY is used to store debug control information (such as debug switches), supports dynamically enabling / disabling debug mode, does not rely on frequent bpf_printk, and provides flow table dump capability to assist in troubleshooting and verification.

[0122] Take a typical multi-load balancer deployment scenario as an example: F5-A connects to the application firewall via interface eth0, and F5-B connects to the application firewall via interface eth1.

[0123] 1. The client request reaches the eth0 interface of the application firewall via F5-A.

[0124] The Ingress eBPF program successfully matched the site IP and port, identified it as a TCP SYN packet, recorded the source MAC (MAC of F5-A: AA:BB:CC:DD:EE:01) and the ingress interface (eth0), and created a connection with the state SYN_SEEN.

[0125] 2. The request message was successfully forwarded to the backend server.

[0126] 3. The server response message is returned to the application firewall. Due to Linux routing decisions, the response message may be sent from the eth1 interface (connected to F5-B).

[0127] 4. The Egress eBPF program queries the connection table and finds that the inbound interface is eth0, but the current outbound interface is eth1, which is inconsistent.

[0128] 5. Compare the current destination MAC (MAC of F5-B) with the recorded source MAC (MAC of F5-A: AA:BB:CC:DD:EE:01). If they are inconsistent, call bpf_skb_store_bytes() to modify the destination MAC to AA:BB:CC:DD:EE:01.

[0129] 6. Call bpf_redirect() to redirect the packet to the send queue of the eth0 interface.

[0130] 7. The response message is sent from eth0 and arrives at F5-A. There is a corresponding connection state on F5-A, the session is matched normally, and the service is not affected.

[0131] The above-mentioned multi-load balancing device path backtracking control method has the following technical effects: 1. Pure eBPF kernel-mode closed-loop processing eliminates external dependencies and reduces system complexity.

[0132] Because this solution adopts a pure eBPF kernel-mode closed-loop processing scheme, all traffic matching, connection establishment, path correction, and MAC modification are completed in the eBPF program, without relying on the iptables (configuration tool) and conntrack (connection tracking module) subsystems. This avoids the high system complexity caused by the collaborative work of the three subsystems eBPF+conntrack+iptables in existing technologies. Therefore, it achieves the beneficial effects of simple system architecture, low maintenance cost, and simple deployment, thereby realizing the lightweight and high maintainability of application firewall products in ALH function.

[0133] Advantage 2: bpf_redirect() directly redirects packets, shortening the packet processing path and reducing latency.

[0134] When this solution detects an inconsistency between the outgoing and incoming interfaces in the egress direction, it directly redirects the data packet to the sending queue of the incoming interface via bpf_redirect(), without needing to go through iptables rule matching and policy route lookup. This avoids the lengthy path of MARK reading → MAC modification → iptables rule matching → policy route lookup → interface redirection in existing technologies. Therefore, it achieves the beneficial effects of a shorter data packet processing path and lower latency, thereby realizing low-latency path correction capabilities in high-performance application firewall scenarios.

[0135] Advantage 3: The LPM prefix tree + Bitmap dual-active configuration mechanism enables continuous hot updates of configurations.

[0136] Because this solution adopts the ActiveLpmIndex dual-active index mechanism, the old and new configurations coexist in the eBPF Map. When the configuration is updated, the new configuration is first written to the inactive index, and then the ActiveLpmIndex is atomically switched to point to the new configuration. This avoids the problem that the eBPF Map and iptables rules cannot be updated atomically in the existing technology. Therefore, it achieves the beneficial effect of zero packet loss and zero interruption during the configuration update process, and thus realizes the goal of making the hot update of application firewall site configuration completely transparent to the business.

[0137] Advantage 4: Multi-level differentiated timeout recycling strategy effectively controls the size of join tables.

[0138] Because this solution adopts a multi-level differentiated recycling strategy of RST immediate deletion / FIN timeout of 5s / SYN-only timeout of 5s / normal idle timeout of 60s, different timeout times are set according to different connection states; it avoids the resource waste or connection mis-recycling problems caused by the single timeout strategy in the existing technology; thus, it achieves the beneficial effect of efficient utilization of eBPF Map memory, and thus realizes the ability to support large-scale connections under limited kernel memory resources.

[0139] Corresponding to the above embodiments of the multi-load balancing device path backtracking control method, this embodiment of the invention also provides a multi-load balancing device path backtracking control device, applied to an application firewall system containing multiple load balancing devices, wherein the application firewall system is positioned between the client and the server; for example Figure 6 As shown, the device includes: Inbound control module 100: When a client's request packet is detected to have passed through the first load balancer and reached the first interface of the application firewall, the first source address of the first load balancer is saved to a preset site table. Outbound control module 200: When the response packet after the server response request packet is detected arrives at the second interface in the application firewall, it obtains the second source address of the second load balancing device corresponding to the second interface, and updates the second source address to the first source address through the site table; Path backtracking module 300: Used to control the response message to return to the client after passing through the first load balancer via the first source address.

[0140] As can be seen from the above-mentioned multi-load balancing device path backtracking control device, this device can save the ingress source address in the ingress direction of the application firewall and replace the egress source address with the ingress source address in the egress direction of the application firewall. Thus, without relying on related configuration tools, connection tracking modules and policy routing, it can ensure that request packets and response packets always pass through the same load balancing device, which greatly improves the connection state consistency and service stability of the application firewall system.

[0141] The multi-load balancing device path backtracking control device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned multi-load balancing device path backtracking control method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned multi-load balancing device path backtracking control method embodiment.

[0142] This embodiment also provides an electronic device, the structural schematic diagram of which is shown below. Figure 7 As shown, the device includes a processor 101 and a memory 102; wherein, the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the above-described multi-load balancing device path backtracking control method.

[0143] Figure 7 The electronic device shown also includes a bus 103 and a communication interface 104, with the processor 101, communication interface 104 and memory 102 connected via the bus 103.

[0144] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0145] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0146] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0147] This invention also provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of the multi-load balancing device path backtracking control method described in the foregoing embodiments.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0149] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0151] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A path backtracking control method for multiple load balancing devices, characterized in that, An application firewall system comprising multiple load balancing devices is used, wherein the application firewall system is positioned between the client and the server; the method includes: When the client's request message is detected to have passed through the first load balancer and reached the first interface of the application firewall, the first source address of the first load balancer is saved to the preset site table. When the response message of the server responding to the request message is detected to arrive at the second interface in the application firewall, the second source address of the second load balancing device corresponding to the second interface is obtained, and the second source address is updated to the first source address through the site table; The response message is controlled by the first source address to return to the client after passing through the first load balancer.

2. The multi-load balancing device path backtracking control method according to claim 1, characterized in that, When a request packet from the client is detected to have arrived at the first interface of the application firewall via the first load balancer, the step of saving the first source address of the first load balancer to a preset site table includes: The protocol type and flag bits of the request messages arriving at the first interface are identified; Only when the request message is a TCP synchronization message, extract the five-tuple identifier, the first source address of the first load balancer, and the index information of the first interface corresponding to the message; The first source address and the index information are saved to a preset site table using the quintuple identifier as the retrieval key.

3. The multi-load balancing device path backtracking control method according to claim 1, characterized in that, Before saving the first source address of the first load balancing device to a preset site table, a site traffic matching step is also included: After performing prefix matching on the target address of the request message using a preset prefix matching strategy, the bitmap array index corresponding to the target address is obtained; The target port number of the request message is matched using the bitmap array index; The subsequent first source address saving operation is performed only if both the target address and the target port number are successfully matched.

4. The multi-load balancing device path backtracking control method according to claim 3, characterized in that, Matching the target port number of the request message using the bitmap array index includes: An active index tag for the target address is constructed based on the prefix matching strategy, and an inactive index tag for the target address is constructed based on the site table; After matching the bitmap array index with the request message using the inactive index flag, the active index flag controls the bitmap array index to match the target port number of the request message.

5. The multi-load balancing device path backtracking control method according to claim 2, characterized in that, Obtaining the second source address of the second load balancing device corresponding to the second interface, and updating the second source address to the first source address through the site table, includes: Based on the quintuple identifier, the connection table associated with the site table is obtained in real time. When it is detected that the inbound interface recorded in the connection table is different from the second interface, the corresponding second load balancing device is determined according to the second interface in the application firewall. Obtain the second source address of the second load balancing device. If the second source address is different from the first source address, update the second source address to the first source address through the site table.

6. The multi-load balancing device path backtracking control method according to claim 1, characterized in that, The step of controlling the response message to return to the client after passing through the first load balancer via the first source address includes: The response message is redirected to the sending queue of the first interface according to the first source address; The sending queue controls the transmission of the response message from the application firewall to the first load balancer. The first load balancer is used to control the response message to be returned to the client in the callback format of the request message.

7. The multi-load balancing device path backtracking control method according to claim 1, characterized in that, After saving the first source address of the first load balancing device to a preset site table, the method further includes: Scan all connection records in the site table at preset time intervals and obtain the message type corresponding to each target connection record; If the message type of the target connection record is a reset message type, then delete the target connection record; If the message type of the target connection record is an end message type, then the target connection record is deleted after the first timeout period; If the message type of the target connection record is a synchronization message type, then the target connection record is deleted after the second timeout period.

8. The multi-load balancing device path backtracking control method according to any one of claims 1 to 7, characterized in that, The method is implemented based on the flow control framework of the extended Berkeley packet filter; The application firewall system uses inbound hooks to attach the same filter inbound processing strategy to each service interface in the inbound direction, which is used to execute the address recording logic of request packets. The application firewall system uses outbound processing strategies with the same filters attached to outbound hooks on each service interface to execute address update and forwarding control logic for response packets. All business interfaces share the same kernel-mode site table.

9. A path backtracking control device for multiple load balancing equipment, characterized in that, An application firewall system comprising multiple load balancing devices, wherein the application firewall system is positioned between the client and the server; the device includes: Inbound control module: When the client's request packet is detected to have passed through the first load balancer and reached the first interface of the application firewall, the first source address of the first load balancer is saved to a preset site table. Outbound control module: When the response message after the server responds to the request message arrives at the second interface in the application firewall, it obtains the second source address of the second load balancing device corresponding to the second interface, and updates the second source address to the first source address through the site table; Path backtracking module: used to control the response message to return to the client after passing through the first load balancing device via the first source address.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the multi-load balancing device path backtracking control method according to any one of claims 1 to 8.

Images