This tool allows you to redirect any TCP connection to SOCKS or HTTPS proxy using your firewall, so redirection is system-wide.
Why is that useful? I can suggest following reasons:
Linux/iptables, OpenBSD/pf and FreeBSD/ipfw are supported. Linux/iptables is well-tested, other implementations may have bugs, your bugreports are welcome.
Transocks is alike project but it has noticable performance penality.
Transsocks_ev is alike project too, but it has no HTTPS-proxy support and does not support authentication.
Several Andoird apps also use redsocks under-the-hood: ProxyDroid (@AndroidMarket) and sshtunnel (@AndroidMarket). And that's over 100'000 downloads! Wow!
Another related issue is DNS over TCP. Redsocks includes `dnstc' that is fake and really dumb DNS server that returns "truncated answer" to every query via UDP. RFC-compliant resolver should repeat same query via TCP in this case - so the request can be redirected using usual redsocks facilities.
Known compliant resolvers are:
Known non-compliant resolvers are:
On the other hand, DNS via TCP using bind9 may be painfully slow. If your bind9 setup is really slow, you have at least two options: pdnsd caching server can run in TCP-only mode, ttdnsd (git repo) has no cache but can be useful for same purpose.
Redirect any TCP connection to SOCKS4, SOCKS5 or HTTPS (HTTP/CONNECT) proxy server.
Login/password authentication is supported for SOCKS5/HTTPS connections. SOCKS4 supports only username, password is ignored. for HTTPS, currently only Basic and Digest scheme is supported.
Redirect UDP packets via SOCKS5 proxy server. NB: UDP still goes via UDP, so you can't relay UDP via OpenSSH.
Sends "truncated reply" as an answer to UDP DNS queries.
Redirect any HTTP connection to proxy that does not support transparent proxying (e.g. old SQUID had broken `acl myport' for such connections).
All source code is licensed under Apache 2.0 license.
You can get a copy at http://www.apache.org/licenses/LICENSE-2.0.html
libevent-2.0.x is required.
gcc is only supported compiler right now, other compilers can be used but may require some code changes.
Compilation is as easy as running `make', there is no `./configure' magic.
GNU Make works, other implementations of make were not tested.
Program has following command-line options:
-c sets proper path to config file ("./redsocks.conf" is default one)
-t tests config file syntax
-p set a file to write the getpid() into
Following signals are understood:
SIGUSR1 dumps list of connected clients to log
SIGTERM and SIGINT terminates daemon, all active connections are closed
You can see configuration file example in redsocks.conf.example
You have to build iptables with connection tracking and REDIRECT target.
# Create new chain root#
iptables -t nat -N REDSOCKS# Ignore LANs and some other reserved addresses. # See Wikipedia and RFC5735 for full list of reserved networks. root#
iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 22.214.171.124/4 -j RETURNroot#
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN# Anything else should be redirected to port 12345 root#
iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345# Any tcp connection made by `luser' should be redirected. root#
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner luser -j REDSOCKS# You can also control that in more precise way using `gid-owner` from # iptables. root#
usermod --append --groups socksified luserroot#
iptables -t nat -A OUTPUT -p tcp -m owner --gid-owner socksified -j REDSOCKS# Now you can launch your specific application with GID `socksified` and it # will be... socksified. See following commands (numbers may vary). # Note: you may have to relogin to apply `usermod` changes. luser$
iduid=1000(luser) gid=1000(luser) groups=1000(luser),1001(socksified) luser$
sg socksified -c iduid=1000(luser) gid=1001(socksified) groups=1000(luser),1001(socksified) luser$
sg socksified -c "firefox"# If you want to configure socksifying router, you should look at # doc/iptables-packet-flow.png and doc/iptables-packet-flow-ng.png and # wikipedia/File:Netfilter-packet-flow.svg # Note, you should have proper `local_ip' value to get external packets with # redsocks, default 127.0.0.1 will not go. See iptables(8) manpage regarding # REDIRECT target for details. # Depending on your network configuration iptables conf. may be as easy as: root#
iptables -t nat -A PREROUTING --in-interface eth_int -p tcp -j REDSOCKS
Keep in mind, that changed GID affects filesystem permissions, so if your application creates some files, the files will be created with luser:socksified owner/group. So, if you're not the only user in the group `socksified` and your umask allows to create group-readable files and your directory permissions, and so on, blah-blah, etc. THEN you may expose your files to another user.
Ok, you have been warned.
Mailing list: email@example.com
Mailing list also has archives.
(~~~~~~~~~~\ __ | jabber: ) / \ | mailto: ( /|oo \ \_________\(_| /_) _ @/_ \ | | \ \\ leon | (*) | \ )) darkk.net.ru |__U__| / \// _//|| _\ / (_/(_|(____/ Valid CSS! Valid XHTML 1.0 Transitional