Total Pageviews

Saturday, 14 November 2015

一些创建tunnels的脚本

tunnels

scripts for create proxies and tunnels
Useful links:

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.
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.
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 !
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.

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)?
# << 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 eth0
Without 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.
UPDATEfdisk 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 image
You 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 offset
Next 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=1b
Now 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.o
Run sfdisk directly on VDI fixed-size image with LD_PRELOAD equal to ./vdiwrap.so:
$ LD_PRELOAD="./vdiwrap.so" /sbin/sfdisk -qluS image.vdi
Look 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> * 512
In 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 option
In my case I ended with:
$ sudo mount image.vdi /mnt/vd -t ext3 -o loop,offset=65536,ro
Maybe I should write some script for automating this? 8-)

Mounting partition from VMDK image

WARNING: FUSE and libfuse are required.
  1. 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.
  2. 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
  3. List available partitions:
    $DIRECTORY/vmware-mount -p PATH_TO_YOUR/image.vmdk
  4. Mount chosen partition:
    $DIRECTORY/vmware-mount PATH_TO_YOUR/image.vmdk PARTITION_NUMBER MOUNT_POINT

Making SOCKS proxy transparent

UPDATEtransocks_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).
  1. 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 (usually libevent-dev).
  2. Download redsocks (http://darkk.net.ru/redsocks/ - either use git to clone repository, get latest snapshot or get locally archived revision from 2009.05.21: redsocks-a37aa7a.tar.gz) and build it using make.
  3. Configure redsocks by editing redsocks.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;
    }
  4. 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.
  5. Now all hosts with your machine set as a gateway use SOCKS proxy accordingly to iptables rules. Transparently! 
  6. Open another beer bottle and enjoy. 8-)

Preparing Ubuntu 9.10 for CUDA 2.3

  1. 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
    
  2. 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
    
  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/