BadVPN – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | .TH badvpn-tun2socks 8 "February 2012" |
2 | .SH NAME |
||
3 | badvpn-tun2socks \- create a TUN device to route TCP traffic through a SOCKS server |
||
4 | .SH SYNOPSIS |
||
5 | .PP |
||
6 | .B |
||
7 | badvpn-tun2socks |
||
8 | .br |
||
9 | [\fB\-\-help\fR] |
||
10 | .br |
||
11 | [\fB\-\-version\fR] |
||
12 | .br |
||
13 | [\fB\-\-logger\fR <stdout/syslog>] |
||
14 | .br |
||
15 | [\fB\-\-syslog-facility\fR <string>] [\fB\-\-syslog-ident\fR <string>] |
||
16 | .br |
||
17 | [\fB\-\-loglevel\fR <0-5/none/error/warning/notice/info/debug>] |
||
18 | .br |
||
19 | [\fB\-\-channel-loglevel\fR <channel-name> <0-5/none/error/warning/notice/info/debug>] ... |
||
20 | .br |
||
21 | [\fB\-\-tundev\fR <name>] |
||
22 | .br |
||
23 | \fB\-\-netif\-ipaddr\fR <ipaddr> |
||
24 | .br |
||
25 | \fB\-\-netif\-netmask\fR <ipnetmask> |
||
26 | .br |
||
27 | \fB\-\-socks\-server\-addr\fR <addr> |
||
28 | .br |
||
29 | [\fB\-\-udpgw-remote-server-addr\fR <addr>] |
||
30 | .br |
||
31 | [\fB\-\-udpgw-max-connections\fR <number>] |
||
32 | .br |
||
33 | [\fB\-\-udpgw-connection-buffer-size\fR <number>] |
||
34 | .PP |
||
35 | Address format is a.b.c.d:port (IPv4) or [addr]:port (IPv6). |
||
36 | .SH DESCRIPTION |
||
37 | .PP |
||
38 | badvpn-tun2socks |
||
39 | is a network utility used to "socksify" TCP connections at the network |
||
40 | layer. It implements a TUN device which accepts all incoming TCP |
||
41 | connections (regardless of destination IP), and forwards them through |
||
42 | a SOCKS server. This allows you to forward all connections through |
||
43 | SOCKS, without any need for application support. It can be used, for |
||
44 | example, to forward connections through a remote SSH server. |
||
45 | .SH EXAMPLE |
||
46 | .PP |
||
47 | This example demonstrates using tun2socks in combination with SSH's dynamic forwarding feature. |
||
48 | |||
49 | Connect to the SSH server, passing -D localhost:1080 to the ssh |
||
50 | command to enable dynamic forwarding. This will make ssh open a local |
||
51 | SOCKS server which tun2socks forward connection through. |
||
52 | |||
53 | First create a TUN device (eg. using openvpn): |
||
54 | |||
55 | .nf |
||
56 | openvpn --mktun --dev tun0 --user <someuser> |
||
57 | .fi |
||
58 | |||
59 | Configure the IP of the new tun device: |
||
60 | |||
61 | .nf |
||
62 | ifconfig tun0 10.0.0.1 netmask 255.255.255.0 |
||
63 | .fi |
||
64 | |||
65 | Now start the badvpn-tun2socks program: |
||
66 | |||
67 | .nf |
||
68 | badvpn-tun2socks --tundev tun0 --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 \\ |
||
69 | --socks-server-addr 127.0.0.1:1080 |
||
70 | .fi |
||
71 | |||
72 | Note that the address 10.0.0.2 is not a typo. It specifies the IP address of the virtual |
||
73 | router inside the TUN device, and must be different from the IP of the |
||
74 | TUN interface itself (but in the same subnet). |
||
75 | |||
76 | Now you should be able to ping the virtual router's IP (10.0.0.2): |
||
77 | |||
78 | .nf |
||
79 | ping -n 10.0.0.2 |
||
80 | .fi |
||
81 | |||
82 | All that remains is to route connections through the TUN device |
||
83 | instead of the existing default gateway. This is done as follows: |
||
84 | |||
85 | 1. Add a route to the SSH server through your existing gateway, with a |
||
86 | lower metric than the original default route. |
||
87 | |||
88 | 2. If your DNS servers are in a network that is not direcly attached (e.g. in the Internet), |
||
89 | also add routes for them (like for the SSH server). This is |
||
90 | needed because tun2socks does not forward UDP by default (see below). |
||
91 | |||
92 | 3. Add a default route through the virtual router in the TUN device, |
||
93 | with a lower metric than the original default route, but higher than |
||
94 | the SSH and DNS routes. |
||
95 | |||
96 | This will make all external connections go through the TUN device, |
||
97 | except for the SSH connection (else SSH would go through the TUN |
||
98 | device, which would go through... SSH). |
||
99 | |||
100 | For example (assuming there are no existing default routes with metric |
||
101 | <=6; otherwise remove them or change their metrics): |
||
102 | |||
103 | .nf |
||
104 | route add <IP_of_SSH_server> gw <IP_of_original_gateway> metric 5 |
||
105 | <same for DNS> |
||
106 | route add default gw 10.0.0.2 metric 6 |
||
107 | .fi |
||
108 | .SH UDP FORWARDING |
||
109 | tun2socks can forward UDP, however this requires a forwarder daemon, badvpn-udpgw to run |
||
110 | on the remote SSH server: |
||
111 | |||
112 | .nf |
||
113 | badvpn-udpgw --listen-addr 127.0.0.1:7300 |
||
114 | .fi |
||
115 | |||
116 | Then tell tun2socks to forward UDP via the forwarder: |
||
117 | |||
118 | .nf |
||
119 | --udpgw-remote-server-addr 127.0.0.1:7300 |
||
120 | .fi |
||
121 | .SH COPYRIGHT |
||
122 | .PP |
||
123 | Copyright \(co 2010 Ambroz Bizjak <ambrop7@gmail.com> |
||
124 | .br |
||
125 | This is free software; see the source for copying conditions. There is NO |
||
126 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |