A bridge transparent proxy method, device, storage medium and equipment

Abstract

The embodiment of the present application provides a bridge transparent proxy method, apparatus, storage medium and device. In this method, the Linux bridge of the transparent proxy device is configured, and two service ports required for forwarding are added to the Linux bridge. When the SYN message sent by the client is intercepted, the Ethernet frame header information including the MAC address information and the SYN input interface index in the SYN message is saved, and then the saved Ethernet frame header information is reversed with the source MAC address and the destination MAC address using a specified hook point and added to the constructed SYN-ACK message, and the target SYN message is sent out from the SYN input interface to establish a connection with the client. When establishing a connection with the server, the saved Ethernet frame header information is added to the constructed target SYN message and sent out from another service port on the Linux bridge other than the SYN input interface. In this way, a transparent proxy is realized in the transparent bridge mode of the switching network, without changing the network topology, without configuring IP and routing, and is easy to implement.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a bridge transparent proxy method, apparatus, storage medium, and device. Background Art

[0002] In some complex network environments, due to issues such as IP resource limitations and switching network management, network devices newly added to the network environment cannot be configured with service IPs. Instead, transparent proxies are required to detect or forward messages passing through the devices. The main solution for such scenarios in related technologies is to use the switching module of the DPDK (DataPlane Development Kit) to send transparent proxy messages to the Linux kernel or read transparent proxy messages from the kernel and send them outward. After the Linux kernel protocol stack has processed them, the application data is passed to the user-layer proxy process. However, DPDK needs to handle issues such as transparent proxy message connection association, making its implementation relatively complex. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a bridge transparent proxy method, apparatus, storage medium and equipment, aiming to solve the problem in the related art that transparent proxy implementation is relatively complex when the bridge has no IP address configuration and the route is unreachable.

[0004] In a first aspect, an embodiment of the present application provides a bridge transparent proxy method, which is applied to a transparent proxy device, wherein a Linux bridge of the transparent proxy device is configured with two service ports; the method comprises:

[0005] Intercepting the TCP SYN message sent by the client to the server, and saving the Ethernet frame header information in the SYN message; the Ethernet frame header information includes MAC address information and SYN input interface index;

[0006] Constructing a SYN-ACK message, using a specified hook point to reverse the source MAC address and destination MAC address in the saved Ethernet frame header information, adding the reversed address to the SYN-ACK message header, and sending the SYN-ACK message out of the service port corresponding to the SYN inbound interface index. Upon receiving a message from the client again, determining to establish a connection with the client;

[0007] When establishing a connection with the server, a target SYN message is constructed, the saved Ethernet frame header information is added to the target SYN message using the specified hook point, and the target SYN message is sent out from the target outgoing interface; the target outgoing interface is another business port on the Linux bridge other than the business port corresponding to the SYN inbound interface index.

[0008] In the above implementation process, the Linux bridge of the transparent proxy device is configured, and the two service ports required for forwarding are added to the Linux bridge. When the SYN message sent by the client is intercepted, the Ethernet frame header information including the MAC address information and the SYN input interface index in the SYN message is saved. Then, the saved Ethernet frame header information is reversed with the source MAC address and the destination MAC address using a specified hook point and added to the constructed SYN-ACK message. The target SYN message is sent out from the SYN input interface to establish a connection with the client. When establishing a connection with the server, the saved Ethernet frame header information is added to the constructed target SYN message and sent out from another service port on the Linux bridge other than the SYN input interface. In this way, a transparent proxy is realized in the transparent bridge mode of the switching network, without changing the network topology, without configuring IP and routing, and is easy to implement.

[0009] Furthermore, in some embodiments, an ebtables extension module is provided in the Linux kernel of the transparent proxy device; and intercepting a TCP SYN message sent from the client to the server includes:

[0010] Match incoming TCP packets through the ebtables extension module to determine whether the TCP packets belong to an established socket or a monitored transparent proxy socket; the TCP packets include SYN packets;

[0011] If the match is successful, the TCP message is sent to the Linux kernel through policy routing.

[0012] In the above implementation process, the ebtables extension module and policy routing are used to route the SYN message sent by the client to the kernel.

[0013] Furthermore, in some embodiments, before sending the TCP packet to the Linux kernel through policy routing, the method includes:

[0014] The TCP message is marked with Mark X; and the Linux kernel is configured to prohibit setting the destination MAC address as the ingress interface MAC address for the message marked with Mark X.

[0015] In the above implementation process, the Linux kernel code is modified to prohibit the destination MAC address from being set to the ingress interface MAC address for messages marked with Mark X. In this way, when the Linux bridge receives a transparent proxy message, it will perform an ebtables extended match. If the match is successful, the transparent proxy message will be marked with Mark X. In this way, the kernel can subsequently send out messages based on the destination MAC address.

[0016] Furthermore, in some embodiments, the storing of the Ethernet frame header information in the SYN message includes:

[0017] Create a request_sock structure, and add tproxy_option information in the request_sock structure, where the tproxy_option information is used to record the Ethernet frame header information in the SYN message.

[0018] In the above implementation process, a specific method for saving Ethernet frame header information is provided, that is, when the kernel Socket layer receives a SYN request, it can create a request_sock structure and add tproxy_option information to the structure to save the Ethernet frame header information in the SYN message.

[0019] Further, in some embodiments, the designated hook point is a POST_ROUTING hook point of Netfilter.

[0020] In the above implementation process, an optional hook point is provided for adding Ethernet frame header information to outgoing messages.

[0021] Furthermore, in some embodiments, a target socket parameter is set in the Linux kernel of the transparent proxy device; and the method further includes:

[0022] The target socket parameters are updated based on the index of the service port receiving the message returned by the server.

[0023] In the above implementation process, the target socket parameter is set to record the index of the target outgoing interface, which facilitates the subsequent processing of the transparent proxy message sent to the server.

[0024] Furthermore, in some embodiments, the method further comprises:

[0025] When there is a transparent proxy message that needs to be sent to the server, the message header of the transparent proxy message is set using the target socket parameter, and the transparent proxy message is sent out from the target outgoing interface.

[0026] In the above implementation process, subsequent transparent proxy messages sent to the server all use the target socket parameters to set the Ethernet MAC information, improving processing efficiency.

[0027] In a second aspect, an embodiment of the present application provides a bridge transparent proxy device, which is applied to a transparent proxy device, wherein the Linux bridge of the transparent proxy device is configured with two service ports; the device includes:

[0028] The frame header storage module is used to intercept the TCP SYN message sent by the client to the server and save the Ethernet frame header information in the SYN message; the Ethernet frame header information includes MAC address information and SYN input interface index;

[0029] A first outgoing module is configured to construct a SYN-ACK message, reverse the source MAC address and the destination MAC address in the stored Ethernet frame header information using a specified hook point, add the reversed address to the SYN-ACK message header, and send the SYN-ACK message from the service port corresponding to the SYN inbound interface index. Upon receiving a message from the client again, the module determines to establish a connection with the client.

[0030] The second outgoing module is used to construct a target SYN message when establishing a connection with the server, use the specified hook point to add the saved Ethernet frame header information to the target SYN message, and send the target SYN message out from the target outgoing interface; the target outgoing interface is another business port on the Linux bridge other than the business port corresponding to the SYN inbound interface index.

[0031] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any one of the first aspects when executing the computer program.

[0032] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which instructions are stored. When the instructions are executed on a computer, the computer executes the method as described in any one of the first aspects.

[0033] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when running on a computer, enables the computer to execute the method as described in any one of the first aspects.

[0034] Other features and advantages disclosed in the present application will be described in the following description, or some features and advantages can be inferred or determined without doubt from the description, or can be learned by implementing the above-mentioned technology disclosed in the present application.

[0035] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0037] Figure 1 A flow chart of a bridge transparent proxy method provided in an embodiment of the present application;

[0038] Figure 2 A schematic diagram of the processing flow for client SYN messages in a transparent proxy method based on a Linux bridge provided in an embodiment of the present application;

[0039] Figure 3 A schematic diagram of a process for establishing a connection with a server in a transparent proxy method based on a Linux bridge provided in an embodiment of the present application;

[0040] Figure 4 A block diagram of a bridge transparent proxy device provided in an embodiment of the present application;

[0041] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0043] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0044] As described in the background technology, there is a problem in the related art that transparent proxy is more complicated to implement when the bridge has no IP address configuration and the route is unreachable. Based on this, the embodiment of the present application provides a bridge transparent proxy solution to solve the above problem.

[0045] Next, the embodiments of the present application are introduced:

[0046] like Figure 1 As shown, Figure 1 This is a flow chart of a bridge transparent proxy method provided in an embodiment of the present application, wherein the method is applied to a transparent proxy device, wherein the Linux bridge of the transparent proxy device is configured with two service ports. In other words, the transparent proxy device is a network device equipped with a Linux bridge, i.e., the transparent proxy device can be a Linux bridge device. A Linux bridge is a product that connects two local area networks using the same protocol, and can be considered as a device that determines whether a packet sent is to its own local area network or to another local area network. Generally speaking, a Linux bridge can be configured with one or more service ports, and the solution of this embodiment configures the Linux bridge, adding two service ports required for forwarding to the bridge, one service port is used to interact with the client, and the other service port is used to interact with the server. It should be noted that when there are multiple clients in the network environment, the sending and receiving messages of these clients share one service port.

[0047] The method comprises:

[0048] In step 101, a TCP SYN message sent from a client to a server is intercepted, and Ethernet frame header information in the SYN message is saved; the Ethernet frame header information includes MAC address information and a SYN inbound interface index;

[0049] The transparent proxy implemented in this embodiment is a TCP transparent proxy, which can include establishing a TCP connection between the client and the server, and processing TCP data packets between the client and the server after the establishment is completed. TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol that uses a three-way handshake protocol to establish a connection. When the active party sends a SYN (Synchronize Sequence Numbers) connection request, it waits for the other party to respond with a SYN+ACK (Acknowledge character), and finally performs an ACK confirmation on the other party's SYN. Therefore, when the client wants to establish a TCP connection with the server, the client sends a SYN message, and the transparent proxy device intercepts and obtains the SYN message.

[0050] In some embodiments, the transparent proxy device includes an ebtables extension module in its Linux kernel. The interception of TCP SYN packets sent from the client to the server mentioned in this step may include: matching incoming TCP packets, including SYN packets, via the ebtables extension module to determine whether the TCP packets belong to an established socket or a listening transparent proxy socket; the TCP packets include SYN packets; and if a match is successful, sending the TCP packets to the Linux kernel via policy routing. In other words, the transparent proxy device can utilize the ebtables extension module and policy routing to send packets whose source or destination addresses belong to the client or server addresses, i.e., transparent proxy packets, to the kernel. Specifically, ebtables is a configuration tool for network packet filtering in Linux systems, operating at the data link layer. This embodiment adds an ebtables extension module to the kernel to match transparent proxy packets, i.e., to determine whether TCP packets entering the transparent proxy device belong to an established socket or a listening transparent proxy socket, thereby implementing filtering. The ebtables extension module also includes a corresponding user-layer extension to upload qualified transparent proxy packets to the kernel network layer for routing lookup. Policy routing is a more flexible packet routing and forwarding mechanism than routing based on the target network. It uses ACLs (Access Control Lists) to define a specific packet, such as a packet with a client source address. A routing policy is then configured for the packet defined by this ACL. In this embodiment, the transparent proxy device uses policy routing to route transparent proxy packets, including SYN packets sent from the client to the server, to the local loopback interface.

[0051] Generally speaking, after receiving a message, the Linux kernel sets the destination MAC address to the incoming interface MAC address. This can easily affect the transparent proxy device's ability to find the correct outgoing interface for the transparent proxy message. Therefore, in some embodiments, before sending the TCP message to the Linux kernel via policy routing, the method may include: marking the TCP message with a Mark X; and the Linux kernel is configured to prohibit setting the destination MAC address to the incoming interface MAC address for messages marked with Mark X. In other words, the Linux kernel code is modified to prohibit setting the destination MAC address to the incoming interface MAC address for messages marked with Mark X. In this way, when the Linux bridge receives a transparent proxy message, it performs an ebtables extended match. If a match is successful, the transparent proxy message is marked with a Mark X. This allows the kernel to subsequently send messages based on the destination MAC address. Furthermore, the Linux kernel still processes other types of messages according to the mechanism of setting the destination MAC address to the incoming interface MAC address.

[0052] After intercepting the SYN message, the transparent proxy device saves the Ethernet frame header information in the SYN message. In Ethernet, the basic unit of data communication is the Ethernet frame, which consists of three parts: header, data, and checksum. In the scenario of the present embodiment, the Ethernet frame header information of the SYN message includes MAC address information and SYN input interface index. The MAC address information here includes the source MAC address used to mark which machine the data is sent from and the destination MAC address used to mark which machine the data is received from. The SYN input interface index here is the ID of the service port that marks the transparent proxy device to receive the SYN message. For example, the IDs of the two service ports configured in the Linux bridge are Eth1 and Eth2 respectively. The ID of the service port that receives the SYN message is Eth1, so the SYN input interface index is Eth1. Of course, in addition to these two types of information, the Ethernet frame header information can also include other information, such as information marking the message type. In some embodiments, storing the Ethernet frame header information in the SYN message may include: creating a request_sock structure and adding tproxy_option information to the request_sock structure, wherein the tproxy_option information is used to record the Ethernet frame header information in the SYN message. In other words, when the kernel socket layer receives a SYN request, it may create a request_sock structure and add tproxy_option information to the structure to store Ethernet frame header information such as the MAC address information and the SYN input interface index in the SYN message. Of course, in other embodiments, other structural blocks may be provided to store the Ethernet frame header information according to actual needs, and this application does not limit this.

[0053] In step 102, a SYN-ACK message is constructed. The source MAC address and the destination MAC address in the stored Ethernet frame header information are reversed using a specified hook point, and the address is added to the SYN-ACK message header. The SYN-ACK message is sent out from the service port corresponding to the SYN inbound interface index. When a message from the client is received again, a connection is established with the client.

[0054] The Linux kernel of the transparent proxy device constructs a SYN-ACK message in response to the SYN message sent by the client, thereby establishing a connection between the original server and the client. This embodiment implements transparent proxy in a switched network where the bridge has no IP address configuration and the route is unreachable. In other words, the transparent proxy device does not need to be configured with an IP address or route, but is instead implemented through the logic of this embodiment.

[0055] Specifically, the SYN-ACK message mentioned in this step is constructed by the Linux kernel. After construction is completed, the kernel can send the SYN-ACK message to the IP layer. Since the source MAC address in the saved Ethernet frame header information is the MAC address of the client device, and the destination MAC address is the MAC address of the server device, the transparent proxy device uses a specified hook point to reverse these two MAC addresses, so that in the adjusted Ethernet frame header information, the source MAC address is the MAC address of the server device, and the destination MAC address is the MAC address of the client device. In this way, the transparent proxy device adds the adjusted Ethernet frame header information to the SYN-ACK message header and sends the SYN-ACK message from the service port corresponding to the SYN inbound interface index, that is, the SYN inbound interface. In this way, when the ACK message returned by the client enters the Linux kernel again, it indicates that the TCP connection with the client has been established normally.

[0056] Alternatively, the designated hook point mentioned above can be the POST_ROUTING hook point of Netfilter. Netfilter is a subsystem introduced in the Linux system. As a general, abstract framework, it provides a complete set of hook function management mechanisms, making it possible to perform functions such as packet filtering, network address translation, and protocol-based connection tracking. The POST_ROUTING hook point is a hook point provided by Netfilter. All packets about to be sent out through the network device pass through this hook point, and the built-in source address translation function (including address masquerading) is performed at this hook point. Therefore, based on this hook point, the correct Ethernet frame header information can be added to the corresponding outgoing message header.

[0057] In addition, the transparent proxy device sends the SYN-ACK message out of the SYN input interface, which can be implemented by calling the dev_queue_xmit function. This function is the interface for the device driver to perform transmission and is used to directly use the skb_buff structure to send packets. Of course, in other embodiments, this transmission can also be implemented based on other methods, and this application does not limit this.

[0058] In step 103, when establishing a connection with the server, a target SYN message is constructed, the saved Ethernet frame header information is added to the target SYN message using the specified hook point, and the target SYN message is sent out from a target outgoing interface; the target outgoing interface is another service port on the Linux bridge other than the service port corresponding to the SYN inbound interface index.

[0059] When the transparent proxy attempts to connect to the proxied server, the Linux kernel will construct a new SYN message and send it to the server to initiate a connection request. Specifically, the target SYN message mentioned in this step is the new SYN message constructed by the Linux kernel. After constructing the target SYN message, the transparent proxy device uses the specified hook point to add the saved Ethernet frame header information to the target SYN message. Finally, the transparent proxy device searches for the target outbound interface based on the SYN inbound interface index and sends the target SYN message from the target outbound interface. The target outbound interface here is another service port on the Linux bridge in addition to the service port corresponding to the SYN inbound interface index. Using the previous example, the Linux bridge is configured with two service ports, Eth1 and Eth2. If the service port corresponding to the SYN inbound interface index is Eth1, the target outbound interface is Eth2. In this way, neither the client nor the server can perceive the existence of the transparent proxy device, realizing transparent proxy in the switched network bridge mode without changing the network topology or configuring IP and routing.

[0060] Furthermore, the transparent proxy device can search for the target outgoing interface based on the target socket parameters, which can refer to the sk_bound_dev_if parameter. During implementation, the transparent proxy device can set the aforementioned tproxy_option information to the newly established socket via the IP_TPROXY_MAC_INFO option and simultaneously set SO_BINDTO_DEVICE for the socket to the interface index stored in the tproxy_option. This allows the transparent proxy device to locate the target outgoing interface based on the sk_bound_dev_if interface index set on the socket when preparing to send a target SYN message. Upon receiving a SYN-ACK message from the server, the transparent proxy device can update the target socket parameters based on the index of the service port from which the message was received. Specifically, when the SYN-ACK message from the server reaches the TCP processing module in the local kernel protocol stack, the sk_bound_dev_if parameter is updated to the SYN-ACK interface index, facilitating subsequent processing of transparent proxy messages sent to the server.

[0061] Furthermore, the method may further include: when a transparent proxy message needs to be sent to the server, setting the message header of the transparent proxy message using the target socket parameters, and sending the transparent proxy message out of the target outbound interface. In other words, subsequent transparent proxy messages sent to the server only need to use the sk_bound_dev_if stored in the sock structure in Netfilter's POST_ROUTING to obtain the corresponding net_device pointer, then reset the Ethernet MAC information of the outbound message and call the dev_queue_xmit function to send it. This is convenient and fast, and helps improve processing efficiency.

[0062] It should be noted that when it is determined to establish a connection with the client, the kernel can use the request_sock structure to create a complete sock structure, save the MAC information saved in the request_sock structure to the inet_sock structure, and save the SYN input interface index saved in the request_sock structure to the sk_bound_dev_if of the sock structure, thereby facilitating the acquisition of the required MAC information and outgoing interface information when subsequent transparent proxy messages are sent out.

[0063] In an embodiment of the present application, a Linux bridge of a transparent proxy device is configured, and two service ports required for forwarding are added to the Linux bridge. When a SYN message sent by a client is intercepted, the Ethernet frame header information including the MAC address information and the SYN input interface index in the SYN message is saved. Then, the saved Ethernet frame header information is inverted with the source MAC address and the destination MAC address using a specified hook point and added to the constructed SYN-ACK message. The target SYN message is sent out from the SYN input interface to establish a connection with the client. When establishing a connection with the server, the saved Ethernet frame header information is added to the constructed target SYN message and sent out from another service port on the Linux bridge other than the SYN input interface. In this way, a transparent proxy is realized in the transparent bridge mode of a switching network, without changing the network topology, without configuring IP and routing, and is easy to implement.

[0064] In order to explain the solution of this application in more detail, a specific embodiment is introduced below:

[0065] This embodiment provides a transparent proxy method based on a Linux bridge to implement transparent proxy in a switched network when the network device functions as a Layer 2 pure transparent bridge, the bridge has no IP address configuration, and routing is unreachable. This solution, based on the Linux bridge module, utilizes ebtables and policy routing to send transparent proxy messages to the kernel, saves the Ethernet frame header information in the message sent by the client to the kernel sock structure, and utilizes Netfilter Hook and policy routing to skip the link layer address lookup for locally sent messages and directly send them to the other end. When connecting to the proxied server, the saved Ethernet frame header information is added to the outgoing message using Netfilter Hook, skipping the ARP (Address Resolution Protocol) lookup and directly sending the transparent proxy message correctly.

[0066] The preparatory work for implementation of the scheme of this embodiment includes: adding an ebtable extension module to the kernel to extend the matching function, that is, to check whether the TCP message entering the proxy device belongs to an established Socket or a listening transparent proxy Socket. If so, set skb→mark to 1; adding a structure to the kernel. This embodiment uses tproxy_option to save the input interface index and Ethernet frame header MAC information of the SYN message, and at the same time adding an IP option IP_TPROXY_MAC_INFO to the kernel Socket to obtain and set the input interface index and Ethernet frame header MAC information on the Socket interface; adding a user layer extension corresponding to the ebtalbes module to send qualified transparent proxy messages to the kernel network layer for routing lookup; adding policy routing to route transparent proxy messages to the local loopback interface; configuring the bridge and adding the two service ports required for forwarding to the bridge.

[0067] Afterwards, the workflow of this embodiment mainly includes the process of processing the SYN message of the client and the process of establishing a connection with the server. The process of processing the SYN message of the client is as follows: Figure 2 Shown, including:

[0068] S201. The kernel bridge module receives a first SYN message. Specifically, the first SYN message is a SYN message sent by a client to a server to request establishment of a TCP connection.

[0069] S202. Determine whether the first SYN message is a transparent proxy message. If so, execute S203; otherwise, execute S209. Specifically, when the kernel bridge module receives the transparent proxy message skb, it performs an ebtables extended match. If the match is successful, it sets the skb→mark=1. For messages with skb→mark=1, the kernel prohibits setting the destination MAC address to the ingress interface MAC address.

[0070] S203, routing the first SYN message to the local server through a policy;

[0071] S204. Create a request_sock structure;

[0072] S205. Save the Ethernet frame header information on the first SYN message in the request_sock structure. Specifically, the kernel socket layer receives the SYN request, creates a request_sock structure, and adds tproxy_option information to the structure to save the MAC address information and SYN inbound interface index in the SYN message.

[0073] S206: Construct a first SYN-ACK message, reverse the source MAC address and destination address in the MAC address information stored in the request_sock structure, and then use the Netfilter Post_Routing Hook to add Ethernet frame header information to the first SYN-ACK message;

[0074] S207, using the dev_queue_xmit function to send the first SYN-ACK message out;

[0075] S208. When receiving the ACK message returned by the client, determine that the TCP connection with the client is normal;

[0076] S209: Directly forward the first SYN message.

[0077] The process of establishing a connection with the server is as follows Figure 3 Shown, including:

[0078] S301. Set SO_BINDTO_DEVICE for the newly created Socket, with the value being the interface index stored in tproxy_option during the client SYN message processing process.

[0079] S302: Construct a second SYN message and send it out based on the saved interface index. Specifically, the kernel constructs the second SYN message and sends it to the IP layer. The message passes through the POST_ROUTING hook of Netfilter. A callback function is added to the hook to reset the outgoing SYN transparent proxy skb→data offset data, correctly set the Ethernet frame header information, and use the sk_bound_dev_if interface index set on the sock to find another interface on the bridge where this interface is located through the bridge module. The corresponding struct net_device pointer is obtained and the dev_queue_xmit function is called to send the second SYN message directly from the network card.

[0080] S303: Receive a second SYN-ACK message returned by the server;

[0081] S304. Update sk_bound_dev_if to the index of the second SYN-ACK message inbound interface; specifically, the second SYN-ACK message is the SYN-ACK message returned by the server. When the kernel receives the SYN-ACK message returned by the server from the interface, after the ebtables rule is successfully matched, the skb→mark is set and the policy routing is performed to enter the local loopback interface for processing. After the second SYN-ACK message arrives at the TCP processing module of the local kernel protocol stack, the sk_bound_dev_if on the sock structure is updated to the second SYN-ACK message input interface index, and the dst_cache (route cache) saved for this sock is cleared to facilitate the transparent proxy message to find the correct outgoing interface. At this point, the connection between the proxy process and the back-end server has been successfully established. Subsequent transparent proxy messages sent to the server only need to use the sk_bound_dev_if saved in the sock structure in the POST_ROUTING of Netfilter to obtain the corresponding net_device pointer, and then reset the Ethernet MAC information of the outgoing message and call dev_queue_xmit to send it, so as to realize the outgoing of the transparent proxy message to the server.

[0082] The solution of the embodiment of the present application utilizes Linux ebtables and Bridge modules, through policy routing and kernel protocol stack, to implement transparent proxy in pure switching network transparent bridge mode.

[0083] Corresponding to the embodiments of the aforementioned method, the present application also provides embodiments of a bridge transparent proxy device and a terminal using the same:

[0084] like Figure 4 As shown, Figure 4This is a block diagram of a bridge transparent proxy device provided by an embodiment of the present application. The device is applied to a transparent proxy device. The Linux bridge of the transparent proxy device is configured with two service ports. The device includes:

[0085] The frame header storage module 41 is used to intercept the TCP SYN message sent by the client to the server and save the Ethernet frame header information in the SYN message; the Ethernet frame header information includes MAC address information and SYN inbound interface index;

[0086] The first outgoing module 42 is configured to construct a SYN-ACK message, reverse the source MAC address and destination MAC address in the stored Ethernet frame header information using a specified hook point, add the reversed address to the SYN-ACK message header, and send the SYN-ACK message out of the service port corresponding to the SYN inbound interface index. Upon receiving a message from the client again, the first outgoing module 42 determines to establish a connection with the client.

[0087] The second outgoing module 43 is used to construct a target SYN message when establishing a connection with the server, use the specified hook point to add the saved Ethernet frame header information to the target SYN message, and send the target SYN message out from the target outgoing interface; the target outgoing interface is another business port on the Linux bridge other than the business port corresponding to the SYN inbound interface index.

[0088] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0089] This application also provides an electronic device, see Figure 5 , Figure 5 This is a block diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include a processor 510, a communication interface 520, a memory 530, and at least one communication bus 540. The communication bus 540 is used to enable direct communication between these components. The communication interface 520 of the electronic device in this embodiment of the present application is used to communicate signaling or data with other node devices. The processor 510 may be an integrated circuit chip with signal processing capabilities.

[0090] The processor 510 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 device, a discrete gate or transistor logic device, or a discrete hardware component. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor, or the processor 510 can also be any conventional processor.

[0091] The memory 530 may be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The memory 530 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 510, the electronic device can perform the above-mentioned operations. Figure 1 The various steps involved in the method embodiment.

[0092] Optionally, the electronic device may further include a storage controller and an input / output unit.

[0093] The memory 530, storage controller, processor 510, peripheral interface, and input / output units are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses 540. The processor 510 is used to execute executable modules stored in the memory 530, such as software function modules or computer programs included in the electronic device.

[0094] The input and output unit is used to provide users with the ability to create tasks and to create optional time periods or preset execution times for the tasks to enable interaction between the user and the server. The input and output unit can be, but is not limited to, a mouse and a keyboard.

[0095] I understand. Figure 5 The structure shown is only for illustration, and the electronic device may also include Figure 5 More or fewer components than shown, or with Figure 5 Different configurations shown. Figure 5 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0096] An embodiment of the present application further provides a storage medium having instructions stored thereon. When the instructions are run on a computer, the computer program is executed by a processor to implement the method described in the method embodiment. To avoid repetition, details are not given here.

[0097] The present application also provides a computer program product, which, when running on a computer, enables the computer to execute the method described in the method embodiment.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0099] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0100] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0101] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0102] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0103] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A bridge transparent proxy method, characterized in that: Applied to a transparent proxy device, wherein the Linux bridge of the transparent proxy device is configured with two service ports; the method comprises: Intercepting the TCP SYN message sent by the client to the server, and saving the Ethernet frame header information in the SYN message; the Ethernet frame header information includes MAC address information and SYN inbound interface index; Constructing a SYN-ACK message, using a specified hook point to reverse the source and destination MAC addresses in the stored Ethernet frame header information, adding the reversed address to the SYN-ACK message header, and sending the SYN-ACK message out of the service port corresponding to the SYN inbound interface index. Upon receiving a message from the client again, determining to establish a connection with the client; the specified hook point is the POST_ROUTING hook point of Netfilter; When establishing a connection with the server, construct a target SYN message, add the saved Ethernet frame header information to the target SYN message using the specified hook point, and send the target SYN message out from a target outgoing interface; the target outgoing interface is another service port on the Linux bridge other than the service port corresponding to the SYN inbound interface index; The Linux kernel of the transparent proxy device is provided with an ebtables extension module; the interception of the TCP SYN message sent by the client to the server includes: Match incoming TCP packets through the ebtables extension module to determine whether the TCP packets belong to an established socket or a monitored transparent proxy socket; the TCP packets include SYN packets; If the match is successful, the TCP message is sent to the Linux kernel through policy routing.

2. The method according to claim 1, characterized in that Before sending the TCP message to the Linux kernel through policy routing, the method includes: The TCP message is marked with Mark X; and the Linux kernel is configured to prohibit setting the destination MAC address as the ingress interface MAC address for the message marked with Mark X.

3. The method according to claim 1, characterized in that The storing of the Ethernet frame header information in the SYN message includes: Create a request_sock structure, and add tproxy_option information in the request_sock structure, where the tproxy_option information is used to record the Ethernet frame header information in the SYN message.

4. The method according to claim 1, wherein The target socket parameters are set in the Linux kernel of the transparent proxy device; the method further includes: The target socket parameters are updated based on the index of the service port receiving the message returned by the server.

5. The method according to claim 4, characterized in that The method further comprises: When there is a transparent proxy message that needs to be sent to the server, the message header of the transparent proxy message is set using the target socket parameter, and the transparent proxy message is sent out from the target outgoing interface.

6. A bridge transparent proxy device, characterized in that: Applied to a transparent proxy device, wherein the Linux bridge of the transparent proxy device is configured with two service ports; the device comprises: The frame header storage module is used to intercept the TCP SYN message sent by the client to the server and save the Ethernet frame header information in the SYN message; the Ethernet frame header information includes MAC address information and SYN input interface index; The first outgoing module constructs a SYN-ACK message, reverses the source MAC address and destination MAC address in the stored Ethernet frame header information using a specified hook point, adds the reversed address to the SYN-ACK message header, and sends the SYN-ACK message from the service port corresponding to the SYN inbound interface index. When receiving a message from the client again, the first outgoing module determines to establish a connection with the client. The specified hook point is the POST_ROUTING hook point of Netfilter. a second outgoing module, configured to construct a target SYN message when establishing a connection with the server, add the stored Ethernet frame header information to the target SYN message using the designated hook point, and send the target SYN message out of a target outgoing interface; the target outgoing interface being another service port on the Linux bridge other than the service port corresponding to the SYN inbound interface index; The Linux kernel of the transparent proxy device is provided with an ebtables extension module; the frame header storage module is specifically used to: match the incoming TCP message through the ebtables extension module to determine whether the TCP message belongs to an established socket or a listening transparent proxy socket; the TCP message includes a SYN message; if the match is successful, the TCP message is sent to the Linux kernel through policy routing.

7. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

8. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method according to any one of claims 1 to 5 is implemented.

Images