Socks5 UDP tunnel + SSL?
Hello all,
I have a shell box at a hosting provider with a dedicated IP address and root access. I wanted to setup a Socks5 proxy + SSL so that I can use it for secure tunneling of traffic to the Internet via the box when on, say, public Wifi etc. I configured Dante on the server and setup Stunnel to allow me to connect to it, and everything works properly - the connection works and is SSL encrypted. Now what I'm wondering is if there's any way to add UDP support to this picture. I have a few apps that can use Socks5 to proxy UDP connections. In most cases, I cannot set a different IP/port for the UDP packets. This means that since I'm Stunneling and thus connecting to localhost, I'd somehow need to have something listening on localhost on the UDP port that matches the stunner TCP port and forwards this UDP traffic somehow to the Dante server. So, is there any way short of doing a full-blown VPN that would allow me to tunnel UDP traffic to my Dante proxy? Obviously we would really like this to be over some form of encryption. (SSL is not necessarily mandatory but I don't know of any sort of "UDP Stunnel" solution.) Advice greatly appreciated! F |
My tun2socks program might be useful, though I'm not sure how well it would integrate with your existing setup.
In short, tun2socks runs on the client and implements a virtual network interface that forwards all outgoing TCP connections through a SOCKS5 server. This is used to force all apps to go through the proxy, behind their back, and you don't have to (and shouldn't) configure proxy servers in the apps. It has some support for UDP, which works by you starting a forwarder daemon (udpgw) on the server, and having tun2socks connect to this daemon through the SOCKS link (which is TCP). In this setup, when tun2socks receives a UDP packet from the OS, it sends it to the udpgw daemon on the server, which then directly sends the packet into the wild (without going through a proxy), and it also sends back any replies. |
This may actually do exactly what I need. I will probably need to do a bit of network restructuring but it should be workable.
Right now, I have Dante running in client mode on my Linux router, and in server mode on the remote shell. So, if I want to SOCKS-ify a connection, I point that application to use the SOCKS server at, say, 192.168.1.1:8999. To integrate this, I'm guessing I could run the BadVPN/OpenVPN suite on the Linux router, and it would then create another interface that I could either manually or via DHCP direct the clients I want SOCKS'ed to use it as its default gateway? Like, suppose I have 192.168.1.1 as the main router, but then I create 192.168.1.2. And any machine that uses 192.168.1.2 as its default gateway will get SOCKS'ed, but those that use 192.168.1.1 won't. Is this something I can do? Or will I need to end up setting up two separate physical LAN segments - one SOCKSed, one not. (Or maybe multihoming might work - assigning the internal LAN interface a second IP like 192.168.2.1 and then using that subnet for SOCKSed clients?) Thanks again, looks like I have some networking fun ahead of me. F |
Could you explain your setup in more detail? I don't know about how Dante works, and what "server mode" and "client mode" means.
As far as I get it, you have a SOCKS server running on the remote machine, but you use stunnel, so that all incoming SOCKS connections go through SSL. Then, on your Linux router, you have another SOCKS server running; this one accepts plain incoming connections, and just forwards them to the remote SOCKS server, wrapping the SOCKS connection in SSL. Is that right? In this scenario, you could start tun2socks on the Linux router, and point it to the local SOCKS server. You can control what goes into this tun2socks's socksifying interface via routing rules. I think that your idea with different gateways is great; however, it won't work straight away. The problem is that when you tell a client to use some default gateway, it will resolve the MAC address of the router, and the frames it sends will only be directed to this MAC address; the destination IP address will be the real destination. In other words, if you assign two different IP addresses to the router's local interface (say eth0) it has absolutely no idea which gateway IP address you were using. This means that if the router wants to know which gateway IP address you were using, each gateway IP would have to be located at a different MAC address. This is in fact possible with Linux. So, assume you already have one, the regular, local IP address, which will route directly. You have to create a new virtual interface for the second address, which will be bound to eth0, but will have a different MAC address: Code:
ip link add dev macvlan0 link eth0 type macvlan Now that the two gateway addresses have different MAC addresses, the router can use the destination MAC to figure out which gateway address they were sent to. We now use iptables to mark those incoming packets that came in via macvlan0; we will use these marks later in routing policies. Code:
iptables -t mangle -A PREROUTING -i macvlan0 -j MARK --set-mark 1 Code:
10 default_direct Code:
ip route add table default_direct 0.0.0.0/0 via <your_real_default_gateway_eg_ISP> Code:
ip rule add pref 40000 fwmark 1 lookup default_tun2socks Code:
# ip rule show As far as UDP is concerned, it should suffice to start the udpgw program on the remote server: Code:
badvpn-udpgw --listen-addr 127.0.0.1:7300 Code:
badvpn-tun2socks ... --udpgw-remote-server-addr 127.0.0.1:7300 |
All times are GMT -5. The time now is 01:26 PM. |