tunnels
scripts for create proxies and tunnels
Useful links:
- https://airvpn.org/topic/9906-bind-all-outgoing-traffic-via-iptables-but-still-allow-ssh-access/
- http://ubuntuforums.org/archive/index.php/t-2136902.html
- https://wiki.archlinux.org/index.php/VPN_over_SSH
- http://habrahabr.ru/post/87197/
- http://pastebin.com/aY8tgajy
- http://pastebin.com/rq7A9291
- http://linuxaria.com/article/redirect-all-tcp-traffic-through-transparent-socks5-proxy-in-linux
- http://openvz.org/VPN_via_the_TUN/TAP_device
- http://przemoc.net/tips/linux#making_socks_proxy_transparent
from https://github.com/Friz-zy/tunnels
------------------------
------------------------
Redirect all (TCP) traffic through transparent socks5 proxy in Linux
SOCKet Secure (SOCKS) is an Internet protocol that routes network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server will proxy TCP connections to an arbitrary IP address as well as providing a means for UDP packets to be forwarded.
As SOCKS (as it was already marked above) transfers all data from a client to a server, nothing adding from itself, from the point of view of a web-server, a socks proxy is a client. Therefore anonymity of this type of proxy servers is really always absolute.
In this article we’ll see how to use redsocks to achieve a SOCKS proxy.
Redsocks allows you to redirect any TCP connection to SOCKS or HTTPS proxy using your firewall, so redirection is system-wide.
Redsocks allows you to redirect any TCP connection to SOCKS or HTTPS proxy using your firewall, so redirection is system-wide.
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.
UDP. RFC-compliant resolver should repeat same query via TCP in this case – so the request can be redirected using usual redsocks facilities.
Why is that useful? these are some examples of use:
- you use tor and don’t want any TCP connection to leak
- you use DVB ISP and this ISP provides internet connectivity with some special daemon that may be also called “Internet accelerator” and this accelerator acts as proxy. Globax is example of such an accelerator
Linux/iptables, OpenBSD/pf and FreeBSD/ipfw are supported. Linux/iptables is well-tested, other implementations may have bugs.
Installation e basic configuration
For Debian/Ubuntu open a terminal and run:
sudo apt-get install iptables git-core libevent libevent-dev git clone http://github.com/darkk/redsocks.git cd redsocks/ make echo 'base{log_debug = on; log_info = on; log = "file:/tmp/reddi.log"; daemon = on; redirector = iptables;} redsocks { local_ip = 127.0.0.1; local_port = 31338; ip = 127.0.0.1; port = 31337; type = socks5; }' > redsocks.conf ./redsocks -c redsocks.conf |
For Redhat/Centos/Fedora open a terminal and run :
yum install iptables libevent libevent-dev wget -O redsocks --no-check-certificate https://github.com/darkk/redsocks/zipball/master unzip redsocks cd /usr/local/redsocks/darkk-redsocks-8839230 #the number could change in the future. make echo 'base{log_debug = on; log_info = on; log = "file:/tmp/reddi.log"; daemon = on; redirector = iptables;} redsocks { local_ip = 127.0.0.1; local_port = 31338; ip = 127.0.0.1; port = 31337; type = socks5; }' > redsocks.conf ./redsocks -c redsocks.conf |
This basic configuration set a socks5 proxy on localhost port 31337.
Iptables configuration
Now we need to configure our local firewall with the following rules, I suggest to put them in a file and then run it.
#!/bin/bash # Create new chain iptables -t nat -N REDSOCKS # Ignore LANs and some other reserved addresses. iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN # Anything else should be redirected to port 31338 iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 31338 # Any tcp connection made by `linuxaria' should be redirected, put your username here. iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner linuxaria -j REDSOCKS |
Start and Stop of redsocks
To start redsocks and iptables
/path/tothe/bin/redsocks -c redsocks.conf /path/tothe/bin/iptables-redsocks.sh |
To stop redsocks and iptables:
sudo iptables -F sudo iptables -X sudo iptables -Z sudo iptables -t nat -F sudo iptables -t nat -X sudo iptables -t nat -Z killall redsocks |
Conclusions
Now – all outbound traffic will be transparently mapped through redsocks to our socks5 proxy.
And thanks to iptables there is no need to adjust any application configurations !
And thanks to iptables there is no need to adjust any application configurations !
from http://linuxaria.com/article/redirect-all-tcp-traffic-through-transparent-socks5-proxy-in-linux
------------------------------------------------------
making_socks_proxy_transparent
Page extracted from (now defunct) Przemoc's wiki: http://wiki.przemoc.net/tips/linux.
Apparently it's still useful for some of you. :-)
Return to Przemoc's network.
Apparently it's still useful for some of you. :-)
Return to Przemoc's network.
Problems
NetBeans 6 - empty window in installer
Turn of Compiz/Beryl and restart installer.
Debian/Ubuntu and VirtualBox with host interface networking and bridging
Have you followed instructions and now you have network problems with host (but not with guest)?
UPDATE: Above information is suitable only for VirtualBox < 2.1
# << start of lacking part auto eth0 iface eth0 inet manual up ifconfig $IFACE 0.0.0.0 up down ifconfig $IFACE down # >> end of lacking part auto br0 iface br0 inet dhcp bridge_ports eth0Without lacking part
eth0
interface conflicts with br0
, because they have the same address.UPDATE: Above information is suitable only for VirtualBox < 2.1
Tasks
GRUB reinstallation
mount /dev/sdXY /mnt/sys mount -t proc none /mnt/sys/proc # or --bind mount -o bind /dev /mnt/sys/dev # or --bind chroot /mnt/sys #mount /dev/sdXZ /boot # if needed grub-install /dev/sdX
Setting processor affinity
taskset -p 0x00000001 13545 taskset -cp 1 13545 taskset -cp 3,4 13545
Mounting partition from VDI fixed-size image
WARNING: You must have little-endian machine and this how-to works only with primary partitions.
UPDATE:
UPDATE2: I divided this how-to into sections and wrote about usage of my new
UPDATE:
fdisk
was permanently replaced with more reliable sfdisk
.UPDATE2: I divided this how-to into sections and wrote about usage of my new
vdiwrap
shared library.Locate partition - manual way
First test if your VDI image is fixed-size.
$ od -j76 -N4 -td4 image.vdi | awk 'NR==1{print $2;}' # read 4-byte unsigned int from offset 76 2 # "2" means that this is a fixed-size imageYou must find out where virtual disk exactly starts.
$ od -j344 -N4 -td4 image.vdi | awk 'NR==1{print $2;}' # read 4-byte unsigned int from offset 344 33280 # your data offsetNext step is copying beginning of the virtual disk to some file. I named it
vdstart
$ dd if=image.vdi of=vdstart bs=1 skip=<data offset> count=1bNow look at partition table.
$ /sbin/sfdisk -luS vdstart # list partition table (units = sectors) Disk vdstart: cannot get geometry Disk vdstart: 0 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System vdstart1 * 63 16771859 16771797 83 Linux vdstart2 0 - 0 0 Empty vdstart3 0 - 0 0 Empty vdstart4 0 - 0 0 Empty
Locate partition - half-automatic way
If you want to mount logical partition you have to use this method. Create new file
vdiwrap.c
with code available in my gist: 571086. Compile it accordingly to instructions, i.e.$ gcc -fPIC -c -o vdiwrap.o vdiwrap.c && gcc -nostdlib -shared -ldl -o vdiwrap.so vdiwrap.oRun
sfdisk
directly on VDI fixed-size image with LD_PRELOAD equal to ./vdiwrap.so
:$ LD_PRELOAD="./vdiwrap.so" /sbin/sfdisk -qluS image.vdiLook at the printed partition table. In output you will find VDI data offset needed in the next step.
Math
Time for some math. Calculate offset (and length if you plan to mount encrypted partition) of chosen partition:
offset = <data offset> + <start sector> * 512 length = <number of sectors> * 512In my image there is only one partition, so I have no choice:
offset
= 65536, length
= 8587160064.Mounting
Last part is mounting (turn off VM which uses your VDI image) and you must be superuser to do this (I'm using
sudo
, but if you haven't configured it, try su -c
):$ sudo mount image.vdi <mount point> -t <filesystem> -o loop,offset=<offset> # add sizelimit=<length> # if partition is encrypted; your losetup must support this optionIn my case I ended with:
$ sudo mount image.vdi /mnt/vd -t ext3 -o loop,offset=65536,roMaybe I should write some script for automating this? 8-)
Mounting partition from VMDK image
WARNING: FUSE and
libfuse
are required.- Download VMware Server 2 suitable for your machine (
uname -m
), e.g. VMware-server-2.0.2-203138.x86_64.tar.gz in my case. - Extract 3 files to some directory. It will be
/opt/vmware-mount
in this example.
DIRECTORY=/opt/vmware-mount mkdir -p $DIRECTORY && cd $DIRECTORY echo " vmware-server-distrib/lib/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8 vmware-server-distrib/lib/lib/libssl.so.0.9.8/libssl.so.0.9.8 vmware-server-distrib/bin/vmware-mount " | tar -xT /dev/stdin --strip 2 -f PATH_TO_DOWNLOADED/VMware-server-2.0.2-203138.i386.tar.gz mv lib/*/* . rm -r lib
- List available partitions:
$DIRECTORY/vmware-mount -p PATH_TO_YOUR/image.vmdk
- Mount chosen partition:
$DIRECTORY/vmware-mount PATH_TO_YOUR/image.vmdk PARTITION_NUMBER MOUNT_POINT
Making SOCKS proxy transparent
UPDATE:
If we have a limited connectivity to the world from current location, but still can connect to a shell account fully open to the world (or open to the other non-public network), than dynamic port forwarding available in
I'm assuming that you already have SOCKS server bound to localhost on standard port 1080 (e.g. you started
transocks_ev
is unstable, therefore using a lot better redsocks
is safer choice. Sorry for this late update.If we have a limited connectivity to the world from current location, but still can connect to a shell account fully open to the world (or open to the other non-public network), than dynamic port forwarding available in
ssh
can save us. This feature (accessible by -D
option) in fact makes ssh acting as SOCKS server. OK, but what can we do if our application doesn't support SOCKS proxy? It's important question, because vast majority of software is unaware of such protocol. In Linux we have a great tsocks
(http://tsocks.sourceforge.net/), shell wrapper which transparently allows an application to use SOCKS proxy. In Windows there are FreeCap
(http://www.freecap.ru/eng/) and Vilongu HTTP SOCKS Tunneler
http://www.connectionresume.com/vilongu/ - they do the same thing, but in a different way. Nice, but what if we have dozens of machines to set up. Teaching all users how to use any of mentioned application can be also really inconvenient. Making SOCKS proxy transparent will solve (almost?) all our problems. Is it feasible? YES, but you must have an access to superuser account on a gateway server (it can be also any other server, but gateway is used here for simplicity).I'm assuming that you already have SOCKS server bound to localhost on standard port 1080 (e.g. you started
ssh
with -D1080
).- Install
libevent
(http://www.monkey.org/~provos/libevent/). It can be already available in your distribution repository. This will be used for compiling in next step, so you must get development package (usuallylibevent-dev
). - Download
redsocks
(http://darkk.net.ru/redsocks/ - either usegit
to clone repository, get latest snapshot or get locally archived revision from 2009.05.21: redsocks-a37aa7a.tar.gz) and build it usingmake
. - Configure
redsocks
by editingredsocks.conf
. I assume that it contains:
base { log_debug = on; log_info = on; log = "file:/home/users/przemoc/redsocks/redsocks.log"; daemon = on; redirector = iptables; } redsocks { local_ip = 0.0.0.0; local_port = 12345; ip = 192.168.0.1; port = 1080; type = socks5; }
- Configure, tune and run below script first time as root with one argument
iptables
and later as normal user.
#!/bin/sh # Where to find iptables IPTABLES="/usr/sbin/iptables" # Where to find redsocks REDSOCKS_DIR="/home/users/przemoc/redsocks" REDSOCKS="$REDSOCKS_DIR/redsocks" # Port that is redsocks listening on REDSOCKS_PORT="12345" # Location of our SOCKS-server SOCKS_HOST="192.168.0.1" SOCKS_PORT="1080" # Start redsocks if [ "$USER" != "root" ]; then echo -n 'Restarting redsocks... ' pkill -U $USER redsocks 2>/dev/null sleep 1 cd $REDSOCKS_DIR && $REDSOCKS if [ $? -eq 0 ]; then echo Done else echo Error fi exit 0; elif [ "$1" != "iptables" ]; then exit 0 fi $IPTABLES -t nat -D PREROUTING -p tcp -j REDSOCKS_FILTER 2>/dev/null $IPTABLES -t nat -D OUTPUT -p tcp -j REDSOCKS_FILTER 2>/dev/null $IPTABLES -t nat -F REDSOCKS_FILTER 2>/dev/null $IPTABLES -t nat -X REDSOCKS_FILTER 2>/dev/null $IPTABLES -t nat -F REDSOCKS 2>/dev/null $IPTABLES -t nat -X REDSOCKS 2>/dev/null # Create our own chain $IPTABLES -t nat -N REDSOCKS $IPTABLES -t nat -N REDSOCKS_FILTER # Do not try to redirect local traffic $IPTABLES -t nat -I REDSOCKS_FILTER -o lo -j RETURN ### Below whitelist and blacklist cannot operate together. ### If you want to change it, refactor the code. It's simple. # Redirect only specified addresses and do not try redirect other traffic. (whitelist option) $IPTABLES -t nat -A REDSOCKS_FILTER -m iprange --dst-range 192.168.0.10-192.168.0.30 -j REDSOCKS $IPTABLES -t nat -A REDSOCKS_FILTER -d 126.0.0.0/8 -j REDSOCKS $IPTABLES -t nat -A REDSOCKS_FILTER -j RETURN ## Do not redirect LAN traffic and some other reserved addresses. (blacklist option) #$IPTABLES -t nat -A REDSOCKS_FILTER -d 0.0.0.0/8 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 10.0.0.0/8 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 127.0.0.0/8 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 169.254.0.0/16 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 172.16.0.0/12 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 192.168.0.0/16 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 224.0.0.0/4 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -d 240.0.0.0/4 -j RETURN #$IPTABLES -t nat -A REDSOCKS_FILTER -j REDSOCKS ## Do not redirect traffic for the SOCKS-Server ## Not needed if server is not on a whitelist or is already blacklisted. #$IPTABLES -t nat -I REDSOCKS -p tcp -d $SOCKS_HOST --dport $SOCKS_PORT -j RETURN # Redirect all traffic that gets to the end of our chain $IPTABLES -t nat -A REDSOCKS -p tcp -j REDIRECT --to-port $REDSOCKS_PORT ## Filter all traffic from the own host ## BE CAREFULL HERE IF THE SOCKS-SERVER RUNS ON THIS MACHINE $IPTABLES -t nat -A OUTPUT -p tcp -j REDSOCKS_FILTER # Filter all traffic that is routed over this host $IPTABLES -t nat -A PREROUTING -p tcp -j REDSOCKS_FILTER echo IPtables reconfigured.
- Now all hosts with your machine set as a gateway use SOCKS proxy accordingly to
iptables
rules. Transparently! - Open another beer bottle and enjoy. 8-)
Preparing Ubuntu 9.10 for CUDA 2.3
- nVidia 190 drivers
sudo add-apt-repository ppa:nvidia-vdpau/ppa sudo apt-get update sudo apt-get install nvidia-190-modaliases nvidia-glx-190 nvidia-settings-190
- GNU Compiler Collection 4.3
sudo apt-get install gcc-4.3 g++-4.3 sudo update-alternatives --remove-all gcc sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.3 43 --slave /usr/bin/g++ g++ /usr/bin/g++-4.3 --slave /usr/bin/gcov gcov /usr/bin/gcov-4.3 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.4 44 --slave /usr/bin/g++ g++ /usr/bin/g++-4.4 --slave /usr/bin/gcov gcov /usr/bin/gcov-4.4 sudo update-alternatives --config gcc # choose gcc 4.3
- CUDA SDK requirements
sudo apt-get install libglut-dev libxi-dev libxmu-dev
from http://przemoc.net/tips/linux#making_socks_proxy_transparent
----------------
SSH VPN over Internet
There was a need to organize a tunnel between your work computer and a home server, and then transport the entire working of traffic through the home server to the Internet. To solve this problem, it is best suited technology Vitual Private Network (VPN). But using this technology which realize? - I chose SSH. The fact is that since OpenSSH version 4.3, supports tun tunneling. This I took ... Schematically it will look as follows: First we need to install OpenSSH on the server. I have Ubuntu Server, and I do it like this: sudo aptitude install openssh-server Though, most likely, it is already installed. I - just set;) Let's look at a more detailed diagram and discuss it. As can be seen from the figure, the working computer has IP 172.16.0.1 mask 255.255.255.0 and the gateway default 172.16.0.254, as well as a DNS Set IP 8.8.8.8 Computer Work: IP address: 172.16.0.1 Netmask: 255.255.255.0 Default Gateway: 172.16.0.254 DNS: 8.8.8.8 The routing table of the client (Work): 172.16.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 172.16.0.254 0.0.0.0 UG 0 0 0 eth0 169.254.0.0 - it zeroconf route. For the organization of the tunnel in the configuration file you want to allow OpenSSH tunneling. The / etc / ssh / sshd_config you need to add a line PermitTunnel point-to-point and restart the OpenSSH server service ssh restart Nuances: The fact is that in order for something to organize the tunnel, you should log in to the server under the account root, which is not good! Therefore, there are two options to solve the problem: 1. Put a password to root complex type md5 hash. 2. Set up the authorization of keys. Which method you choose - you decide. For example, described by me, it does not matter. If you want to use password authentication, are allowed in config PermitRootLogin yes to that, you could log in under the root. Connecting to the server and the establishment of the tunnel is done with the command sudo ssh root@74.125.87.104 -w 0: 0 Be sure to do with sudo or root-a. Tun devices will be created, which requires privileges. -w Switch will tun0 device on the server and the client, combining them together. Here is a description of the man-a. -w local_tun [: remote_tun] <b> Requests tunnel device </ b> forwarding with the specified <b> tun </ b> (4) devices <b> between the client </ b> (local_tun) <b> and the server </ b> (remote_tun) <br /> Setting tun devices. On the server ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2 On the client, ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1 You can test using ping (a client computer): user @ host: ~ $ ping 10.0.0.1 -c 2 PING 10.0.0.1 (10.0.0.1) 56 (84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq = 1 ttl = 64 time = 5.80 ms 64 bytes from 10.0.0.1: icmp_seq = 2 ttl = 64 time = 8.61 ms --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min / avg / max / mdev = 5.800 / 7.209 / 8.618 / 1.409 ms Now it is necessary to let all traffic through tun0, it takes just tun0 specify the default gateway, but lost contact with a server (Home Server) and DNS server. Therefore, before you delete the current default gateway (172.16.0.254), be sure to add routes to the server and DNS server in the routing table. What can be done as follows: <br /> route add -host 74.125.87.104 gw 172.16.0.254 <br /> route add -host 8.8.8.8 gw 172.16.0.254 <br /> Then remove the current default gateway (172.16.0.254) and specify a gateway IP address that we have assigned to the tun0 interface server (10.0.0.1) <br /> route del default <br /> route add default gw 10.0.0.1 <br /> After completing the above steps the client routing table (Work) takes the following form: 74.125.87.104 172.16.0.254 255.255.255.255 UGH 0 0 0 eth0 8.8.8.8 172.16.0.254 255.255.255.255 UGH 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 172.16.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 tun0 Now all traffic that goes to the unknown subnet, and all unknown except addresses 8.8.8.8 and 74.125.87.104, routed through 10.0.0.1, ie over an encrypted SSH tunnel. But the server is nothing to him, traffic does not. Because you need to set up NAT for the client. To do this, add a rule to iptables <br /> iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE <br /> Includes the nucleus ip forward-ING <br /> sysctl -w net.ipv4.ip_forward = 1 <br /> Do not forget to make sure that he would have turned on at boot ... <br /> mcedit /etc/sysctl.conf PS> mcedit - text editor. You can use any other. We find the commented lines net.ipv4.ip_forward = 1 and uncomment it. Everything, mission complete, is now all traffic is routed via ssh tunnel and NATitsya the Internet. The tunnel encrypted traffic to the server is protected.
from https://habrahabr.ru/post/87197/