Method and apparatus for supporting both bridge forwarding and proxy forwarding in transparent mode

Abstract

This invention discloses a method and apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, relating to the field of network security technology. The method includes: receiving and parsing raw data packets through the network interface of a WAF device, identifying key feature information for traffic classification in the raw data packets; performing policy matching on the raw data packets containing the key feature information using a dynamic policy table pre-configured in the Linux kernel of the WAF device; if the key feature information matches the transparent proxy mode in the dynamic policy table, then forwarding the raw data packet to the proxy processing module through the Linux kernel protocol stack. This invention combines the advantages of bridge forwarding and proxy forwarding, meeting the flexible deployment needs of users.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode. Background Technology

[0002] A Web Application Firewall (WAF) is a security device specifically designed to protect web applications from various network attacks. WAFs provide real-time protection for web applications by monitoring, filtering, and blocking malicious requests in HTTP / HTTPS traffic. To adapt to flexible network topologies, WAFs typically offer multiple deployment modes for users to choose from, such as reverse proxy mode, traffic mirroring mode, transparent bridge mode, transparent proxy mode, and so on.

[0003] Both transparent bridge mode and transparent proxy mode aim to transparently insert WAF devices into network links without altering the network topology. They each have their own advantages and disadvantages and rely on different technology stacks. See also Figure 1 The transparent bridge mode does not use the Linux kernel protocol stack to receive and send network packets; instead, it performs packet inspection in user space. The transparent proxy mode relies on HTTP proxy software to proxy HTTP traffic. This proxy software typically runs on Linux systems and depends on the Linux kernel's network protocol stack to send and receive network packets.

[0004] Because the transparent bridge mode and the transparent proxy mode rely on different network packet sending and receiving technology stacks, it is difficult to run both modes simultaneously on the same device. Users must choose one of the transparent modes when deploying a WAF. If a change in deployment mode is required, manual mode switching is necessary, which increases the complexity of operation and maintenance, and users cannot simultaneously enjoy the advantages of both "transparent bridge" and "transparent proxy" modes. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a method and apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, which can solve the technical problems mentioned in the background art.

[0006] One aspect of the present invention provides a method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode, comprising:

[0007] The WAF device receives and parses raw data packets through its network interface, identifying key feature information in the raw data packets used for traffic classification.

[0008] The WAF device uses a dynamic policy table pre-configured in the Linux kernel to perform policy matching on raw data packets containing the key feature information. If the key feature information matches the transparent proxy mode in the dynamic policy table, the raw data packet is forwarded to the proxy processing module via the Linux kernel protocol stack. If the key feature information matches the transparent bridge mode in the dynamic policy table, the raw data packet is bypassed from the Linux kernel protocol stack and sent to the bridge processing module. If the raw data packet is non-TCP service traffic, it is sent directly to the peer network interface.

[0009] In another aspect, the present invention provides an apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, comprising:

[0010] The packet parsing module is used to receive and parse raw data packets through the WAF device's network interface, and identify key feature information in the raw data packets used for traffic classification.

[0011] The traffic splitting and scheduling module is used to perform policy matching on raw data packets containing the key feature information through the dynamic policy table pre-configured in the Linux kernel of the WAF device. If the key feature information matches the transparent proxy mode in the dynamic policy table, the raw data packet is forwarded to the proxy processing module through the Linux kernel protocol stack. If the key feature information matches the transparent bridge mode in the dynamic policy table, the raw data packet is bypassed and sent to the bridge processing module. If the raw data packet is non-TCP service traffic, the raw data packet is sent directly to the peer network interface.

[0012] This invention provides a method and apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode. By supporting both forwarding methods in transparent mode, it solves the problem in existing technologies where WAF devices can only be deployed in one transparent mode. This invention combines the advantages of both bridge forwarding and proxy forwarding, meeting users' flexible deployment needs. It eliminates the need for users to switch between "transparent bridge mode" and "transparent proxy mode," reducing the operational complexity caused by mode switching, lowering the deployment and maintenance costs of WAF devices, and improving the practicality and adaptability of WAF devices. Attached Figure Description

[0013] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0014] Figure 1 This is a technical schematic diagram of the transparent bridge pattern and transparent proxy pattern in existing technologies;

[0015] Figure 2This is a flowchart illustrating a method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode, provided in one embodiment of this application. Figure 1 ;

[0016] Figure 3 This is a flowchart illustrating a method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode, provided in one embodiment of this application. Figure 2 ;

[0017] Figure 4 This is a flowchart illustrating the creation of a bridge processing module for an AF_XDP socket according to an embodiment of this application;

[0018] Figure 5 This is a schematic diagram of a device that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, according to another embodiment of this application.

[0019] Figure 6 This is a schematic diagram of the structure of a WAF device provided in another embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 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.

[0021] In existing technologies, there is a technology stack conflict between transparent bridge mode and transparent proxy mode. Transparent bridge needs to circumvent kernel stack protocols, while transparent proxy depends on kernel protocol stack. Moreover, traffic in either transparent mode needs to occupy a network card or a specific network namespace. Traffic cannot dynamically switch traffic paths according to policies at runtime. If the two types of traffic are forcibly mixed, either the performance of bridge mode or the proxy function will be sacrificed. The two cannot coexist on the same network interface, and users can only choose one transparent mode for deployment.

[0022] To overcome the aforementioned technical problems, this application provides a method and apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode. It utilizes AF_XDP and xdp / ebpf technologies provided by the Linux kernel to collect, distribute, and send network traffic. This allows encrypted traffic such as HTTPS, or other TCP traffic requiring transparent proxy mode processing, to be distributed to the transparent proxy module, while unencrypted traffic such as HTTP, or other TCP traffic not requiring transparent proxy mode processing, is distributed to the transparent bridge module. Thus, transparent proxy mode and transparent bridge mode are simultaneously implemented in the WAF.

[0023] See Figure 2-3 One embodiment of this application provides a method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode, comprising the following steps:

[0024] Step S101: The WAF device receives and parses raw data packets through its network interface, identifying key feature information in the raw data packets used for traffic diversion.

[0025] This embodiment constructs a traffic splitting and scheduling module using a series of XDP / ebpf programs for receiving, splitting, and sending network traffic. The principle of the traffic splitting and scheduling module is as follows: a series of XDP / ebpf programs are inserted into the network interface of the WAF device. These XDP / ebpf programs receive all data packets on the network interface and then store all preset network traffic processing policies in a mapping table. These policies determine how to handle various types of traffic. After parsing the data packets, the XDP / ebpf programs perform a matching of network traffic processing policies and finally execute the processing action according to the matched policy.

[0026] Specifically, the traffic splitting and scheduling module parses the Ethernet frame header, IP header, TCP / UDP header, and other headers byte by byte from the raw data packet byte stream received from the WAF device's network interface, and performs a series of validity checks, such as checksum, version number, and length. Invalid packets or non-TCP / IP packets are either directly discarded or allowed to pass to the peer network interface at this stage. Next, the module extracts the five-tuple information (source IP, destination IP, source port, destination port, protocol) and / or payload information for policy matching from the raw data packet header. These constitute the key feature information for subsequent traffic classification and identification. For example, based on the key feature information, HTTP traffic or HTTPS traffic can be identified, and then HTTP traffic and HTTPS traffic can be distributed to different transparency modes according to the classification policy.

[0027] Step S102: The WAF device uses a dynamic policy table pre-configured in the Linux kernel to perform policy matching on raw data packets containing the key feature information. If the key feature information matches the transparent proxy mode in the dynamic policy table, the raw data packet is forwarded to the proxy processing module via the Linux kernel protocol stack. If the key feature information matches the transparent bridge mode in the dynamic policy table, the raw data packet is bypassed from the Linux kernel protocol stack and sent to the bridge processing module. If the raw data packet is non-TCP service traffic, it is sent directly to the peer network interface.

[0028] Specifically, the dynamic policy table pre-built into the Linux kernel is preferably in the form of an eBPF Map. The eBPF Map stores different processing methods for different traffic data. It is supported by an efficient hash algorithm and can complete policy matching in constant time complexity by matching key feature information, making it extremely fast.

[0029] When routing traffic, the original data packets containing key characteristic information are first subjected to policy matching. If the key characteristic information matches the transparent proxy mode in the dynamic policy table, the original data packet is forwarded to the proxy processing module via the Linux kernel protocol stack. If the key characteristic information matches the transparent bridge mode in the dynamic policy table, the original data packet is bypassed by the Linux kernel protocol stack and sent to the bridge processing module. If the original data packet is non-TCP service traffic, it is either sent directly to the peer network interface or discarded.

[0030] The contents of the eBPF Map (i.e., the dynamic policy table) can be found in the table below:

[0031]

[0032] The strategy matching process is exemplified as follows:

[0033] (1) For traffic that accesses the destination IP address 29.1.1.3 and the access port is 443, execute the TO_PROXY action to send the traffic to the transparent proxy module for processing;

[0034] (2) For TCP traffic accessing other IPs / Ports, the TO_BRIDGE action will be executed to send the traffic to the transparent bridge processing module for processing;

[0035] (3) For other non-TCP traffic (such as Ping traffic), the data packets are sent directly from the peer network interface without any complex processing.

[0036] Furthermore, the key to achieving traffic splitting and scheduling lies in ensuring that traffic data in transparent bridge mode can bypass the Linux kernel protocol stack and reach the bridge processing module. That is, ensuring that the bridge processing module cooperates with the traffic splitting and scheduling module to capture data packets is another core aspect of this invention following the traffic splitting and scheduling strategy. To achieve this objective, this method designs the following high-performance forwarding mode based on AF_XDP sockets.

[0037] It's important to note that traditional AF_XDP technology requires user-space applications (e.g., bridge processing modules) to first mount the XDP program (e.g., traffic routing and scheduling modules) themselves. This ensures that when creating an AF_XDP socket, the application can access the existing "correspondence table between AF_XDP sockets and network interface data queues" within the XDP program (e.g., traffic routing and scheduling module). The user-space application then injects its own created AF_XDP socket into this table to achieve the mapping between user-space sockets and kernel-space XDP programs. This necessitates that the user-space application (e.g., bridge processing module) load the XDP program (e.g., traffic routing and scheduling module) onto the network interface card, and does not support the XDP program (e.g., traffic routing and scheduling module) being loaded before the user-space application (e.g., bridge processing module). This strong binding relationship results in a rigid and fixed deployment order between the "user-space bridge processing module" and the "kernel-space traffic routing and scheduling module," severely limiting system deployment flexibility.

[0038] To overcome the above technical problems, see Figure 4 This invention employs a dynamic discovery mechanism that supports mounted XDP programs (e.g., traffic splitting and scheduling modules). This mechanism enables the creation of AF_XDP sockets for bridge processing modules, making the deployment order of user-mode bridge processing modules and kernel-mode traffic splitting and scheduling modules more flexible.

[0039] First, the system obtains information on all loaded XDP programs through the Linux kernel and identifies the target XDP program (such as the traffic splitting and scheduling module) for raw packet traffic classification from all loaded XDP programs.

[0040] Next, obtain the file descriptor of the correspondence table between the existing AF_XDP sockets and network interface data queues in the target XDP program (such as the traffic diversion and scheduling module).

[0041] Finally, the bridge processing module creates its own AF_XDP socket and updates the AF_XDP socket of the bridge processing module to the entry of the network interface data queue in the corresponding relation table through the file descriptor.

[0042] This achieves the creation of the bridge processing module's own AF_XDP socket, the establishment of the mapping relationship between the AF_XDP socket and the kernel-mode traffic routing and scheduling module, and the establishment of the correspondence between the AF_XDP socket and the network interface data queue. This method allows for the deployment of the target XDP program (such as the traffic routing and scheduling module) in kernel mode first, followed by the deployment of the user-mode bridge processing module application, or vice versa, making the deployment order quite flexible.

[0043] Furthermore, in existing technologies, a data packet needs to undergo multiple data copies—from the network card to kernel memory and from kernel space to user space—to reach the user-space application (bridge proxy module). This results in low data transmission efficiency and high CPU resource consumption. To address these issues, this invention pre-allocates and shares the same physical memory between the user-space bridge processing module's AF_XDP socket and the kernel-space traffic routing and scheduling module / network card. The network card directly writes the original data packets distributed by the kernel-space traffic routing and scheduling module in bridge processing mode to this shared memory via DMA. The data itself remains stationary in the shared memory. The kernel-space traffic routing and scheduling module sends pointers or indices to the data locations in the shared memory to the user-space bridge processing module, which then directly reads the data packet content from the shared memory for processing. This eliminates the need for data transfer from kernel space to user space, thus reducing CPU resource consumption.

[0044] Furthermore, after creating the AF_XDP socket for the bridge processing module and setting up the shared storage area, in response to traffic splitting decisions, the module queries the correspondence between the AF_XDP socket and the network interface data queue, obtains the AF_XDP socket corresponding to the target network interface data queue, and writes the original data packets transmitted by the target network interface data queue into the corresponding storage location of the AF_XDP socket in the shared memory area. Then, the bridge processing module reads the original data packets from the shared memory area, performs security checks on the original data packets, and transparently transmits the traffic data that passes the security check to the peer network interface, thereby realizing the transparent bridge mode of the WAF.

[0045] Furthermore, after the traffic splitting and scheduling module parses and matches the traffic, if it finds that the traffic needs to be transparently proxied, it marks the original data packet with a specific tag / flag so that it can be correctly received by the Linux kernel network protocol stack and finally sent to the user-space proxy processing module. In this way, the proxy processing module can successfully carry out proxy forwarding processing of HTTP traffic.

[0046] Furthermore, after the traffic splitting and scheduling module parses and matches the traffic, if it finds that the traffic is not TCP traffic, such as Ping traffic, it can choose to discard it or send it directly to the other end's network interface, depending on the situation.

[0047] This embodiment supports both bridge forwarding and proxy forwarding modes simultaneously in transparent mode, solving the problem that existing WAF devices can only be deployed in one transparent mode. This embodiment combines the advantages of both bridge forwarding and proxy forwarding, meeting users' flexible deployment needs. It eliminates the need for users to switch between "transparent bridge mode" and "transparent proxy mode," reducing operational complexity caused by mode switching, lowering the deployment and maintenance costs of WAF devices, and improving the practicality and adaptability of WAF devices.

[0048] See Figure 5 Another embodiment of the present invention provides an apparatus 200 that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, including a packet parsing module 201 and a traffic splitting and scheduling module 202. The apparatus 200 is capable of executing the method in the method embodiment that simultaneously supports bridge forwarding and proxy forwarding in transparent mode.

[0049] Specifically, the device 200 that simultaneously supports bridge forwarding and proxy forwarding in transparent mode includes:

[0050] The packet parsing module 201 is used to receive and parse raw data packets through the network interface of the WAF device, and identify key feature information in the raw data packets used for traffic classification.

[0051] The traffic splitting and scheduling module 202 is used to perform policy matching on the original data packets containing the key feature information through the dynamic policy table pre-configured in the Linux kernel of the WAF device; if the key feature information matches the transparent proxy mode in the dynamic policy table, the original data packet is forwarded to the proxy processing module through the Linux kernel protocol stack; if the key feature information matches the transparent bridge mode in the dynamic policy table, the original data packet is bypassed and sent to the bridge processing module; if the original data packet is non-TCP service traffic, the original data packet is sent directly to the peer network interface.

[0052] Furthermore, it also includes: a socket creation module, used to create AF_XDP sockets belonging to the bridge processing module and establish a correspondence between each AF_XDP socket and a network interface data queue; setting a unified shared memory area for all AF_XDP sockets of the bridge processing module; a data processing module, used to respond to traffic diversion decisions, query the correspondence between AF_XDP sockets and network interface data queues, obtain the AF_XDP socket corresponding to the target network interface data queue, and write the original data packets transmitted by the target network interface data queue into the corresponding storage location of the AF_XDP socket in the shared memory area; and a bridge processing module, used to read the original data packets in the shared memory area, perform security checks on the original data packets, and pass through the traffic data that passes the security check to the peer network interface.

[0053] Furthermore, the traffic splitting and scheduling module 202 is also used to: instruct the bridge processing module to obtain information on all loaded XDP programs in the system through the Linux kernel, identify the target XDP program for raw data packet traffic splitting from all loaded XDP programs; obtain the file descriptor of the correspondence table between the existing AF_XDP sockets and network interface data queues in the target XDP program; create the AF_XDP socket of the bridge processing module, and update the AF_XDP socket of the bridge processing module to the entry of the network interface data queue in the correspondence table through the file descriptor.

[0054] Furthermore, the key feature information includes quintuple data and / or payload features.

[0055] Furthermore, the traffic diversion and scheduling module 202 is also used to: add a tag to the original data packet for the Linux kernel protocol stack to recognize; the Linux kernel protocol stack recognizes and parses the original data packet with the tag, and forwards the processed original data packet to the proxy processing module.

[0056] It should be noted that the technical solutions corresponding to the device 200 that supports both bridge forwarding and proxy forwarding in transparent mode provided in this embodiment, which can be used to execute various method embodiments, have similar implementation principles and technical effects to the methods, and will not be repeated here.

[0057] See Figure 6 Another embodiment of the present invention provides a schematic diagram of an electronic device 300, which is used to implement the method in the method embodiment that simultaneously supports bridge forwarding and proxy forwarding in transparent mode. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, WAF devices composed of smartphones, tablets, PCs, laptops, servers, etc. Figure 6The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0058] like Figure 6 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0059] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0060] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode, characterized in that, Includes the following steps: The WAF device receives and parses raw data packets through its network interface, identifying key feature information in the raw data packets used for traffic classification. The WAF device uses a dynamic policy table pre-configured in the Linux kernel to perform policy matching on raw data packets containing the key feature information. If the key feature information matches the transparent proxy mode in the dynamic policy table, the raw data packet is forwarded to the proxy processing module via the Linux kernel protocol stack. If the key feature information matches the transparent bridge mode in the dynamic policy table, the raw data packet is bypassed from the Linux kernel protocol stack and sent to the bridge processing module. If the raw data packet is non-TCP service traffic, the raw data packet is sent directly to the peer network interface. Create AF_XDP sockets belonging to the bridge processing module and establish the correspondence between each AF_XDP socket and the network interface data queue; set up a unified shared memory area for all AF_XDP sockets of the bridge processing module; In response to traffic diversion decisions, the system queries the correspondence between AF_XDP sockets and network interface data queues, obtains the AF_XDP socket corresponding to the target network interface data queue, and writes the original data packets transmitted by the target network interface data queue into the corresponding storage location of the AF_XDP socket in the shared memory area. The bridge processing module reads the original data packets in the shared memory area, performs security checks on the original data packets, and then forwards the traffic data that passes the security check to the peer network interface.

2. The method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 1, characterized in that, The step of creating the AF_XDP socket belonging to the bridge processing module includes: The bridge processing module obtains information on all loaded XDP programs in the system through the Linux kernel, and identifies the target XDP program for raw packet traffic diversion from all loaded XDP programs. Obtain the file descriptor of the mapping table between the existing AF_XDP sockets and network interface data queues in the target XDP program; Create the AF_XDP socket for the bridge processing module, and update the AF_XDP socket of the bridge processing module to the entry of the network interface data queue in the corresponding relation table through the file descriptor.

3. The method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 1, characterized in that, The key feature information includes quintuple data and / or payload features.

4. The method for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 1, characterized in that, The step of forwarding the raw data packet to the proxy processing module via the Linux kernel protocol stack includes: Add tags to the raw data packets that can be recognized by the Linux kernel protocol stack; The Linux kernel protocol stack identifies and parses the raw data packets with the aforementioned tags, and then forwards the processed raw data packets to the proxy processing module.

5. An apparatus that simultaneously supports bridge forwarding and proxy forwarding in transparent mode, characterized in that, include: The packet parsing module is used to receive and parse raw data packets through the WAF device's network interface, and identify key feature information in the raw data packets used for traffic classification. The traffic splitting and scheduling module is used to perform policy matching on raw data packets containing the key feature information through the dynamic policy table pre-configured in the Linux kernel of the WAF device. If the key feature information matches the transparent proxy mode in the dynamic policy table, the raw data packet is forwarded to the proxy processing module through the Linux kernel protocol stack. If the key feature information matches the transparent bridge mode in the dynamic policy table, the raw data packet is bypassed and sent to the bridge processing module. If the raw data packet is non-TCP service traffic, the raw data packet is sent directly to the peer network interface. The socket creation module is used to create AF_XDP sockets belonging to the bridge processing module and establish the correspondence between each AF_XDP socket and the network interface data queue; it also sets up a unified shared memory area for all AF_XDP sockets of the bridge processing module. The data processing module is used to respond to traffic diversion decisions, query the correspondence between AF_XDP sockets and network interface data queues, obtain the AF_XDP socket corresponding to the target network interface data queue, and write the original data packets transmitted by the target network interface data queue into the corresponding storage location of the AF_XDP socket in the shared memory area. The bridge processing module is used to read the raw data packets in the shared memory area, perform security checks on the raw data packets, and pass through the traffic data that passes the security check to the peer network interface.

6. The apparatus for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 5, characterized in that, The traffic diversion and scheduling module is also used for: The command bridge processing module obtains information on all loaded XDP programs in the system through the Linux kernel, and identifies the target XDP program for raw packet traffic diversion from all loaded XDP programs. Obtain the file descriptor of the mapping table between the existing AF_XDP sockets and network interface data queues in the target XDP program; Create the AF_XDP socket for the bridge processing module, and update the AF_XDP socket of the bridge processing module to the entry of the network interface data queue in the corresponding relation table through the file descriptor.

7. The apparatus for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 5, characterized in that, The key feature information includes quintuple data and / or payload features.

8. The apparatus for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode according to claim 5, characterized in that, The traffic diversion and scheduling module is also used for: Add tags to the raw data packets that can be recognized by the Linux kernel protocol stack; The Linux kernel protocol stack identifies and parses the raw data packets with the aforementioned tags, and then forwards the processed raw data packets to the proxy processing module.

Images