ebtables extension 'http'

ebtables extension 'http'

[Felipe W Damasio]

  Hi,

  I'm using squid to cache all the content from certain domains, such
as amazon.com, googlevideo.com, etc.

  But when using:

ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-dport 80
-j redirect --redirect-target DROP

  All the http traffic is routed...and my squid doesn't handle it
well, since the ISP in question has a 600Mbps with about 10-12,000
users.

  So I thought I could develop something like this:

ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-dport 80
--http-domain '.*googlevideo.com.*' -j redirect --redirect-target DROP

  And match the regexp --http-domain with the http header on (each)
packet the match "--ip-dport 80".

  This way all the non-cacheable traffic doesn't get routed, it's
forwarded along all other traffic, and only the desirable packets are
routed to iptables and then squid.

  What do you guys think? Could this be done?

  Any thoughts would be appreciated.

  Cheers,

Felipe Damasio

Re: ebtables extension 'http'

[Jan Engelhardt]

On Monday 2010-01-25 14:46, Felipe W Damasio wrote:
>
>  This way all the non-cacheable traffic doesn't get routed, it's
>forwarded along all other traffic, and only the desirable packets are
>routed to iptables and then squid.
>
>  What do you guys think? Could this be done?

For the same reason:
http://l7-filter.sourceforge.net/FAQ#usage

Re: ebtables extension 'http'

[Felipe W Damasio]

   Hi Mr. Jan,

2010/1/25 Jan Engelhardt <jengelh@medozas.de>:
> For the same reason:
> http://l7-filter.sourceforge.net/FAQ#usage

  Right, thanks!

  But I just don't see the point of letting all the http traffic flows
through squid since it'll only care about a handful of domains...

  I don't suppose there is a way  of "putting" the connection back on
the forwarding-state on the bridge after ebtables already dropped it
on the broute table, is there?

  I was trying to get something like "if the domain is not
www.amazon.com, but it back on the bridge"...

  Thanks!

Felipe Damasio

Re: ebtables extension 'http'

[Jan Engelhardt]

On Monday 2010-01-25 15:32, Felipe W Damasio wrote:
>> For the same reason:
>> http://l7-filter.sourceforge.net/FAQ#usage
>
>  Right, thanks!
>
>  But I just don't see the point of letting all the http traffic flows
>through squid since it'll only care about a handful of domains...
>
>  I don't suppose there is a way  of "putting" the connection back on
>the forwarding-state on the bridge after ebtables already dropped it
>on the broute table, is there?

Once you decided which machine handles the packet stream, it's decided. 
The twist is, you have to decide when you see the very first packet.

Re: ebtables extension 'http'

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2010-01-25 15:32, Felipe W Damasio wrote:
>>> For the same reason:
>>> http://l7-filter.sourceforge.net/FAQ#usage
>>  Right, thanks!
>>
>>  But I just don't see the point of letting all the http traffic flows
>> through squid since it'll only care about a handful of domains...
>>
>>  I don't suppose there is a way  of "putting" the connection back on
>> the forwarding-state on the bridge after ebtables already dropped it
>> on the broute table, is there?
> 
> Once you decided which machine handles the packet stream, it's decided. 
> The twist is, you have to decide when you see the very first packet.

CT actually doesn't really care, it should be possible with TPROXY
if the local socket could be persuaded to close silently.

Re: ebtables extension 'http'

[Jan Engelhardt]

On Monday 2010-01-25 17:50, Patrick McHardy wrote:
>>>> http://l7-filter.sourceforge.net/FAQ#usage
>>>  Right, thanks!
>>>
>>>  But I just don't see the point of letting all the http traffic flows
>>> through squid since it'll only care about a handful of domains...
>>>
>>>  I don't suppose there is a way  of "putting" the connection back on
>>> the forwarding-state on the bridge after ebtables already dropped it
>>> on the broute table, is there?
>> 
>> Once you decided which machine handles the packet stream, it's decided. 
>> The twist is, you have to decide when you see the very first packet.
>
>CT actually doesn't really care, it should be possible with TPROXY
>if the local socket could be persuaded to close silently.

The issue is that you would need to replay the tcp handshake.

Case 1:
- do TCP handshake
- read out Host: header
- if proxied
  - good
- if not,
  - have to replay TCP handshake to next host (eww :-)

Re: ebtables extension 'http'

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2010-01-25 17:50, Patrick McHardy wrote:
>>>>> http://l7-filter.sourceforge.net/FAQ#usage
>>>>  Right, thanks!
>>>>
>>>>  But I just don't see the point of letting all the http traffic flows
>>>> through squid since it'll only care about a handful of domains...
>>>>
>>>>  I don't suppose there is a way  of "putting" the connection back on
>>>> the forwarding-state on the bridge after ebtables already dropped it
>>>> on the broute table, is there?
>>> Once you decided which machine handles the packet stream, it's decided. 
>>> The twist is, you have to decide when you see the very first packet.
>> CT actually doesn't really care, it should be possible with TPROXY
>> if the local socket could be persuaded to close silently.
> 
> The issue is that you would need to replay the tcp handshake.
> 
> Case 1:
> - do TCP handshake
> - read out Host: header
> - if proxied
>   - good
> - if not,
>   - have to replay TCP handshake to next host (eww :-)

You're right, that wouldn't work without even mory ugly.

Re: ebtables extension 'http'

[Felipe W Damasio]

  Hi Mr. Jan

2010/1/25 Jan Engelhardt <jengelh@medozas.de>:
> The issue is that you would need to replay the tcp handshake.
>
> Case 1:
> - do TCP handshake
> - read out Host: header
> - if proxied
>  - good
> - if not,
>  - have to replay TCP handshake to next host (eww :-)

  Would this be so bad? :-)

  I mean, if I could do this, I could reduce the HTTP traffic from
around 400Mbps to around 100Mbps of domains that the proxy actually do
cares.

  And the rest would be forwarded down the bridge.

  Could I do this with repeating the TCP handshake with the next host?
How could I do this?

  Thanks,

Felipe Damasio
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables extension 'http'

[Pascal Hambourg]

Hello,

Felipe W Damasio a écrit :
> 
> 2010/1/25 Jan Engelhardt <jengelh@medozas.de>:
>> The issue is that you would need to replay the tcp handshake.
>>
>> Case 1:
>> - do TCP handshake
>> - read out Host: header
>> - if proxied
>>  - good
>> - if not,
>>  - have to replay TCP handshake to next host (eww :-)
> 
>   Would this be so bad? :-)

Yes, quite, because it must be transparent to the client. However the
new server may have a lower MSS and not support some TCP options such as
windows scaling, ECN, selective ACK, window scaling, timestamps... that
the previous one supported and which are transmitted only during the
handshake, so the client would not know about. Not to mention that of
course it will use a different initial sequence number and it would have
to be translated by the bridge in each packet.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables extension 'http'

[Changli Gao]

On Tue, Jan 26, 2010 at 3:02 AM, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> Hello,
>
> Felipe W Damasio a écrit :
>>
>> 2010/1/25 Jan Engelhardt <jengelh@medozas.de>:
>>> The issue is that you would need to replay the tcp handshake.
>>>
>>> Case 1:
>>> - do TCP handshake
>>> - read out Host: header
>>> - if proxied
>>>  - good
>>> - if not,
>>>  - have to replay TCP handshake to next host (eww :-)
>>
>>   Would this be so bad? :-)
>
> Yes, quite, because it must be transparent to the client. However the
> new server may have a lower MSS and not support some TCP options such as
> windows scaling, ECN, selective ACK, window scaling, timestamps... that
> the previous one supported and which are transmitted only during the
> handshake, so the client would not know about.

how about learning this info from the next hop by sending a SYN packet
with all options set and the largest MSS. It sounds like TCP splicing
and SYN proxy. And I heard some one had implemented SYN proxy in
Linux, and xBSD also support SYN proxy. Is there any chance to
integrate SYN proxy and TCP splicing into Linux?

> Not to mention that of
> course it will use a different initial sequence number and it would have
> to be translated by the bridge in each packet.

NAT also need to take care of this, so we can reuse the code already
in the kernel maybe.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html