Open johnwigley opened 5 years ago
yes. tproxy also works for tcp.
johnwigley notifications@github.com 于 2019年11月4日周一 18:53写道:
Hi,
The IPtables configuration for proxying TCP traffic in Redsocks2 suggest using REDIRECT, and then to use TPROXY for UDP traffic.
Is it possible to use TPROXY also for TCP traffic and NOT REDIRECT?
The reason I ask is that I need to DNAT the traffic before it is directed to Redsocks2, and because DNAT and REDIRECT are terminating statements in IPtables, it is not possible to combine a DNAT and a REDIRECT, whereas Tproxy is handled in the Mangle table and so will support DNAT and then TPROXY.
Thanks
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/semigodking/redsocks/issues/133?email_source=notifications&email_token=AAP2XD5JSWPVBAGSLJGXFZTQR75JLA5CNFSM4JIRZQSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HWR57RA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP2XD4L67LCBOZGB32G3C3QR75JLANCNFSM4JIRZQSA .
Thanks for answering, that's great news.
Can I ask two follow up questions: 1) Can you then use REDIRECT and TPROXY also for UDP? So both TCP and UDP can use either REDIRECT or TPROXY, or is it just TCP that can use both?
2) Why is it that Redsocks2 recommends using REDIRECT for TCP, and TPROXY for UDP, I've noticed that it seems all of the transparent socks proxies including Redsocks, Shadowsocks (ss-redir), and V2ray all specify REDIRECT for TCP, but TPROXY for UDP? I asked the same question on IRC #NetFilter, and no one seemed to know why this convention, rather than both use REDIRECT or both use TPROXY. It would be good to know why this recommendation is always made.
Thanks very much, appreciate all the work you've put in on Redsocks2.
for 1, if you use redirect for udp, you lost true destination address. That is why redudp allows you specify a destinaion adress. for 2, i think the reasons are: a) redirect requires less configuations. b) many routers have REDIRECT kmod built in but not tproxy.
johnwigley notifications@github.com 于 2019年11月4日周一 23:55写道:
Thanks for answering, that's great news.
Can I ask two follow up questions:
1.
Can you then use REDIRECT and TPROXY also for UDP? So both TCP and UDP can use either REDIRECT or TPROXY, or is it just TCP that can use both? 2.
Why is it that Redsocks2 recommends using REDIRECT for TCP, and TPROXY for UDP, I've noticed that it seems all of the transparent socks proxies including Redsocks, Shadowsocks (ss-redir), and V2ray all specify REDIRECT for TCP, but TPROXY for UDP? I asked the same question on IRC #NetFilter, and no one seemed to know why this convention, rather than both use REDIRECT or both use TPROXY. It would be good to know why this recommendation is always made.
Thanks very much, appreciate all the work you've put in on Redsocks2.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/semigodking/redsocks/issues/133?email_source=notifications&email_token=AAP2XD7ED3S7ZSOZVX77AELQSBAX7A5CNFSM4JIRZQSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC7XOII#issuecomment-549418785, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP2XDY7YOAQBBQWUST5F63QSBAX7ANCNFSM4JIRZQSA .
Thanks, I can confirm that TPROXY works fine for TCP traffic as you suggested.
I have now tried an IPtables DNAT before the TPROXY, and Redsocks2 is still pulling out the original before DNAT destination address, so I am presuming that that is because in the code flow, firstly a check is made to see if an original destination address is available via SO_ORIGINAL_DST, and then if NOT, then the current destination address is used.
So, what I would like to do is an experiment to disable Redsocks2 from using the SO_ORIGINAL_DST to see if that fixes the issue.
However, I can't actually find where in the code it is looking for the original destination address in TCP mode - could you please let me know where in the code this logic is, so that I can try disabling it?
Thanks
Also, I saw you commented here: https://github.com/semigodking/redsocks/issues/20#issuecomment-140291864
That TPROXY only works in the PREROUTING chain, and the Tproxy docs also suggest the same thing, however, I have just tested TPROXY in the OUTPUT chain on Debian 10 (Kernel 4.19), and it definitely works fine for TCP traffic in the OUTPUT chain now. Maybe it still doesn't work for UDP, haven't tested that yet.
yes. it works for me on my router with linux kernel 3.10.
johnwigley notifications@github.com 于 2019年11月5日周二 22:16写道:
Also, I saw you commented here: #20 (comment) https://github.com/semigodking/redsocks/issues/20#issuecomment-140291864
That TPROXY only works in the PREROUTING chain, and the Tproxy docs also suggest the same thing, however, I have just tested TPROXY in the OUTPUT chain on Debian 10 (Kernel 4.19), and it definitely works fine for TCP traffic in the OUTPUT chain now. Maybe it still doesn't work for UDP, haven't tested that yet.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/semigodking/redsocks/issues/133?email_source=notifications&email_token=AAP2XDZXOIXIHLEALRZOI3TQSF55HA5CNFSM4JIRZQSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDC4AUI#issuecomment-549830737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP2XD2LNDQSTUFHGPD537DQSF55HANCNFSM4JIRZQSA .
that is in base.c line 240
johnwigley notifications@github.com 于 2019年11月5日周二 22:04写道:
Thanks, I can confirm that TPROXY works fine for TCP traffic as you suggested.
I have now tried an IPtables DNAT before the TPROXY, and Redsocks2 is still pulling out the original before DNAT destination address, so I am presuming that that is because in the code flow, firstly a check is made to see if an original destination address is available via SO_ORIGINAL_DST, and then if NOT, then the current destination address is used.
So, what I would like to do is an experiment to disable Redsocks2 from using the SO_ORIGINAL_DST to see if that fixes the issue.
However, I can't actually find where in the code it is looking for the original destination address in TCP mode - could you please let me know where in the code this logic is, so that I can try disabling it?
Thanks
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/semigodking/redsocks/issues/133?email_source=notifications&email_token=AAP2XD7JAXCB42XVSB2DF33QSF4OXA5CNFSM4JIRZQSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDC3IHQ#issuecomment-549827614, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP2XD3NJB5KEQRZ23DAQ53QSF4OXANCNFSM4JIRZQSA .
Ok, so reviewing the code in base.c around line 240 shows that the REDIRECT specific extraction of the destination address using so_orig_dst ONLY occurs if the config option is set: redirector=iptables
If you change to: redirector=generic
Then this works perfectly with TPROXY to allow other IPtables transforms such as DNAT and SNAT to occur before Redsocks picks up the IP address.
For these very specific configurations where you want to use IPtables NAT transforms in conjunction with Redsocks, maybe should be a FAQ or README item to suggest using TPROXY and redirector=generic.
@semigodking - Thank you very much, really appreciate you taking the time to look into this.
Hi,
The IPtables configuration for proxying TCP traffic in Redsocks2 suggest using REDIRECT, and then to use TPROXY for UDP traffic.
Is it possible to use TPROXY also for TCP traffic and NOT REDIRECT?
The reason I ask is that I need to DNAT the traffic before it is directed to Redsocks2, and because DNAT and REDIRECT are terminating statements in IPtables, it is not possible to combine a DNAT and a REDIRECT, whereas Tproxy is handled in the Mangle table and so will support DNAT and then TPROXY.
Thanks