DE102023105918A1 - Method for transferring data between two networks - Google Patents

Abstract

The invention relates to a computer-implemented method (100) and a system for transmitting data between a first network (1) and a second network (2) that is different from the first network (1). The invention further relates to a data structure comprising a SOCKS request according to the SOCKS protocol, a computer program and a computer-readable storage medium. A client domain (3) and a gateway domain (5) are provided within the first network (1), with at least one client (4a; 4b) being arranged in the client domain (3) and a proxy server (6) and at least one relay server (7; 8) being arranged in the gateway domain (5). For this purpose, a request based on the SOCKS protocol is received by the proxy server (6) and a SOCKS reply is sent back. Now a data transfer is established between the client domain (3), the relay server (7; 8) and the second network (2) based on the SOCKS request and the SOCKS reply. The SOCKS request has at least one of the following additional parameters: protocol type, origin address of the client (4a; 4b), type of origin address of the client (4a; 4b) and origin port of the client (4a; 4b).

Description

The invention relates to a computer-implemented method and a system for transmitting data between a first network and a second network that is different from the first network. The invention also relates to a data structure comprising a SOCKS request according to the SOCKS protocol, a computer program and a computer-readable storage medium.

So-called firewalls are used to effectively protect a computer system in an internal network from an external network or to control access to the computer system in the internal network. Firewalls can be used to offer various services such as TELNET, FTP and SMTP under controlled conditions at the application layer level.

However, the ever-growing need to communicate and transfer data between an internal network and an external network via such services requires ever more solutions tailored to each application in order to prevent possible hacker attacks, data theft and system failures.

For this purpose, so-called proxy servers are usually used, which act as an intermediary and process requests from a computer or computer system in the internal network and forward them to the external network without the external network communicating directly with the computer in the internal network.

The so-called SOCKS protocol has become established. This is an Internet protocol that allows client-server applications to use the services of a proxy server in a protocol-independent and transparent manner. Clients behind a firewall that want to establish a connection to an external server connect directly to a SOCKS proxy server instead of to the external server. This proxy server checks whether the client is authorized to contact the external server or the external server is authorized to contact the client, and forwards the request to the server or the client.

WO 02/065650 A2 For example, discloses a method for securely transmitting data when using an insecure communication protocol such as the User Datagram Protocol (UDP). The SOCKS protocol is used so that secure UDP datagrams can be exchanged between a proxy server and a client computer.

WO 2012/006595 A2 discloses a method for establishing an optimized communication connection with improved performance of at least one application. For this purpose, various performance requirements of an application are determined, then information regarding the possible capacity of various communication channels is recorded and these channels are controlled on the basis of this information.

However, if several clients within an internal network want to communicate and exchange data with one or more external servers via the proxy server, a separate connection can be created for each client by the proxy server. However, all communication between clients in the internal network and servers in the external network takes place via this SOCKS proxy server, which can have a negative impact on the overall system if the data transfer increases.

Since essentially all data traffic is carried out via the SOCKS proxy server, the possible data transfer rate, latency, etc. depends on the properties of the proxy server. This often represents a bottleneck when several clients want to communicate with servers in external networks via the SOCKS proxy server. To counteract this, so-called TCP slicing can be used. However, this is not very efficient with high data volumes and additional hardware is required.

It is therefore an object of the present invention to improve communication via the SOCKS protocol. In particular, it is an object of the present invention to improve the transmission of data between a client located in an internal network and a server located in an external network.

The problem is solved by a computer-implemented method, a system, a data structure, a computer program and a computer-readable storage medium for transmitting data between a first network and a second network different from the first network.

A first aspect relates to a computer-implemented method for transmitting data between a first network and a second network that is different from the first network. In a first step, a client domain is provided within the first network, wherein at least one client is arranged in the client domain.

Furthermore, a gateway domain is provided within the first network, with a gateway proxy server arranged in the gateway domain, which is set up to control the data exchange between the client domain and the second network. In a further step, a request based on the SOCKS protocol is received by the gateway proxy server. The SOCKS request requests the gateway proxy server to establish and provide a data connection between the client and the second network.

For this purpose, a relay server is provided within the gateway domain by the gateway proxy server, taking into account the information transmitted in the SOCKS request. The gateway proxy server then sends a SOCKS reply to the client, which contains information on how the client and the second network can communicate via the relay server. A data transfer is now established between the client domain, the relay server and the second network based on the SOCKS request and the SOCKS reply.

The SOCKS request has at least one of the following additional parameters: protocol type, client source address, client source address type, and client source port.

The invention is based on the idea that a separate relay server can be provided for each application or client within the first network, so that if there are several clients or increased data traffic from one client, not all of the data traffic is transmitted by the proxy server, but by several relay servers. The proxy server therefore only has a controlling function, i.e. the data exchange between client and server is set up directly via a separate relay server. The relay server preferably operates at IP level, in which the destination address and port number of the server or the source address of the client are known and the relay server transmits the data transparently. If the ports at the destination and at the client are preferably known in advance, routing can be carried out purely at IP level and there is no need to use a proxy server.

A second aspect relates to a system for transmitting data between a first network and a second network that is different from the first network. The system has means for carrying out the method according to the first aspect.

A third aspect relates to a data structure comprising a SOCKS request according to the SOCKS protocol, wherein the SOCKS request additionally comprises at least one of the following parameters: protocol type, client origin address, client origin address type, and client origin port.

A fourth aspect relates to a computer program which, when executed by a computer, causes the computer to carry out the method according to the first aspect or to use the data structure according to the third aspect.

A fifth aspect relates to a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the first aspect or has the data structure according to the third aspect.

According to a preferred embodiment, the SOCKSv5 protocol is used. This protocol is specified in more detail in the standard RFC 1928 and is available on the Internet Engineering Task Force (IETF) website. https://datatracker.ietf.org/doc/html/rfc1928 ). This protocol standard is characterized by an extended command set, which makes the use of a method according to the first aspect particularly efficient.

According to a further preferred embodiment, the CMD parameter in the SOCKS request can be supplemented with an additional TRANSPARENT MODE. If a proxy server or, in this case, the relay server controlled by the proxy server is transparent, the data traffic between client and server is not changed or only changed to a small extent. The throughput of data can therefore be increased according to the principle of bandwidth with computer power by applying the extensions in the SOCKS request and using the TRANSPARENT MODE between clients and Internet servers, e.g. without splitting connections in the proxy at transport protocol level.

This is particularly advantageous because, in comparison to other transmission protocols, where the data traffic must be analyzed and adjusted if necessary, the data to be transmitted is not adjusted by the proxy or relay server. Thus, using a TRANSPARENT MODE is particularly efficient in processing and forwarding data, which in turn results in lower latency and lower data error rates.

According to a further preferred embodiment, the protocol type parameter in the SOCKS request identifies the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP). UDP is a minimal, connectionless network protocol that belongs to the transport layer of the Internet Protocol family (IP family). UDP therefore enables applications to send datagrams in IP-based computer networks. So-called ports are used to send sent data to the correct application or program on the client or server. For this purpose, each datagram contains the number of the source or destination port of the service or computer that is to receive the data. UDP also offers the option of an integrity check by sending a checksum. This allows incorrectly transmitted datagrams to be identified and discarded.

TCP, on the other hand, is a network protocol that defines how data should be exchanged between network components. It is also part of the IP family. In contrast to connectionless UDP, TCP establishes a connection between two endpoints of a network connection (sockets). Data can be transmitted in both directions on this connection. TCP has the positive properties that data loss can be detected and automatically corrected, data transmission is possible in both directions and network overload can be prevented.

This allows SOCKS-based TCP streaming to be enabled by an IP router as the main component of the relay server instead of a TCP proxy. This also applies to UDP, with the advantage that special datagram handling as provided for in the RFC1928 standard is no longer required, allowing native UDP solutions to be applied to each component used.

A further advantage of using an IP router for the transport protocols supported by the inventive method is that data traffic can be offloaded to the kernel space, which increases performance.

According to a further preferred embodiment, the method according to the first aspect has the following additional step: configuring, in particular securing, the source port to which the client can be connected before the SOCKS reply is sent. This step is advantageous because an unsecured (source) port on the client potentially poses the risk that malware or the like can be introduced into the client or even into the first network and, in the worst case, affect the first, internal network.

According to a further preferred embodiment, the SOCKS reply contains information about which port and which address of the relay server data can be transmitted via. In this way, data transmission between the client and the external server can be particularly simple and efficient. Since the client receives the port number and the address from the relay server, via which the client can communicate with the server in the second network more transparently and thus with less latency through the relay server, data exchange is particularly easy.

According to a further preferred embodiment, the relay server only forwards transmitted data that corresponds to the parameters defined in the SOCKS request. This makes it possible for essentially only the data that corresponds to the specific parameters defined by the SOCKS proxy server to be forwarded from the server to the client or from the client to the server via the relay server. This increases the security that no unauthorized and potentially dangerous data reaches the first, internal network, in particular to the client.

According to a further preferred embodiment, the method according to the first aspect comprises the following additional step: dissolving the relay server if the data transfer was successful. This improves network security in the first network, since external access to the internal network via the relay server is only available for a predetermined data transfer. The risk of unauthorized access by an unauthorized external device is thus reduced.

According to a further preferred embodiment, the method according to the first aspect has the following additional step: dissolving the relay server after a predetermined time interval has elapsed. This makes it possible to send and/or receive data between the server in the second, external network and the client in the first, internal network via the relay server provided by the SOCKS proxy server only for a predetermined period of time. This also increases security, as the risk of unauthorized access to the internal network, in particular the client, via the relay server can be reduced.

According to a further preferred embodiment, the method according to the first aspect has the following additional step: dissolving the relay server if the target address defined in the SOCKS request is different from the target address stored in the received data transmission and/or the target port defined in the SOCKS request is different from the target port stored in the received data transmission. In this way, unauthorized attacks such as those based on the brute force method can be efficiently fended off.

For use cases or application situations that may arise during the method and which are not explicitly described here, it may be provided that, in accordance with the method, an error message and/or a request to enter user feedback is issued and/or a default setting and/or a predetermined initial state is set.

The invention also includes a control device for a motor vehicle. The control device can have a data processing device or a processor device that is set up to carry out an embodiment of the method according to the invention. For this purpose, the processor device can have at least one microprocessor and/or at least one microcontroller and/or at least one FPGA (Field Programmable Gate Array) and/or at least one DSP (Digital Signal Processor). Furthermore, the processor device can have program code that is set up to carry out the embodiment of the method according to the invention when executed by the processor device. The program code can be stored in a data memory of the processor device. The processor device can be based, for example, on at least one circuit board and/or on at least one SoC (System on Chip).

The motor vehicle according to the invention is preferably designed as a motor vehicle, in particular as a passenger car or truck, or as a passenger bus or motorcycle.

As a further solution, the invention also includes a computer-readable storage medium, comprising program code which, when executed by a computer or a computer network, causes it to carry out an embodiment of the method according to the invention. The storage medium can be provided at least partially as a non-volatile data memory (e.g. as a flash memory and/or as an SSD - solid state drive) and/or at least partially as a volatile data memory (e.g. as a RAM - random access memory). The storage medium can be arranged in the computer or computer network. However, the storage medium can also be operated, for example, as a so-called app store server and/or cloud server on the Internet. The computer or computer network can provide a processor circuit with, for example, at least one microprocessor. The program code can be provided as binary code and/or as assembler code and/or as source code of a programming language (e.g. C) and/or as a program script (e.g. Python).

The invention also includes combinations of the features of the described embodiments. The invention therefore also includes implementations that each have a combination of the features of several of the described embodiments, provided that the embodiments have not been described as mutually exclusive.

• 1 ein Flussdiagramm bezüglich eines computer-implementierten Verfahrens zum Übertragen von Daten zwischen einem ersten Netzwerk und einem von dem ersten Netzwerk unterschiedlichen zweiten Netzwerk;
• 2 eine erste schematische Abbildung aufweisend Komponenten zum Übertragen von Daten zwischen einem ersten Netzwerk und einem von dem ersten Netzwerk unterschiedlichen zweiten Netzwerk; und
• 3 eine zweite schematische Abbildung aufweisend Komponenten zum Übertragen von Daten zwischen einem ersten Netzwerk und einem von dem ersten Netzwerk unterschiedlichen zweiten Netzwerk.

Embodiments of the invention are described below.

• 1 a flowchart relating to a computer-implemented method for transmitting data between a first network and a second network different from the first network;
• 2 a first schematic diagram comprising components for transmitting data between a first network and a second network different from the first network; and
• 3 a second schematic diagram comprising components for transmitting data between a first network and a second network different from the first network.

The exemplary embodiments explained below are preferred embodiments of the invention. In the exemplary embodiments, the components of the embodiments described each represent individual features of the invention that are to be considered independently of one another and which also develop the invention independently of one another. Therefore, the disclosure should also include combinations of the features of the embodiments other than those shown. Furthermore, the described embodiments can also be supplemented by other features of the invention already described.

In the figures, identical reference symbols designate functionally identical elements.

1 shows a flow chart relating to a computer-implemented method 100 for transmitting data between a first network 1 and a second network 2 different from the first network 1.

In a first step 101, a client domain 3 is provided within the first network 1. The client domain 3 has a client 4a. This client 4a communicates with one or more applications 9a, 9b, which are usually designed as programs of an operating system in a computer.

In a second step 102, a gateway domain 5 is provided within the first network 1. This gateway domain 5 has a gateway proxy server 6. The gateway proxy server 6 is set up to control the data exchange between the client domain 3, in particular the client 4a, and the second network 2. At least one backend server is normally arranged within the second, external network 2, which exchanges data with the client 4a of the client domain 3.

Next, a so-called SOCKS request is received 103 by the gateway proxy server 6. This was preferably sent beforehand by the client 4a, since the latter wants to establish a connection to the second, external network 2. In order to meet any security requirements, a connection request is sent via the gateway proxy server 6 - instead of communicating directly with the second, external network 2 and exchanging data. The gateway proxy server 6 thus acts as an intermediary, which can monitor the communication between the client 4a and the second, external network 2 and adapt it if necessary.

In addition, the SOCKS request additionally has at least the following parameters: protocol type, source address of the client 4a, type of source address of the client 4a and source port of the client 4a.

The following table shows a data structure that corresponds to the SOCKS request based on the SOCKS protocol and additionally has the parameters protocol type, source address of the client 4a, type of source address of the client 4a and source port of the client 4a: parameter Explanation Example VER Protocol version X'05' CMD command CONNECT X'01' BIND X'02' UDP ASSOCIATE X'03' RSV Reserved X'00' ATYP Address type 1 DST.ADDR Desired destination address Variable; e.g. an IP address: 1.2.3.4 DST.PORT Desired destination port 8090 PTCL Protocol type TCPX'06' UDP X'11' ATYP Client origin address type 1 SRC.ADDR Client's origin address 2.3.4.5 SRC.PORT Client origin port 5050

The SOCKS request has the protocol type parameter by default. For this described procedure, the SOCKS request can have the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP), so that a data connection can take place based on one of these two protocols.

Additionally or alternatively, this SOCKS request can be extended with a TRANSPARENT MODE in the CMD parameter. This preferably has its own identifier such as "TRANSPARENT X'04'". Based on a SOCKS TRANSPARENT link, a control path can be established between the client 4a, 4b and the gateway proxy server 6 in order to exchange configuration requests between the client 4a, 4b and the gateway proxy server 6.

Based on the received SOCKS request, the gateway proxy server 6 provides a relay server 7 104. This is configured by the gateway proxy server 6 in such a way that it forwards the data for the client 4a to a second, external network 2 or a server located in the second network 2. The parameters DST.ADDR and DST.PORT as well as the client-side parameters SRC.ADDR and SRC.PORT are used for this purpose to configure the relay server 7. The so-called interception can be carried out on an IP basis by the relay server 7. A PTCL-TRANSPARENT interception can be used to improve the control of data connections.

In this way, it is also possible for one or more clients 4a, 4b to use multiple relay servers 7, 8 to transmit data from the first, internal network 1 to the second, external network 2 or to receive data from it. This means that multiple parallel connections can exist between a client 4a, 4b and the second, external network 2, which can increase the overall data throughput. For example, it is possible for a separate relay server 7, 8 to be provided and configured by the gateway proxy server 6 for each client 4a, 4b within the client domain 3.

In a further step 105, the source port to which the client 4a, 4b can be connected is configured before a SOCKS reply is sent. This step makes it possible to secure the first, internal network 1 and in particular access to the client 4a, 4b in order to make it more difficult, and preferably prevent, the introduction of malware, for example.

A SOCKS reply message is then sent 106 from the gateway proxy server 6 to the client 4a. The SOCKS reply message contains information on how communication can take place between the client 4a and the second, external network 2 via the first relay server 7. For example, it can specify which protocol version is to be used. The SOCKSv5 protocol is preferably used. This has many configuration options, which means that the requirements for a data connection between the client 4a and the second, external network 2 can be individually addressed. The SOCKS reply preferably contains information on which port and which address of the relay server 7 data can be transmitted via. This can preferably be done using the two parameters BND.PORT and BND.ADDR.

In a further step 107, the data transmission between the client domain 3, in particular the client 4a, the first relay server 7 and the second, external network 2 can be established on the basis of the configuration requested in the SOCKS request and sent in the SOCKS reply. This enables data exchange between the client 4a and the second, external network 2 via the Proxy server 6 provides a relay server 7, whereby the properties of proxy server 6 still apply. Preferably, relay server 7 is set up to only forward transmitted data to client 4a which corresponds to the parameters defined in the SOCKS request.

Should the case arise that the destination address defined in the SOCKS request is different from the destination address stored in the received data transmission and/or the destination port defined in the SOCKS request is different from the destination port stored in the received data transmission, the data received from the relay server 7 and originating from the second, external network 2 are ignored 108. This can further increase the security in the data exchange between the client 4a and the second, external network 2.

As soon as the data transfer was successful and thus completed, the relay server 7 is preferably closed again 109a. This is done in particular by breaking off the control channel between the proxy server 6 and the relay server 7. This step closes gaps in the first, internal network 1, since access from the second, external network 2 via the relay server 7 is no longer possible. This serves in particular to ensure the security of the first network 1.

Alternatively or additionally, a relay server 7 can also be closed after a predetermined time interval has elapsed 109b. Thus, a data exchange between the client 4a and the second, external network 2 is limited in time, which in turn serves the security of the first network 1 by being at least temporarily protected against access from the second, external network 2.

In a further alternative or additional step 109c, the relay server 7 is resolved if the destination address defined in the SOCKS request is different from the destination address stored in the received data transmission and/or the destination port defined in the SOCKS request is different from the destination port stored in the received data transmission.

This step is similar to the ignoring step 108, but with the difference that transmitted data packets are not only ignored by the relay server 7, but the connection is completely terminated by dissolving the relay server 7. Thus, depending on requirements and potential security risks, the data transmission via the relay server 7 can be ignored or completely terminated, which in particular increases the configuration options.

Preferably, the method 100 also comprises any steps relating to the authentication between the first network 1 and the second network 2. This additionally serves for secure data transmission between the client 4a, 4b and a backend server located in the second network 2.

2 shows a first schematic illustration comprising components for transmitting data between the first network 1 and the second network 2 which is different from the first network 1.

The first, internal network 1 has a client domain 3 and a gateway domain 5. In this example, a client 4a is arranged in the client domain 3, which is connected to a first application 9a. The application 9a preferably wants to communicate with the external network 2 and uses the client 4a for communication.

In order to enable data exchange between the client 4a and the second network 2, a proxy server 6 is arranged in the gateway domain 5, which does not itself forward the data. Therefore, only one configuration connection is provided between the client 4a and the proxy server 6, which is shown as a dashed line, i.e. preferably no user data is transmitted between the client 4a and the proxy server 6, but only data for configuring a data connection between the client 4a and the second, external network 2.

Rather, the proxy server 6 serves to provide a relay server 7, via which user data of the client 4a can be transmitted to the second network 2 or received from it. The proxy server 6 therefore only has the function of providing and configuring the relay server 7, in particular depending on the properties of the client 4a requested in the SOCKS request.

As soon as the data connection between the client 4a and the second network 2 has been established via the relay server 7 by the proxy server 6, the client 4a and the second network 2 can exchange data from Preferably, it is also possible for several applications 9a, 9b to communicate and exchange data via the one client 4a with the second network 2 via the one relay server 7.

3 shows a second schematic diagram comprising components for transmitting data between the first network 1 and the second network 2, which is different from the first network 1. This diagram differs from the one in 2 Shown in that, on the one hand, another client 4b is connected to another application 9b and both are arranged in the client domain 3.

Furthermore, the gateway domain 5 now has a further relay server 8 in addition to the relay server 7, which is connected to the application 9a via the client 4a. This further relay server 8 is connected to the further application 9b via the further client 4b, so that each application 9a, 9b can have its own client 4a, 4b. The two clients 4a, 4b are in turn each connected to the second network 2 with their own relay server 7, 8.

Data can thus be received from the applications 9a, 9b in parallel via the two clients 4a, 4b or relay servers 7, 8 to the second network 2 or from this second network 2. In this way, the data throughput can be significantly increased, since not all data traffic between the first, internal network 1 and the second, external network 2 runs via a proxy server 6 as is usual, but the data traffic can be distributed across several relay servers 7, 8, whereby bottlenecks due to hardware limitations or software-specific circumstances such as a maximum packet size can be reduced, in particular prevented. The two relay servers 7, 8 are preferably each connected via their own connection to the proxy server 6, which can thus control and configure the relay servers 7, 8 individually.

Preferably, a separate client 4a, 4b can be provided for each application 9a, 9b in the first, internal network 1, which in turn can exchange data between a respective application 9a, 9b and the second, external network 2 with its own relay server 7, 8. This parallelization can also increase the latency in data exchange and the security of the first network 1, since only those applications from the second network 2 that are also connected on the basis of the SOCKS protocol via the clients and relay servers 7, 8 assigned to them can be reached via the relay server 7, 8.

Preferably, at least one of the relay servers 7, 8 can benefit from capabilities already built into the hardware or software on which the gateway domain 5 is operated with regard to an IP connection or IP communication. For example, a Linux kernel can have the ability to support kernel hooks. Operations and commands can be outsourced in the kernel, whereby data processing can be further optimized, in particular accelerated.

Preferably, the first network 1 is arranged in a motor vehicle such as a car. In this way, big loop tasks, in which large amounts of data are transmitted, can be carried out better. For example, various data are collected in the vehicle, in particular in an application, and transmitted to a second, external network 2, preferably a backend. There, the data can be evaluated and, for example, artificial intelligence can be trained on the basis of the collected data. An evaluation of this data or corresponding instructions for action can then be sent from the backend server, which is arranged in the second network 2, back to the vehicle, preferably the first network 1. This enables efficient data exchange between several vehicles and entire vehicle fleets and a manufacturer backend.

Furthermore, the client domain 3 and the gateway domain 5 can be designed independently of each other and preferably each have their own domain security layer.

In one embodiment, the gateway domain 5 is instantiated first. Then, for each application 9a, 9b, it is waited whether it reports to the proxy server 6 and wants to establish a connection to the second network 2. For example, an application relating to the driver's door of the vehicle in a control unit of the vehicle may want to connect to the manufacturer's backend in the second network 2. To do this, the application can send a CONNECTION request to the gateway domain 5, preferably to the gateway proxy 6. This establishes a corresponding data connection via a relay server 7, whereby each TCP packet can be forwarded bidirectionally from the proxy server 6 or the corresponding relay server 7, 8.

In summary, the invention relates to an extension of the SOCKS request defined in SOCKSv5, which is defined by RFC1928. The extension allows the SOCKSv5 protocol to additionally support transparent proxies for various types of transport protocols such as TCP or UDP. In this way, the performance of the SOCKS gateway proxy in terms of "bandwidth to computing power" can be improved by using the extension to set up transparent connections between clients and Internet servers, e.g. without splitting the connections at proxy and transport protocol level.

Firstly, the SOCKSv5 protocol is extended to support a new SOCKS request, namely the command (CMD) called TRANSPARENT association. In addition, the transport PTCL type and the client address and the client port are specified within the request. In the SOCKS reply to a TRANSPARENT Association Request (SOCKS request), the parameters BND-PORT and BND.ADDR indicate the port number or address where the client 4a can or must send its data so that PTCL-typical packets are forwarded. The new SOCKS TRANSPARENT Association handshake is preferably carried out via TCP, as is the case with the other SOCKS commands of the RFC1928 standard. The inventive extension of the SOCKS protocol is fully backwards compatible with the RFC1928 standard.

Furthermore, the SOCKS TRANSPARENT Association connection can be used to establish a control path between a client 4a and the proxy 6 for an associated connection. Each PTCL-typical relay server 7, 8 is connected to the SOCKS proxy server 6.

Furthermore, a PTCL-typical relay server 6 can transparently forward PTCL-typical data that is assigned to a SOCKS TRANSPARENT control path. In this case, the assigned PTCL relay server 7, 8 may receive and use the assigned DST.ADDR and DST.PORT information and, on the client side, the SRC.ADDR and SRC.PORT parameters of the TRANSPARENT Association Request for connection-specific relay configuration. The PTCL relay server can preferably only accept data packets that correspond to the PTCL-specific type (IP/IPv6 header: Protocol/NH Type = PTCL). Interception can be carried out at IP level by a PCTL-typical relay server 7, 8. PTCL-transparent interception can be used for so-called “stateful processing” of associated data connections.

In addition, a PTCL-typical relay server 7, 8 will preferably not forward data that is not associated with the SOCKS-TRANSPARENT control path. On the one hand, this can affect the case that a specific PTCL-typical relay data connection is terminated when the associated control path has been resolved, e.g. when the SOCKS proxy TCP connection is terminated after the TRANSPARENT association request has arrived. On the other hand, this can affect the further case that the PTCL-typical relay server 7, 8 must ignore all data packets that originate from a different source address or from a different source port than that configured in the relay connections.

The PTCL-typical relay server 7, 8 may also be able to leverage built-in capabilities related to IP communication of an operating system kernel running the relay server (e.g. Linux kernel). The advantage of kernel offloading is an improvement in throughput through data forwarding with the support of suitable kernel hooks. Furthermore, built-in kernel functions related to network address translation or network prefix translation can help to improve the overall performance of data throughput.

Overall, the examples show how a computer-implemented method 100 and a system for transmitting data between a first network 1 and a second network 2 that is different from the first network 1 can be provided. Furthermore, the examples show how a data structure comprising a SOCKS request according to the SOCKS protocol, a computer program and a computer-readable storage medium can be provided.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• WO 02065650 A2 [0006]
• WO 2012006595 A2 [0007]

Cited non-patent literature

• https://datatracker.ietf.org/doc/html/rfc1928 [0021]

Claims (15)

Computer-implemented method (100) for transmitting data between a first network (1) and a second network (2) that is different from the first network (1), comprising the steps: - providing (101) a client domain (3) within the first network (1), wherein at least one client (4a; 4b) is arranged in the client domain (3); - providing a gateway domain (5) within the first network (1), wherein a gateway proxy server (6) is arranged in the gateway domain (5), which is designed to control the data exchange between the client domain (3) and the second network (2); - receiving a SOCKS request by the gateway proxy server (6) to provide a data connection between the client (4a; 4b) and the external network (2); - providing a relay server (7; 8) within the gateway domain (5) by the gateway proxy server (6) based on the received SOCKS request; - sending a SOCKS reply by the gateway proxy server (6), wherein the SOCKS reply includes information on how communication can take place between the client (4a; 4b) and the second network (2) via the relay server (7; 8); and - establishing a data transmission between the client domain (3), the relay server (7; 8) and the second network (2) based on the SOCKS request and the SOCKS reply, wherein the SOCKS request additionally includes at least one of the following parameters: protocol type, origin address of the client (4a; 4b), type of origin address of the client (4a; 4b) and origin port of the client (4a; 4b). Procedure (100) according to Claim 1 , using the SOCKSv5 protocol. Procedure (100) according to Claim 1 or 2 , where the CMD parameter in the SOCKS request can be supplemented with an additional TRANSPARENT MODE. Method (100) according to one of the preceding claims, wherein the protocol type parameter in the SOCKS request identifies the User Datagram Protocol or the Transmission Control Protocol. Method (100) according to one of the preceding claims, comprising the following additional step: - Configuring, in particular securing, the source port to which the client (4a; 4b) can be connected before the SOCKS reply is sent. Method (100) according to one of the preceding claims, wherein the SOCKS reply comprises information about which port and which address of the relay server (7; 8) data can be transmitted via. Method (100) according to one of the preceding claims, wherein the relay server (7; 8) only forwards transmitted data which correspond to the parameters defined in the SOCKS request. Method (100) according to one of the preceding claims, comprising the following additional step: - Dissolving the relay server (7; 8) if the data transmission was successful. Method (100) according to one of the Claims 1 until 7 , comprising the following additional step: - dissolving the relay server (7; 8) after expiration of a predetermined time interval. Method (100) according to one of the Claims 1 until 7 , comprising the following additional step: - resolving the relay server (7; 8) if the destination address defined in the SOCKS request is different from the destination address stored in the received data transmission and/or the destination port defined in the SOCKS request is different from the destination port stored in the received data transmission. Method (100) according to one of the preceding claims, comprising the following additional step: - ignoring data received by the relay server (7; 8) if the destination address defined in the SOCKS request is different from the destination address stored in the received data transmission and/or the destination port defined in the SOCKS request is different from the destination port stored in the received data transmission. System for transmitting data between a first network (1) and a second network (2) different from the first network (1), comprising means for carrying out the method (100) according to one of the Claims 1 until 11 . Data structure comprising a SOCKS request according to the SOCKS protocol, wherein the SOCKS request additionally comprises at least one of the following parameters: protocol type, source address of the client (4a; 4b), type of source address of the client (4a; 4b) and source port of the client (4a; 4b). Computer program which, when executed by a computer, causes the computer to carry out the method (100) according to one of the Claims 1 until 11 or to execute the data structure according to Claim 13 to use. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method (100) according to one of the Claims 1 until 11 to execute or having the data structure according to Claim 13 .

Images