Re: REDIRECT and IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yasuyuki KOZAKAI wrote:
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Thu, 19 Jul 2007 10:59:55 +0200

squid3@xxxxxxxxxxxxx wrote:
Greetings,

Pardon if this is a dumb question. But I have searched the web, and the
source code for a solution to this one and have reached a brick wall.

I'm upgrading a user-space proxy (squid3) which has in the past done
transparent connections under IPv4-only using SO_ORIGINAL_DST.

The Firewall/router uses iptables and REDIRECT port 80 outbound to port
81. All is fine and dandy when squid listens on 0.0.0.0:81.

With the new code I have to use an IPv6 socket ( [::]:81 ) as the
receiver. With that getsockopt(..., SO_ORIGINAL_DST, ...) always returns
err "92 Protocol not supported." regardless of the IP-level parameters
passed in.

NOTE: All traffic for testing so far has been from IPv4 clients to what
they think is an IPv4 server, but with a dual-enabled middleman. The
'middleman' Software is iptables 1.3.6 on Debian 2.6.21-2-486 (unstable),
squid3 built with g++ 4.1.3.

You're right, nf_conntrack_ipv4 only registeres SO_ORIGINAL_DST for
AF_INET, changing that should make it work I believe. I feel like
I'm missing something though ..

I wrote getorigdst() for IPv6 at once but threw away it
because of no IPv6 NAT :) I hope that new tproxy will support IPv6 in future.

-- Yasuyuki Kozakai


Thanks for everything people.

Well, obviously the REDIRECT is working despite no IPv6 NAT.
What sort of a timeframe should I expect before this case is working?

Amos


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux