Merging tproxy patch to standard kernel ?
Hello It is often required to keeping source address on proxy, and tproxy seems be almost only one solution. Now, it seems be very nice if tproxy patch is merged to standard kernel. Is there any plan to merge tproxy to standard kernel ? Thank you ! -- Nihon F-Secure Corporation Yoshioka Tsuneo E-MAIL: Tsuneo.Yoshioka@f-secure.com
Hi, On p, júl 18, 2008 at 11:15:38 +0900, Yoshioka Tsuneo wrote:
It is often required to keeping source address on proxy, and tproxy seems be almost only one solution. Now, it seems be very nice if tproxy patch is merged to standard kernel.
Is there any plan to merge tproxy to standard kernel ?
Well, that's always been the plan. However, we're still not in a position to ask for merging -- there are still serious issues with the current patch (handling of related ICMP traffic). We hope to be able to address this issues but progress has been very-very slow recently... -- KOVACS Krisztian
Redirecting ICMP related traffic - I am not an kernel / netfilter hacker, but what to extend netfilter CONNMARK for that purpose ? Addition of --restore-mark-related option to CONNMARK target , witch copy connmark from master connection to related traffic probably will do this job. so then it could look like this ? iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcpo -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-xmark 0x1/0xffffffff iptables -t mangle -j CONNMARK ---save-mark // save mark on connection iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -p icmp -j CONNMARK --restore-mark-related // copy connmark from master conenction to its related stuff // now related ICMP traffic is marked too and can be directed by routing code Or I am miss some point ? And maybe marking a related traffic can be useful for other things not only for tproxy... Regards. PS: please execuse my wrong english
------------ Původní zpráva ------------ Od: KOVACS Krisztian <hidden@sch.bme.hu> Předmět: Re: [tproxy] Merging tproxy patch to standard kernel ? Datum: 21.7.2008 10:17:49 ---------------------------------------- Hi,
On p, júl 18, 2008 at 11:15:38 +0900, Yoshioka Tsuneo wrote:
It is often required to keeping source address on proxy, and tproxy seems be almost only one solution. Now, it seems be very nice if tproxy patch is merged to standard kernel.
Is there any plan to merge tproxy to standard kernel ?
Well, that's always been the plan. However, we're still not in a position to ask for merging -- there are still serious issues with the current patch (handling of related ICMP traffic).
We hope to be able to address this issues but progress has been very-very slow recently...
-- KOVACS Krisztian _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Hi, On h, júl 21, 2008 at 04:49:43 +0200, NTPT wrote:
Redirecting ICMP related traffic - I am not an kernel / netfilter hacker, but what to extend netfilter CONNMARK for that purpose ?
Addition of --restore-mark-related option to CONNMARK target , witch copy connmark from master connection to related traffic probably will do this job.
so then it could look like this ?
iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcpo -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-xmark 0x1/0xffffffff iptables -t mangle -j CONNMARK ---save-mark // save mark on connection iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -p icmp -j CONNMARK --restore-mark-related // copy connmark from master conenction to its related stuff
// now related ICMP traffic is marked too and can be directed by routing code
Yes, you're right but this requires connection tracking -- while we would like to be able to use tproxy without conntrack. But I like the idea... ;) -- KOVACS Krisztian
I thin k CONNTRACK is not so much burden in moder times and fast machines with plenty of ram . And may be using a connection tracking wisely in your example can remove some budrden from machine. AFAIK, all traffic must come through "-m socket" match, witch control if packet belongs to a listenning transparent socket on the machine (if so, then mark it and route it to local interface). So each incomming packet must be checked against list of all opened transparent sockets. Using conntrack may help reduce overhead MAy be like this. iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark // coppy connection mark to packet iptables -t mangle -A PREROUTING -m mark --mark 0x1/0xffffffff -j ACCEPT // Already marked packets accept, unmarked to future processing.. iptables -t mangle -A PREROUTING -m state --state NEW -j DIVERT // only NEW connections to divert iptables -t mangle -A DIVERT -p tcpo -m socket -j MARK --set-xmark 0x1/0xffffffff iptables -t mangle -A DIVERT -j CONNMARK ---save-mark // save mark on connection for with we have transparent socket iptables -t mangle -A DIVERT -j ACCEPT In this, new connections are checked against -m socket and marked, mark is saved to whole connection and future packets for that connection are marked directly by CONNTRACK so matching a whole traffic against list of open transparent sockets is not needed... So in busy boxes, high TCP load and a lot of opened transparent sockets it MAY save lot of cpu cycles. Or I am miss a point somewhere ? NTPT
------------ Původní zpráva ------------ Od: KOVACS Krisztian <hidden@sch.bme.hu> Předmět: Re: [tproxy] Merging tproxy patch to standard kernel ? Datum: 23.7.2008 14:40:18 ---------------------------------------- Hi,
On h, júl 21, 2008 at 04:49:43 +0200, NTPT wrote:
Redirecting ICMP related traffic - I am not an kernel / netfilter hacker, but what to extend netfilter CONNMARK for that purpose ?
Addition of --restore-mark-related option to CONNMARK target , witch copy connmark from master connection to related traffic probably will do this job.
so then it could look like this ?
iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcpo -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-xmark 0x1/0xffffffff iptables -t mangle -j CONNMARK ---save-mark // save mark on connection iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -p icmp -j CONNMARK --restore-mark-related // copy connmark from master conenction to its related stuff
// now related ICMP traffic is marked too and can be directed by routing code
Yes, you're right but this requires connection tracking -- while we would like to be able to use tproxy without conntrack.
But I like the idea... ;)
-- KOVACS Krisztian _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
Hello KOVACS Krisztia-san Thank you very much for your kindly information ! Well, I would like to know what is the ICMP issue. Is the ICMP issue affect when tproxy is used for TCP to keep source IP addresses for transparent HTTP(or other TCP) proxy, or not ? If not, I think the issue is not serious from my point of view... And, is the issue happen only on tproxy4.1, or happens both on tproxy2 and tproxy4 ? Thank you ! -- 日本エフ・セキュア株式会社 (Nihon F-Secure Corporation) 吉岡 恒夫(Yoshioka Tsuneo) E-MAIL: Tsuneo.Yoshioka@f-secure.com TEL: 045-440-6612 / FAX: 045-440-6616
Hi,
On p, júl 18, 2008 at 11:15:38 +0900, Yoshioka Tsuneo wrote:
It is often required to keeping source address on proxy, and tproxy seems be almost only one solution. Now, it seems be very nice if tproxy patch is merged to standard kernel.
Is there any plan to merge tproxy to standard kernel ?
Well, that's always been the plan. However, we're still not in a position to ask for merging -- there are still serious issues with the current patch (handling of related ICMP traffic).
We hope to be able to address this issues but progress has been very-very slow recently...
-- KOVACS Krisztian _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
participants (3)
-
KOVACS Krisztian
-
NTPT
-
Yoshioka Tsuneo