Expat-IT Tech Bits

Home

Contact

Links

Search this site:

Categories:

/ (287)
  Admin/ (122)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (6)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (30)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)

Archives:

  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    PyBlosxom

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Wed, 17 Feb 2016


    /Admin/VPN-options/Tinc: Simple Tinc VPN

    Tinc[1] is a rare animal, an actual peer-to-peer VPN that (for *NIX users) is easy to setup, not widely used and so (as far as I am aware) not blocked by anyone, including the GFW (Great Firewall of China).

    My main OS is Debian, so this example of a very simple tinc configuration will follow Debian standards in getting two Tinc VPN nodes talking to one another -- typically, one would be your Desktop, and the other would be a server with a public IP address running Squid.

    apt-get install tinc
    This is all that /etc/tinc contains after install:
    /etc/tinc/nets.boot

    Tinc can run multiple daemons, each handling a separate Tinc network on a separate subnet. To have each tinc network started automatically, simply add the network name to a list of same in nets.boot

    Each tinc network is represented by a separate directory under /etc/tinc/. Each Tinc network also requires a hosts subdirectory where the public keys for other peers in this network are held. For the simplest possible configuration, here are the main decisions to make:

    Let's first configure your desktop:

    Create the requisite directory structure:

    mkdir -p /etc/tinc/myvpn/hosts
    And create the two configuration files for this network:
    vi /etc/tinc/myvpn/tinc-up
    containing something like this
    modprobe tun
    ifconfig myvpn 10.99.3.1 netmask 255.255.0.0
    10.99.3.1 is the private tinc IP address of the node you are currently configuring. And
    vi /etc/tinc/myvpn/tinc.conf
    containing this:
    Name = mydesk
    Device = /dev/net/tun
    Port = 19001
    ConnectTo = myremote

    The Port line is optional, if omitted tinc will listen on the default port 655.

    Create your keys for the myvpn network (each separate tinc network/subnet has different keys) for the desktop node by running this on it:

    tincd -K -n myvpn
    (If things are correctly configured you should be able to just accept the defaults.) This is the pair of keys you just created:
    /etc/tinc/myvpn/rsa_key.priv
    /etc/tinc/myvpn/hosts/mydesk
    The former is your private key, the latter is your public key. Now edit the public key:
    vi /etc/tinc/myvpn/hosts/mydesk
    DO NOT modify the key, but add this config block ABOVE the key:
    Subnet = 10.9.3.1/32
    Address = x.x.x.x 19001

    The top line is the VPN private IP of the node, the bottom line is the real world (public, but not necessarily) IP and port where OTHER peers in this tinc network will find the machine. You will be sharing this file with all other peers in this network, and this config block tells them where to find this node.

    IMPORTANT, EASILY OVERLOOKED STEP: fix permissions:

    chown -R root: /etc/tinc/
    chmod a+rx /etc/tinc/myvpn/tinc-*
    tinc-* are scripts that must be executable, otherwise your configuration will subtly break. Now start tinc:
    systemctl start tinc.service

    If all goes well, ifconfig should show a myvpn device with IP 10.9.3.1.

    Configure the remote machine:

    It is the same as the above desktop config, with these exceptions:

    Putting it together:

    Once tinc is running on the server, copy the public tinc key of each machine into the tinc hosts directory of the other machine.

    Make sure port 19001 is open in the firewall on the myremote end.

    Restart tinc on both ends:

    systemctl restart tinc.service

    and you should now be able to ping the tinc IP of the other machine from both ends.

    This delivers to you a secure connection between desktop and a remote machine. If you would like to proxy browser traffic from mydesk through myremote, just install squid on myremote and enable connections from the tinc subnet. In your browser, set the proxy IP to the myremote tinc IP, port 3128 (default squid port), and select a proxy type of socks v5.

    [1] http://www.tinc-vpn.org/

    posted at: 08:17 | path: /Admin/VPN-options/Tinc | permanent link to this entry

    Thu, 04 Oct 2012


    /Admin/VPN-options/SSH-Proxy: A Do-It-Yourself Proxy For Those Who Need to Circumvent a Firewall

    Thanks to Jon[2] for reminding me that there is something better then flaky public proxies and the over-taxed Tor network[1]. Tor is still better if you want end-to-end security and anonymity, but if you just want a secure hop out of the local censored network and after that you do not care, renting a cheap server (as little as $8/month at vpslink[3], 100G of bandwidth included) is a simple and easy option.

    Assuming your remote server is called hostname.com, setting up an encrypted tunnel is as simple as executing this on a local terminal (must be root):

    ssh -v -CND 1080 username@hostname.com

    Note that for my own Debian server on the other end of the SSH proxy tunnel, I have found that "username" cannot be "root". I am not sure why this is (and it is definitely counter-intuitive) but if I try to tunnel to the root account on my server, when I try to use the tunnel to browse to a website it does not work and the following error is reported:

    channel 1: open failed: administratively prohibited: open failed

    If I tunnel to an ordinary user account on my server, I get no error and everything works. Go figure.....

    To semi-automate this I created an alias in my ~/.bashrc:

    tunnel="autossh -M 0 -v -CND 1080 username@hostname.com"

    Thereafter, in any terminal, just invoke "tunnel" to create the encrypted tunnel. (To eliminate the password prompt, setup passwordless authentication[6].)

    Any browser can use this proxy, by pointing its proxy setting at localhost and port 1080, with SOCKS 5 turned on. The Firefox FoxyProxy[4] plugin makes this infinitely more flexible by allowing the simultaneous configuration of multiple proxies, and providing fine-grained control over which websites are accessed using which proxies.

    Once FoxyProxy is installed into Firefox, you have the option of selecting any one proxy (or none) for all of your surfing, or associating certain websites with certain proxies and running FoxyProxy in "Patterns" mode. Since youtube is often getting itself blocked, a pattern for youtube would be:

    *.youtube.com/*

    While you are at it, install privoxy[5] and make it your default proxy for websites that have not been diverted to Tor or your just created personal proxy. Privoxy blocks a lot of advertisements and information gathering by nosy websites.

    Finally, note that

    ssh -v -CND 1080 username@hostname.com

    will only allow connections from the localhost. To allow connections from other computers over your local network, start it like this for example:

    ssh -v -CND [192.168.8.58]:1080 username@hostname.com

    This will allow any connections to port 1080 on the machine's exterior network interface. To start this as a persistent service at boot, add the following line to /etc/rc.local:

    su username -c 'autossh -M 0 -v -CND [192.168.8.58]:1080 username@hostname.com'&

    where username is the account you wish the service to run under.

    [1] http://www.torproject.org/
    [2] http://rejon.org/2009/07/access-facebook-through-the-great-firewall-second-line-ssh-tunnel/
    [3] http://blog.langex.net/index.cgi/Hosting/vpslink/
    [4] https://addons.mozilla.org/en-US/firefox/addon/2464
    [5] http://www.privoxy.org/
    [6] http://blog.langex.net/index.cgi/Admin/SSH-SSL/passwordless-ssh-authentication.html

    posted at: 08:39 | path: /Admin/VPN-options/SSH-Proxy | permanent link to this entry

    Tue, 03 Apr 2012


    /Admin/VPN-options/sshuttle: sshuttle is a Simple Alternative to VPN

    For anyone with (non-root) SSH access to remote servers, sshuttle[1] provides a very simple alternative to the key-juggling headache of configuring VPN. All you need is root locally (as it needs to modify iptables) and python installed on the opposite end. On the Virtual Machine I am using for some Twitter-related software development, I just turned off OpenVPN and replaced it with the following:

    sshuttle --dns -vvr userid@server.com 0/0 -x 192.168.8.0/24

    and behavior seems to be the same, ie. everything (including DNS) is sent through the SSH tunnel, except traffic going to the local 192.168.8.0/24 subnet. But, it seems there is no automatic restart if the connection is broken, sshuttle just errors out. Enter restartd, with this line in /etc/restartd.conf

    shuttleTunnel "sshuttle" "sshuttle --dns -r userid@server.com 0/0 -x 192.168.8.0/24" " "

    (Obviously I am using an SSH key here for passwordless server login....)

    It is worth reading [1] to understand that this tool is meant to restore packet loss and thus TCP's automatic speed throttling to an SSH tunnel connection, thus improving overall performance.

    [1] https://github.com/apenwarr/sshuttle/

    posted at: 06:45 | path: /Admin/VPN-options/sshuttle | permanent link to this entry

    Fri, 20 Jan 2012


    /Admin/VPN-options/OpenVPN: Basic OpenVPN as an Internet Gateway

    Aka. How to bore through the Great Firewall if you do not want to use an SSH tunnel.

    This[1] is the OpenVPN documentation, but it is not altogether straight-forward to read, and it is missing some necessary detail.

    This[2] will get OpenVPN basically working and connected for you. First create your keys:

    cd /usr/share/doc/openvpn/examples/easy-rsa/2.0 . ./vars ./clean-all ./build-ca ./build-key server ./build-key <client> ./build-dh

    Here I would add a warning from [1] that when creating your certificates above you must enter something at the "Common Name" prompt. My first time I just accepted all the defaults and got a connection error when I tried to start OpenVPN on my client. The second time, with a "Common Name" on the server certificates, everything just worked.

    Then distribute the keys to server and client(s) per the references.

    This will get the VPN client to the VPN server. However, we want to route *all* network traffic on the client through VPN and out to the internet. There are two components to this: some additional OpenVPN configuration, and some routing configuration on the server. On my VPN server, this is my /etc/openvpn/server.conf:

    port 1348
    proto udp
    dev tap
    ca ca.crt
    cert server.crt
    key server.key # This file should be kept secret
    dh dh1024.pem
    server 10.10.10.0 255.255.255.0 # vpn subnet
    ifconfig-pool-persist ipp.txt
    keepalive 10 120
    comp-lzo
    user nobody
    ; group nobody
    persist-key
    persist-tun
    verb 10
    mute 20
    client-to-client
    client-config-dir ccd "route 134.33.0.0 255.255.0.0"
    
    ; push "route 192.168.1.0 255.255.255.0" # home subnet
    push "redirect-gateway def1"
    push "dhcp-option DNS 10.10.10.1"
    

    This should be the same as in [2] except that "group nobody" line did not work on my Ubuntu Lucid server for some reason, and the last two "push" lines are what is needed on the server end to tell connecting clients to redirect all network traffic to the VPN. (Though I am not convinced that last dhcp line is having any effect on my Debian box at the moment....) Also, per [1], note that if your network interface is DHCP, it may die periodically because it is unable to communicate with your DHCP server.

    On my VPN client, this is my /etc/openvpn/client.conf:

    client
    dev tap
    proto udp
    resolv-retry infinite # this is necessary for DynDNS
    nobind
    user nobody
    ; group nobody
    persist-key
    persist-tun
    ca ca.crt
    cert x60s.crt
    key x60s.key
    comp-lzo
    verb 4
    mute 20
    

    which is the same as in [2], except for commenting out "group nobody", which did not work on my Debian Testing client machine.

    Now for routing on the server. What a PITA. I tried at some length to get raw iptables to do the job, but in the end turned to my old faithful, firehol. Here is my /etc/firehol/firehol.conf on my server, which enables the routing of traffic between tap0 (VPN) and eth0 (internet):

    version 5
    
    # interface eth0 internet
    interface eth0 internet
       protection strong 10/sec 10
       server "https http icmp ssh"  accept
       server openvpn accept
       server ident reject with tcp-reset
       client all   accept
    
    interface tap0 vpn
       server all   accept
       client all   accept
    
    router internet2vpn inface eth0 outface tap0
       masquerade reverse
       client all      accept
       server ident    reject with tcp-reset
    

    (After the fact, I ran into this[3] very interesting post....)

    [1] http://www.openvpn.net/index.php/open-source/documentation/howto.html
    [2] https://www.debian-administration.org/article/Connecting_to_office_network_using_OpenVPN_tunnel
    [3] http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux

    posted at: 04:58 | path: /Admin/VPN-options/OpenVPN | permanent link to this entry

    Sun, 17 Jan 2010


    /Admin/VPN-options/SSH-Proxy: Proxychains Allows Any Application to Use a Proxy

    My SSH Socks5 proxy[1] works great, especially with the addition of autossh, but unlike most web browsers and Pidgin, many applications (particularly on the command line) just do not have proxy support built in.

    Proxychains[2] is a wrapper that redirects all network traffic through a designated proxy. To get it working is very simple. After installing, I made this change to the bottom of /etc/proxychains.conf:

    # defaults set to "tor"
    # socks4 127.0.0.1 9050
    socks5 127.0.0.1 1082

    ie. I commented out the default Tor proxy and added my local SSH socks5 proxy which I have placed on port 1082.

    Then, for instance, to send my gpodder podcatcher through the SSH tunnel, I just start gpodder in a terminal as follows:

    proxychains gpodder&

    Then all of gpodder's network traffic (DNS queries included) go out via SSH through my out-of-country server. And now I have restored access to many blocked podcasts, PGP key servers, and no doubt many other things as they come up. I have been looking for something like this for years.

    [1] http://blog.langex.net/index.cgi/Admin/SSH-Proxy/
    [2] http://proxychains.sourceforge.net/

    posted at: 09:04 | path: /Admin/VPN-options/SSH-Proxy | permanent link to this entry

    Fri, 08 Jan 2010


    /Admin/VPN-options/SSH-Proxy: Use autossh to Fix Frequent Disconnects

    Sometimes the bandwidth is so bad here (or is it the "Great Firewall" deliberately trying to break my connection?) that my SSH tunnel will frequently fail. Very inconvenient, as I do not notice until I need it, then I have to do a manual restart and wait for it to connect (and said wait can sometimes be significant when bandwidth sucks...)

    Enter autossh[1].

    I have setup an alias in my .bashrc as follows:

    alias tunnel="autossh -M 0 -v -CND 1082 username@hostname.com"

    To start the tunnel at the beginning of the day, I just type "tunnel" in any terminal. And whenever the ssh connection is broken, autossh automatically (and apparently intelligently) restarts it. So far, so good.

    [1] http://www.harding.motd.ca/autossh/

    posted at: 01:11 | path: /Admin/VPN-options/SSH-Proxy | permanent link to this entry