Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Jack Bates <uo4zau@nottheoilrig.com>
To: Jan Engelhardt <jengelh@inai.de>
Cc: netfilter@vger.kernel.org
Subject: Re: Discriminate client requests from transparent proxy requests?
Date: Wed, 19 Dec 2012 23:42:14 -0800	[thread overview]
Message-ID: <50D2C156.2050801@nottheoilrig.com> (raw)
In-Reply-To: <alpine.LNX.2.01.1212192247440.17747@nerf07.vanv.qr>

On 19/12/12 01:51 PM, Jan Engelhardt wrote:
>
> On Wednesday 2012-12-19 17:41, Jack Bates wrote:
>>
>>> A second possibility, when proxy server and origin server are on the
>>> same Ethernet subnet, is to look at the L2 address. Of course the L2
>>> addr can be "tproxified" as well, but usually is not worth doing.
>>
>> This is a possibility, with "iptables -m mac --mac-source ..." The proxy and
>> the router are on the same subnet. Are there any other options?
>>
>> I tried adding a second IP to the router, as an alias, changing the default
>> gateway of the proxy to this other address, and matching traffic from the proxy
>> with "iptables -i br-lan:1" but I discovered that --in-interface doesn't
>> support aliases (I guess this makes sense, traffic doesn't reference the IP of
>> the next hop, so how can you tell which alias it arrived on?)
>
> Obviously, using the iptables -d option.

--destination is the ultimate destination. Say our "br-lan" router 
interface is 192.168.1.1 and our "br-lan:1" alias is 192.168.1.84. The 
default gateway for clients is 192.168.1.1, so when a client makes a 
request to an origin server, 12.34.56.78, it forwards it to 192.168.1.1 
(--destination is 12.34.56.78)

The router intercepts this request and reroutes it to our transparent 
proxy. The default gateway for the proxy is 192.168.1.84, so when it 
makes a request to the origin server, it forwards it to 192.168.1.84 
(--destination is 12.34.56.78)

I think iptables can't tell whether the request was forwarded to 
192.168.1.1 or 192.168.1.84, so it can't tell whether it arrived on the 
"br-lan" interface or the "br-lan:1" alias?

>>>> and route the former to the proxy, but not route the latter.
>>>
>>> As you have noticed, if the original client address is used, routing
>>> topology/rules needs to be laid out such that packets to client
>>> addresses always pass through the proxy server machine in both
>>> directions. (This is the same prerequisite as for connection-tracked
>>> NAT.)
>>
>> Discriminating between responses from origin servers and responses from the
>> proxy is easier because the proxy is on a different router interface than our
>> internet connection, so I use the following to reroute responses via the
>> transparent proxy:
>>
>> iptables -A PREROUTING -t mangle -i eth0.2 -p tcp --sport 80 -j MARK --set-mark
>> 1/1
>
> You probably know that, by using CONNMARK, you can always mark it..
>
> -i eth0.2 -j CONNMARK --mark 1 all packets coming from the proxy server,
> -i internet -j CONNMARK --restore-mark for all packets from $internet
>
> and then routing back to the proxy also works - based solely on fwmark.

Right, using CONNMARK to reroute responses from origin servers back via 
the proxy would also work. Thanks!

>> ip rule add fwmark 1/1 table 1
>> ip route add table 1 via 192.168.1.35

So some options for discriminating client requests from proxy requests are:

   * Application layer (e.g. Via: header)
   * --mac-source
   * TOS/DSCP field

Are there any other options worth considering? Do you have any advice 
about which to choose?

  reply	other threads:[~2012-12-20  7:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18  7:45 Discriminate client requests from transparent proxy requests? Jack Bates
2012-12-18  8:27 ` Jan Engelhardt
2012-12-19 16:41   ` Jack Bates
2012-12-19 21:51     ` Jan Engelhardt
2012-12-20  7:42       ` Jack Bates [this message]
2012-12-20  8:18         ` Jan Engelhardt
2012-12-20 12:58           ` Leonardo Rodrigues
2012-12-20 15:54           ` Neal Murphy
2012-12-20 19:35             ` Jan Engelhardt
2012-12-20 21:03               ` Neal Murphy
2012-12-18 13:35 ` Leonardo Rodrigues
2012-12-19 18:33   ` Jack Bates
2012-12-19 19:05     ` Leonardo Rodrigues
2012-12-20  7:10       ` Jack Bates

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50D2C156.2050801@nottheoilrig.com \
    --to=uo4zau@nottheoilrig.com \
    --cc=jengelh@inai.de \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox