This article describes how to connect to Qrator Labs reverse TCP proxy in Proxy Protocol or Raw TCP Proxy mode.
For more details on the principles of work and differences between these modes, see Technology: Reverse TCP proxy.
Connection in Proxy Protocol mode
Connecting to Qrator Labs using Proxy Protocol allows you to protect traffic against DDoS attacks at the TCP segment level while preserving sender information.
Required software
A TCP segment with a Proxy Protocol header is different from a regular TCP segment and requires additional processing by the receiving side. This can be handled by any upstream software that knows how to handle this protocol. For example, it can be installed on routers or individual servers.
Some specialized software packages have built-in support for Proxy Protocol. For example, the Dovecot mail server or the MetaTrader trading platform can accept a segment using this protocol without additional tools.
An up-to-date list of software supporting the Proxy Protocol can be found at HAProxy.
Note that there are two versions of the protocol. Proxy Protocol v1 uses the text header format, while Proxy Protocol v2 uses the binary format. The overhead for data transmission and processing when using the binary version of the protocol is lower compared to the text version. Some software versions support only one version of the protocol. For example, Proxy Protocol v1 is supported in NGINX 1.5.12 and later versions, but Proxy Protocol v2 is only supported in NGINX 1.13.11 and later versions.
Some software, such as the MetaTrader 5 trading platform, supports the Proxy Protocol without additional configuration.
For information on how to enable the use of Proxy Protocol in some software, please refer to the relevant documentation, e.g.:
Switching between upstreams
By default, if only one upstream is configured, the reverse TCP proxy tries to send all TCP segments from users to that upstream, and if the connection to the upstream fails within 5 seconds, it reports an error to the user.
If you have set up two or more upstreams, in case of an error when connecting to one of them, the reverse TCP proxy will connect to the next upstream on the list. Note that the same upstream check order will be used for each request. This means that if the main upstream fails for a long time, all users' requests will be handled with a delay of at least 5 seconds. So if you know that one of your upstreams is currently unavailable, contact technical support to temporarily remove it from the list of upstreams being used or change their order.
Also, at your request, Qrator Labs technical support can set up active upstream checking to automatically enable and disable each upstream depending on its availability. Active checking is performed by each node in the Qrator Labs network individually and works as follows:
-
As part of each check, the reverse TCP proxy performs a special diagnostic request about the state of each upstream. This request is made to a special healthcheck service, which can be located either on the upstream itself or on any other URL you specify. The request is made using HTTP or HTTPS to a specific URL on the upstream. If necessary, you can specify the HTTP method (GET by default), HTTP headers (including
Host) and the request body to be sent. -
If upstream fails to connect within a certain time (by default 5 seconds) or returns a response with a certain status (by default any HTTP 5xx status), this is considered an error. If necessary, the reverse TCP proxy can also check the contents of the request body as well as the upstream certificate when connecting over HTTPS.
-
By default, the reverse TCP proxy is configured such that it immediately disconnects the upstream after an error occurs. This means that user traffic will temporarily not be routed to it.
To protect against false positives, you can configure the reverse TCP proxy to, within a single check, perform several diagnostic requests one after the other immediately or with a slight delay. The reverse TCP proxy will count the number of successful and unsuccessful attempts and will end the check as soon as a certain number of successful attempts or a certain number of unsuccessful attempts have been reached. Upstream will be considered active or inactive depending on which event occurs first.
A full check of all upstreams, including those disconnected, is performed every few seconds. The default interval is 15 seconds, but this can be changed depending on your needs.
Connection setup order
Contact technical support and provide the IP addresses of the upstreams that the reverse TCP proxy should connect to using Proxy Protocol. Specify the protocol version that the software on your side supports.
-
If multiple upstreams are configured, select the necessary switching parameters.
-
If you need to protect against DDoS attacks at the application layer of the OSI/ISO model, make sure that server logs are transmitted to the Qrator Labs servers automatically for analysis. If this is not done, reverse TCP proxy will not be able to protect against application layer (L7) attacks. Check with technical support for details on log transfer options.
-
Coordinate with technical support on when to enable reverse TCP proxy. Please note that if the upstream at this IP address is currently operating via a reverse HTTP proxy, the site may be temporarily unavailable for about 10 minutes when switching over.
-
At the specified time, enable Proxy Protocol on your side.
Raw TCP Proxy connection
Raw TCP Proxy mode is suitable for cases where it is difficult or impossible to enable Proxy Protocol on the upstream, and information about the sender of TCP segments is not critical for upstream operation.
To start working with reverse TCP proxy in Raw TCP Proxy mode, contact Qrator Labs technical support and tell them which IP address and port that TCP traffic should be forwarded to and, if necessary, other additional details that the technical support would request.
No additional configuration on the upstream side is required.