Reverse TCP proxy redirects traffic from the user to the client's upstream and vice versa.
Reverse TCP proxy is similar in principle to reverse HTTP proxy, but operates at the transport layer of the OSI/ISO network model and parses TCP traffic. Malicious TCP traffic is cut off and does not reach the upstream. So, Qrator Labs reverse TCP proxy protects sites from DDoS attacks at the transport layer (L4).
TCP proxy can also be used to protect against DDoS attacks at the application layer (L7), acting as an alternative to reverse HTTP proxy. To do this, you need to configure automatic sending of logs from your server to the Qrator Labs server.
Note that this is not equivalent to full application-layer traffic processing (TCP proxy does not work at that level), so you cannot use such a proxy for web application filter or anti-bot protection. These products work strictly at the application layer and require an HTTP reverse proxy.
- When the server needs to see user TCP segment headers;
- When it's necessary to protect a resource running on protocols other than HTTP and HTTPS from DDoS attacks;
- When it's necessary to establish a
point-to-pointconnection with a server running Windows.
Proxy Protocol mode
If your upstream software supports Proxy Protocol, the reverse TCP proxy can send it both the contents of user TCP segments and information about the IP addresses they came from. The upstream should also send return traffic using Proxy Protocol through Qrator Labs network from where they will be redirected to the user.
Proxy Protocol support is built into financial broker trading platform MetaTrader, so a reverse TCP proxy can protect the trading gateways on that platform against DDoS attacks. In this case, instead of receiving TCP traffic from users directly, the MetaTrader gateway in the broker's network only receives it from the reverse TCP proxy in the Qrator Labs network. Illegitimate traffic from users is not sent to the broker's network and does not threaten the gateway performance.
Under Proxy Protocol, at the beginning of each TCP connection, the upstream receives a header with information about the IP addresses of the sender and receiver of the original segment. All other data can be obtained directly from the forwarded segment. It means that after proper header processing, the software on the upstream side can implement the same functions as when receiving TCP traffic directly without reverse proxy, e.g. logging sender's IP address or performing other actions.
In the figure, the upstream substitutes a separately received header for each segment received within that connection, thus recreating all the information sent by the user:
For information on how to connect a reverse TCP proxy in Proxy Protocol mode, see relevant section.
Raw TCP Proxy mode
To protect upstreams that do not support Proxy Protocol, use a reverse TCP proxy in Raw TCP Proxy mode. In this mode, having received a TCP segment from a user, the reverse TCP proxy simply proxies this segment, acting as the sender of the segment for the upstream. No additional information about the original sender is passed to the upstream.
When using Raw TCP Proxy, the upstream cannot get information about the user's IP address, unless it is provided by a higher-layer protocol. That's why this mode is mostly used for protocols that provide for a way of authentication that doesn't rely on the sender's IP address. For example, with Raw TCP Proxy, you can protect against DDoS attacks that are aimed at the SSH server behind an upstream.
The main advantage of Raw TCP Proxy over Proxy Protocol is that you don't need to configure it on the upstream side. The upstream accepts legitimate TCP segments from the Qrator Labs network just like it would accept them directly from users.
Qrator Labs Raw TCP Proxy protects resources from DDoS attacks no higher than the transport layer (L4).
For information on how to connect Raw TCP proxy, see relevant section.