Transparent proxy mode

[krizhanovsky]

The issue is TBD and may be split into several separate issues for particular subtasks.

Transparent proxy

A DDoS filtration scenario may include the case with a transparent proxy servicing requests for large networks, e.g. /16. So Tempesta FW must intercept HTTP requests, perform full HTTP processing, and send the requests to origin destination IP with source IP as of client. In the simplest case, Tempesta FW in ransparent mode, is configured as a default route for both clients and backend server.

Tempesta FW receives traffic on a special listening address (also must be configurable on per-vhost basis, see issue #1105), let's consider a configuration example:

   vhost base {
        listen 192.168.1.10:443 proto=https;
    proxy_pass transparent=dsr,const;
    }

Note that 10.10.10.10 is an original domain address, not configured on Tmpesta FW's interface. Netfilter must be used to rewrite IP and TCP fields for redirects. Following steps happen in transparent scenario:

1. Tempesta box receives a IP packet for 10.10.10.10 (an original server destination), netfilter rewrites it to local address 192.168.1.10 by a PREROUTING DNAT rule for the whole server's network;
2. the normal TCP, TLS and HTTP processing on Tempesta FW side take place;
3. Tempesta chooses a backend server and establishes a new backend connection (as opposite to persistent connections used for now) bound to client source IP and port on local interface (routing must be appropriately configured);
4. Tempesta sends a, probably modified, HTTP request to the backend server and waits for a response;
5. Netfilter redirects the traffic with POSTROUTING SNAT rule;
6. Tempesta receives and forwards a response to a client and closes the server connection is the client connection is closed.

A new configuration attribute transparent for option proxy_pass has the following values:

• const - do not adjust HTTP messages (no X-Forwarded-For, Via and other HTTP headers), just proxy then to a peer;
• dsr (direct server return) - just schedule and send an HTTP request and free it, do not expect HTTP response (the backend server will respond to a client directly).

Direct Server Return

With DSR a proxy can not monitor state of backend servers and do very limited HTTP functionality. However, since Tempesta FW is embedded into Linux TCP/IP stack it can implement much more flexible DSR.

To get better performance, HTTP responses can bypass the HTTP processing layer in Tempesta FW, but, if the Tempesta FW box is used as a router for DSR, Tempesta FW still can

1. TLS encrypt or re-encrypt (if backend connection also uses TLS) HTTP responses and/or
2. modify HTTP requests and/or
3. measure backend server performance and detect failures.

In general we only need to proxy TCP connection from the backend to a client and rewrite seqnos, ACKs and several other options.

[fatihusta]

Kernel TPROXY feature may be an option.