From ae98b36a4b214d8b5366b08b71c15ae16ff11320 Mon Sep 17 00:00:00 2001 From: Rob Date: Wed, 27 Feb 2019 00:35:01 +0800 Subject: [PATCH] directory restructered --- advanced.txt | 48 ------ chinese.html | 58 ------- chinese/advanced-resources.txt | 48 ++++++ docs/compile.sh | 10 ++ docs/fastd.html | 276 ++++++++++++++++++++++++++++++++ docs/fastd.txt | 248 +++++++++++++++++++++++++++++ docs/ikev2-nat-rw.html | 101 ++++++++++++ docs/ikev2-nat-rw.txt | 87 ++++++++++ docs/resources.html | 44 +++++ docs/resources.txt | 40 +++++ docs/tinc.html | 354 +++++++++++++++++++++++++++++++++++++++++ docs/tinc.txt | 328 ++++++++++++++++++++++++++++++++++++++ docs/tmp.html | 51 ++++++ docs/tmp.txt | 49 ++++++ docs/tunneling.html | 21 +++ docs/tunneling.txt | 9 ++ fastd.html | 276 -------------------------------- fastd.txt | 248 ----------------------------- ikev2-nat-rw.html | 101 ------------ ikev2-nat-rw.txt | 87 ---------- index.html | 85 ++++++---- index.md | 19 --- old/chinese.html | 58 +++++++ old/fastd.html | 276 ++++++++++++++++++++++++++++++++ old/ikev2-nat-rw.html | 101 ++++++++++++ old/index.html | 84 ++++++++++ old/index.md | 19 +++ old/resources.html | 44 +++++ old/tinc.html | 354 +++++++++++++++++++++++++++++++++++++++++ old/tunneling.html | 21 +++ resources.html | 44 ----- resources.txt | 40 ----- tinc.html | 354 ----------------------------------------- tinc.txt | 328 -------------------------------------- tmp.txt | 49 ------ tunneling.html | 21 --- tunneling.txt | 9 -- 37 files changed, 2675 insertions(+), 1715 deletions(-) delete mode 100644 advanced.txt delete mode 100644 chinese.html create mode 100644 chinese/advanced-resources.txt create mode 100755 docs/compile.sh create mode 100644 docs/fastd.html create mode 100644 docs/fastd.txt create mode 100644 docs/ikev2-nat-rw.html create mode 100644 docs/ikev2-nat-rw.txt create mode 100644 docs/resources.html create mode 100644 docs/resources.txt create mode 100644 docs/tinc.html create mode 100644 docs/tinc.txt create mode 100644 docs/tmp.html create mode 100644 docs/tmp.txt create mode 100644 docs/tunneling.html create mode 100644 docs/tunneling.txt delete mode 100644 fastd.html delete mode 100644 fastd.txt delete mode 100644 ikev2-nat-rw.html delete mode 100644 ikev2-nat-rw.txt delete mode 100644 index.md create mode 100644 old/chinese.html create mode 100644 old/fastd.html create mode 100644 old/ikev2-nat-rw.html create mode 100644 old/index.html create mode 100644 old/index.md create mode 100644 old/resources.html create mode 100644 old/tinc.html create mode 100644 old/tunneling.html delete mode 100644 resources.html delete mode 100644 resources.txt delete mode 100644 tinc.html delete mode 100644 tinc.txt delete mode 100644 tmp.txt delete mode 100644 tunneling.html delete mode 100644 tunneling.txt diff --git a/advanced.txt b/advanced.txt deleted file mode 100644 index 40f6322..0000000 --- a/advanced.txt +++ /dev/null @@ -1,48 +0,0 @@ -Chinese Learning -~~~~~~~~~~ - -Here are some resources for the more advanced learners. Instead of using books, you might want to pick a podcast, tv show or radio program that Chinese listen to themselves. Still have to parse the Chinese correctly... - --------------- - -原来是这样！- http://www.ximalaya.com/7200706/album/246622/ -Podcast about some interesting scientific (useless?) facts. It's a two host show, with basically the girl 装疯卖傻. Recordings are quite long, but well eloborated and not too technical. - -Difficulty: 3 - -上班脱口秀 - http://www.ximalaya.com/6534662/album/336435/ -Short broadcast about current events. Supposed to be funny, but that might be a matter of taste. Great way to stay up to date. Pace is fast, a lot of slang. - -Difficulty: 4 - - -新闻今日谈 https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm -Analysis of political events. A guest speaker is invited and does usually discuss two news items in 20 minutes. Hosts are from mainland, taiwan and hongkong, might have some dialect issues. - -Difficulty: 4.5 - -圓桌派 -The continuation of 锵锵三人行, that for some reason dissapeared. Four people discussing current events, pace is slow, use a lot of trendy words. Has subtitles in Chinese -https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm - -Diffuculty: 3.5 - -凤凰财知道 -Although the name says finance, it basically discusses anyting that is even remotely related to money. Short, but quite intense. You can find subtitles somewhere in cyberspace if you search on the title. - -http://diantai.ifeng.com/#!/category/1/92395 - -Difficulty: 5 - -一虎一席谈 -Discussion panel with many speakers (including the audience). An excited and composed host. Often has non-native speakers on the show. About societal issues, often a 'Yes' front and 'No' front. Quite long, but has subtitles. - https://www.youtube.com/playlist?list=PLvXvMUSstINfmrcFH0LFBBYW9OcEuA3yx - -Difficulty 4.5 - -公开课 -These are some free courses you can download (most are on university level) -谈判学 - series of classes about negotiation -物流学 - series of classes about transportation - -Difficulty: 4 diff --git a/chinese.html b/chinese.html deleted file mode 100644 index 134e4ed..0000000 --- a/chinese.html +++ /dev/null @@ -1,58 +0,0 @@ - - - -Chinese Learning - - - - -

Chinese Learning

- -

Here are some resources for the more advanced learners. Instead of using books, you might want to pick a podcast, tv show or radio program that Chinese listen to themselves. Still have to parse the Chinese correctly... -

-
- -

原来æ~&hibar;è¿TM样！- http://www.ximalaya.com/7200706/album/246622/ -Podcast about some interesting scientific (useless?) facts. It's a two host show, with basically the girl 装ç–&hibar;卖傻. Recordings are quite long, but well eloborated and not too technical. -

-

Difficulty: 3 -

-

上班脱口秀 - http://www.ximalaya.com/6534662/album/336435/ -Short broadcast about current events. Supposed to be funny, but that might be a matter of taste. Great way to stay up to date. Pace is fast, a lot of slang. -

-

Difficulty: 4 -

-

新闻今日谈 https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm -Analysis of political events. A guest speaker is invited and does usually discuss two news items in 20 minutes. Hosts are from mainland, taiwan and hongkong, might have some dialect issues. -

-

Difficulty: 4.5 -

-

圓桌派
-The continuation of 锵锵三人行, that for some reason dissapeared. Four people discussing current events, pace is slow, use a lot of trendy words. Has subtitles in Chinese -https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm -

-

Diffuculty: 3.5 -

-

凤凰财知道
-Although the name says finance, it basically discusses anyting that is even remotely related to money. Short, but quite intense. You can find subtitles somewhere in cyberspace if you search on the title. -

-

http://diantai.ifeng.com/#!/category/1/92395 -

-

Difficulty: 5 -

-

一èTMŽä¸€å¸­è°ˆ
-Discussion panel with many speakers (including the audience). An excited and composed host. Often has non-native speakers on the show. About societal issues, often a 'Yes' front and 'No' front. Quite long, but has subtitles. - https://www.youtube.com/playlist?list=PLvXvMUSstINfmrcFH0LFBBYW9OcEuA3yx -

-

Difficulty 4.5 -

-

公开è&hibar;¾
-These are some free courses you can download (most are on university level) -谈判学 - series of classes about negotiation -物流学 - series of classes about transportation -

-

Difficulty: 4

- - - diff --git a/chinese/advanced-resources.txt b/chinese/advanced-resources.txt new file mode 100644 index 0000000..40f6322 --- /dev/null +++ b/chinese/advanced-resources.txt @@ -0,0 +1,48 @@ +Chinese Learning +~~~~~~~~~~ + +Here are some resources for the more advanced learners. Instead of using books, you might want to pick a podcast, tv show or radio program that Chinese listen to themselves. Still have to parse the Chinese correctly... + +-------------- + +原来是这样！- http://www.ximalaya.com/7200706/album/246622/ +Podcast about some interesting scientific (useless?) facts. It's a two host show, with basically the girl 装疯卖傻. Recordings are quite long, but well eloborated and not too technical. + +Difficulty: 3 + +上班脱口秀 - http://www.ximalaya.com/6534662/album/336435/ +Short broadcast about current events. Supposed to be funny, but that might be a matter of taste. Great way to stay up to date. Pace is fast, a lot of slang. + +Difficulty: 4 + + +新闻今日谈 https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm +Analysis of political events. A guest speaker is invited and does usually discuss two news items in 20 minutes. Hosts are from mainland, taiwan and hongkong, might have some dialect issues. + +Difficulty: 4.5 + +圓桌派 +The continuation of 锵锵三人行, that for some reason dissapeared. Four people discussing current events, pace is slow, use a lot of trendy words. Has subtitles in Chinese +https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm + +Diffuculty: 3.5 + +凤凰财知道 +Although the name says finance, it basically discusses anyting that is even remotely related to money. Short, but quite intense. You can find subtitles somewhere in cyberspace if you search on the title. + +http://diantai.ifeng.com/#!/category/1/92395 + +Difficulty: 5 + +一虎一席谈 +Discussion panel with many speakers (including the audience). An excited and composed host. Often has non-native speakers on the show. About societal issues, often a 'Yes' front and 'No' front. Quite long, but has subtitles. + https://www.youtube.com/playlist?list=PLvXvMUSstINfmrcFH0LFBBYW9OcEuA3yx + +Difficulty 4.5 + +公开课 +These are some free courses you can download (most are on university level) +谈判学 - series of classes about negotiation +物流学 - series of classes about transportation + +Difficulty: 4 diff --git a/docs/compile.sh b/docs/compile.sh new file mode 100755 index 0000000..1d4daba --- /dev/null +++ b/docs/compile.sh @@ -0,0 +1,10 @@ +### compile all + +if [ -x /usr/bin/txt2html ]; then + txt2html --version + for FILE in *.txt; do + NEWFILE=$(echo $FILE | sed 's/txt/html/') + txt2html --infile $FILE --outfile $NEWFILE --style_url ../files/style.css + echo "Compiled $FILE to $NEWFILE" + done +fi diff --git a/docs/fastd.html b/docs/fastd.html new file mode 100644 index 0000000..29d91cb --- /dev/null +++ b/docs/fastd.html @@ -0,0 +1,276 @@ + + + + + + + + +

Redirecting traffic using FastD

+ +

FastD is a VPN daemon that has many features of OpenVPN and Tinc and is optimized for small code size and small number of dependencies. Fastd became popular on small devices like routers. In this tutorial we will configure a listening peer (alpha) and a connecting peer (anyremote). On a side note, with fastD you can setup mesh networks (n:n), as opposed to classical clients server networks (1:n). This configuration can be seen as a simple (1:1) setup between the listening alpha peer and our connecting client anyremote. All traffic from anyremote is redirected to alpha, making alpha the default gateway. This configuration has a lot of similarities with the tinc tutorial (that you can find here: http://www.robinkrens.nl/tutorials/tinc.html). Documentation and manual pages of fastd can be found here http://fastd.readthedocs.io +

+
+ +

Alpha peer

+ +

To run the daemon you only need one configuration file. You can place it in fastd's defualt directory /etc/fastd/fastd.conf. Here we show a standard configuration of fastd.conf with some minor changes: +

+
+        # Log warnings and errors to stderr
+        log level warn;
+
+        # Log everything to syslog
+        log to syslog level debug;
+
+        # tunnel mode (default is tap). 
+        # We use tunneling mode, since we are dealing with routing
+        mode tun;
+
+        # Set the interface name
+        # you can use any name you like
+        # this is the name to configure your interface wit
+        interface "vpngateway";
+
+        # encryption method to use
+        falls back to null if salsa is not chosen.
+        method "salsa2012+umac";
+        method "null";
+
+        # Bind to a fixed port, IPv4 only
+        # If your remote ip is 1.2.3.4, make sure 1.2.3.4:10000 is accesible
+        bind 0.0.0.0:10000;
+
+        # Secret key generated by `fastd --generate-key`
+        # --generate-key outputs a file with a secret and public key
+        # secret key goes in here. Public keys is distributed amongst other peers
+        # read about PKI infrastructures if you don't know about this.
+        secret "supersecretkey";
+
+        # (see MTU selection documentation)
+        # base MTU is 1500 and you want to use TUN mode over IPv4 with any 
+        # crypto method: Choose 1500 - 52 = 1448 bytes.
+        mtu 1448;
+
+        # on up: shell script to configure the tun interface on daemon start
+        on up "./interface-up";
+
+        # on down: shell script when daemon is terminated
+        on down "./interface-down"; 
+
+        # Include peers from the directory 'peers'
+        # anyremote is a peer trying to connect to alpha
+        include peer "peers/anyremote";
+
+

Keys can be generate by running --generate-key (written to stdout): + +

+        root@alpha:~$ fastd --generate-key > keys
+        root@alpha:~$ cat keys
+        2018-04-30 19:25:57 +0800 --- Info: Reading 32 bytes from /dev/random...
+        Secret: 5035de5b4ea448b74e9a373765207095057a9485fd9dca5fadb9c1b86347bd75
+        Public: 8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42
+
+

The secret key needs to be added to the above fastd.conf file. The public needs to be spread amongst peers (as we explain later). +on up "./interface-up" will run a simple shell script and configures our network interface vpngateway (make sure this script is executable). +This is our interface.up script: We create a virtual IP: 172.16.16.1. +

+
+        #!/bin/bash
+        ip link set $INTERFACE up
+        ip addr add 172.16.16.1/24 dev $INTERFACE
+
+

If we terminate fastd, we run a similar script as defined in interface-down + +

+        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
+

We will create the peer/anyremote file after we finished configuring anyremote and its public key +

+

Anyremote peer

+ +

Similar to alpha, we create /etc/fastd/fastd.conf. Since we only need to connect to alpha we don't need to bind to a fixed port. +

+
+        # log arnings and errors to stderr
+        log level warn;
+
+        # Log everything to syslog
+        log to syslog level debug;
+
+        # tunnel mode (default is tap)
+        mode tun;
+
+        # Set the interface name
+        interface "vpngateway";
+
+        # Support salsa2012+umac and null methods, prefer salsa2012+umac
+        method "salsa2012+umac";
+        method "null";
+
+        # Secret key generated by `fastd --generate-key`
+        secret "supersecretkey";
+
+        # (see MTU selection documentation)
+        mtu 1448;
+
+        # daemon start
+        on up "./interface-up";
+
+        # daemon terminated
+        on down "./interface-down";
+
+        # if a connection is established set up the gateway
+        on establish "./set-gateway";
+
+        # if the connection is lost restore the default gateway
+        on disestablish "./restore-gateway";
+
+        # Include peers from the directory 'peers'
+        include peer "peers/alpha";
+
+

For anyremote we also need to generate a key pair and replace the "supersecretkey" with the secret key value. The public key will be given to alpha (explained in a little while) +

+
+        root@anyremote~ $ fastd --generate-keys > anyremote-keypair
+        root@anyremote~ $ cat anyremote-keypair
+        2018-05-01 19:48:49 +0800 --- Info: Reading 32 bytes from /dev/random...
+        Secret: c0a611e0d4f3075b45cf172d3221c8427008e2c6f541b5b6adda0368cb79f271
+        Public: 2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9
+
+ +

on up and on down are similar to alpha (except the ip address). interface-up: + +

+        #!/bin/bash
+        ip link set $INTERFACE up
+        ip addr add 172.16.16.2/24 dev $INTERFACE
+
+ +

interface-down: +

+
+        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
+

We need to include some information about how to connect to alpha. We define in a file (/etc/fastd/peers/alpha): +

+
+        root@anyremote:/etc/fastd/peers/ $ cat alpha
+        # alpha 
+        key "8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42";
+        remote 1.2.3.4:10000;
+
+

key means the public key we just created with --generate-keys the alpha section. Here we add a remote ip to which anyremote tries to connect to. Make sure port numbers are the same. +Don't forget to also add our our just created public key to our alpha server: +

+
+        root@alpha:/etc/fastd/peers/ $ cat anyremote
+        # anyremote
+        key "2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9";
+
+

This will allow alpha to accept connections from anyremote. Note: you don't need to specify a remote address, this will make it more dynamic and you can connect with anyremote from anywhere as long as you have the private key. +

+

After these steps you should be able to run both alpha and anyremote. You can run the daemon as follows: + +

+        root@alpha:~ $ fastd -c /etc/fastd/fastd.conf &
+        root@anyremote:~ $ fastd -c /etc/fastd/fastd.conf &
+
+

The interface vpngateway should show up and you should be able to ping to both hosts us. + +

Now, in our config file of anyremote we see two additionals values: on establish and on disestablish. Once the connection is (dis)established, fastd will execute these scripts. This brings us two the last step: setting the default gateway of anyremote to point to alpha +

+

Alpha as gateway for anyremote

+ +

Have a look at the tinc tutorial (gateway section) about the theory of routing and gateways. +We add the following scripts in /etc/fastd of anyremote if a connection with alpha is established: (set-gateway) + +

+        #!/bin/bash
+        #ip link set $INTERFACE up
+        #ip addr add 172.16.16.2/24 dev $INTERFACE
+
+        VPN_GATEWAY=172.16.16.1
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=1.2.3.4
+
+        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route add $VPN_GATEWAY dev $INTERFACE
+        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+
+ +

And, similar, if the connecting is lost: (restore-gateway): +

+
+        #!/bin/sh
+        #ip addr del 172.16.16.2/24 dev $INTERFACE
+        #ip link set $INTERFACE down
+
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=45.76.159.1
+
+        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route del $VPN_GATEWAY dev $INTERFACE
+        ip route del 0.0.0.0/1 dev $INTERFACE
+        ip route del 128.0.0.0/1 dev $INTERFACE
+
+

Setup firewall

+ +

Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded anyremote) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. +

+
+        #!/bin/sh
+        # iptables config line to masquerade
+        
+        echo "Enabling IPv4 forwarding"
+        echo 1 >/proc/sys/net/ipv4/ip_forward
+        
+        echo "Appending Masquerade rule to iptables"
+        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
+
+

I use iptables to masquerade the (-s) source address on the (-o) interface eth0. +

+

Test the gateway

+ +

Restart the daemon on alpha and anyremote. Use route -n to see check your routing tables. Ping both 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. +

+

Troubleshooting help

+ + +
+        root@anyremote:~$ cat /etc/resolv.conf  
+        # resolv.conf file
+        nameserver 127.0.1.0
+
+ +
+        IP ROUTING TABLE
+        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
+
+ +
+        --log-level error|warn|info|verbose|debug|debug2
+        Sets the stderr log level; default is info if no alternative log
+        destination is configured.
+
+ + + + diff --git a/docs/fastd.txt b/docs/fastd.txt new file mode 100644 index 0000000..1197a1e --- /dev/null +++ b/docs/fastd.txt @@ -0,0 +1,248 @@ +Redirecting traffic using FastD +===== + +FastD is a VPN daemon that has many features of OpenVPN and Tinc and is optimized for small code size and small number of dependencies. Fastd became popular on small devices like routers. In this tutorial we will configure a listening peer (alpha) and a connecting peer (anyremote). On a side note, with fastD you can setup mesh networks (n:n), as opposed to classical clients server networks (1:n). This configuration can be seen as a simple (1:1) setup between the listening *alpha* peer and our connecting client *anyremote*. All traffic from anyremote is redirected to alpha, making alpha the default gateway. This configuration has a lot of similarities with the tinc tutorial (that you can find here: http://www.robinkrens.nl/tutorials/tinc.html). Documentation and manual pages of fastd can be found here http://fastd.readthedocs.io + +-------------- + +Alpha peer +********** + +To run the daemon you only need one configuration file. You can place it in fastd's defualt directory _/etc/fastd/fastd.conf_. Here we show a standard configuration of _fastd.conf_ with some minor changes: + + # Log warnings and errors to stderr + log level warn; + + # Log everything to syslog + log to syslog level debug; + + # tunnel mode (default is tap). + # We use tunneling mode, since we are dealing with routing + mode tun; + + # Set the interface name + # you can use any name you like + # this is the name to configure your interface wit + interface "vpngateway"; + + # encryption method to use + falls back to null if salsa is not chosen. + method "salsa2012+umac"; + method "null"; + + # Bind to a fixed port, IPv4 only + # If your remote ip is 1.2.3.4, make sure 1.2.3.4:10000 is accesible + bind 0.0.0.0:10000; + + # Secret key generated by `fastd --generate-key` + # --generate-key outputs a file with a secret and public key + # secret key goes in here. Public keys is distributed amongst other peers + # read about PKI infrastructures if you don't know about this. + secret "supersecretkey"; + + # (see MTU selection documentation) + # base MTU is 1500 and you want to use TUN mode over IPv4 with any + # crypto method: Choose 1500 - 52 = 1448 bytes. + mtu 1448; + + # on up: shell script to configure the tun interface on daemon start + on up "./interface-up"; + + # on down: shell script when daemon is terminated + on down "./interface-down"; + + # Include peers from the directory 'peers' + # anyremote is a peer trying to connect to alpha + include peer "peers/anyremote"; + +Keys can be generate by running --generate-key (written to stdout): + + root@alpha:~$ fastd --generate-key > keys + root@alpha:~$ cat keys + 2018-04-30 19:25:57 +0800 --- Info: Reading 32 bytes from /dev/random... + Secret: 5035de5b4ea448b74e9a373765207095057a9485fd9dca5fadb9c1b86347bd75 + Public: 8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42 + +The secret key needs to be added to the above _fastd.conf_ file. The public needs to be spread amongst peers (as we explain later). +on up "./interface-up" will run a simple shell script and configures our network interface vpngateway (make sure this script is executable). +This is our _interface.up_ script: We create a virtual IP: 172.16.16.1. + + #!/bin/bash + ip link set $INTERFACE up + ip addr add 172.16.16.1/24 dev $INTERFACE + +If we terminate fastd, we run a similar script as defined in interface-down + + #!/bin/sh + ip addr del 172.16.16.1/24 dev $INTERFACE + ip link set $INTERFACE down + +We will create the _peer/anyremote_ file after we finished configuring anyremote and its public key + +Anyremote peer +********* + +Similar to alpha, we create _/etc/fastd/fastd.conf_. Since we only need to connect to alpha we don't need to bind to a fixed port. + + # log arnings and errors to stderr + log level warn; + + # Log everything to syslog + log to syslog level debug; + + # tunnel mode (default is tap) + mode tun; + + # Set the interface name + interface "vpngateway"; + + # Support salsa2012+umac and null methods, prefer salsa2012+umac + method "salsa2012+umac"; + method "null"; + + # Secret key generated by `fastd --generate-key` + secret "supersecretkey"; + + # (see MTU selection documentation) + mtu 1448; + + # daemon start + on up "./interface-up"; + + # daemon terminated + on down "./interface-down"; + + # if a connection is established set up the gateway + on establish "./set-gateway"; + + # if the connection is lost restore the default gateway + on disestablish "./restore-gateway"; + + # Include peers from the directory 'peers' + include peer "peers/alpha"; + +For anyremote we also need to generate a key pair and replace the "supersecretkey" with the secret key value. The public key will be given to alpha (explained in a little while) + + root@anyremote~ $ fastd --generate-keys > anyremote-keypair + root@anyremote~ $ cat anyremote-keypair + 2018-05-01 19:48:49 +0800 --- Info: Reading 32 bytes from /dev/random... + Secret: c0a611e0d4f3075b45cf172d3221c8427008e2c6f541b5b6adda0368cb79f271 + Public: 2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9 + + +*on up* and *on down* are similar to alpha (except the ip address). interface-up: + + #!/bin/bash + ip link set $INTERFACE up + ip addr add 172.16.16.2/24 dev $INTERFACE + +interface-down: + + #!/bin/sh + ip addr del 172.16.16.1/24 dev $INTERFACE + ip link set $INTERFACE down + +We need to include some information about how to connect to alpha. We define in a file (_/etc/fastd/peers/alpha_): + + root@anyremote:/etc/fastd/peers/ $ cat alpha + # alpha + key "8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42"; + remote 1.2.3.4:10000; + +*key* means the public key we just created with --generate-keys the alpha section. Here we add a remote ip to which anyremote tries to connect to. Make sure port numbers are the same. +Don't forget to also add our our just created public key to our alpha server: + + root@alpha:/etc/fastd/peers/ $ cat anyremote + # anyremote + key "2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9"; + +This will allow alpha to accept connections from anyremote. Note: you don't need to specify a remote address, this will make it more dynamic and you can connect with anyremote from anywhere as long as you have the private key. + +After these steps you should be able to run both alpha and anyremote. You can run the daemon as follows: + + root@alpha:~ $ fastd -c /etc/fastd/fastd.conf & + root@anyremote:~ $ fastd -c /etc/fastd/fastd.conf & + +The interface *vpngateway* should show up and you should be able to ping to both hosts us. + +Now, in our config file of anyremote we see two additionals values: *on establish* and *on disestablish*. Once the connection is (dis)established, fastd will execute these scripts. This brings us two the last step: setting the default gateway of anyremote to point to alpha + +Alpha as gateway for anyremote +********** + +Have a look at the tinc tutorial (gateway section) about the theory of routing and gateways. +We add the following scripts in _/etc/fastd_ of anyremote if a connection with alpha is established: (set-gateway) + + #!/bin/bash + #ip link set $INTERFACE up + #ip addr add 172.16.16.2/24 dev $INTERFACE + + VPN_GATEWAY=172.16.16.1 + ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` + REMOTEADDRESS=1.2.3.4 + + ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY + ip route add $VPN_GATEWAY dev $INTERFACE + ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE + ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE + +And, similar, if the connecting is lost: (restore-gateway): + + #!/bin/sh + #ip addr del 172.16.16.2/24 dev $INTERFACE + #ip link set $INTERFACE down + + ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` + REMOTEADDRESS=45.76.159.1 + + ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY + ip route del $VPN_GATEWAY dev $INTERFACE + ip route del 0.0.0.0/1 dev $INTERFACE + ip route del 128.0.0.0/1 dev $INTERFACE + + +Setup firewall +******* + +Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded anyremote) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. + + #!/bin/sh + # iptables config line to masquerade + + echo "Enabling IPv4 forwarding" + echo 1 >/proc/sys/net/ipv4/ip_forward + + echo "Appending Masquerade rule to iptables" + iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE + +I use iptables to masquerade the (-s) source address on the (-o) interface eth0. + + +Test the gateway +******** + +Restart the daemon on alpha and anyremote. Use route -n to see check your routing tables. Ping both 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. + +Troubleshooting help +******* + +* DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration + + root@anyremote:~$ cat /etc/resolv.conf + # resolv.conf file + nameserver 127.0.1.0 + +* and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway + + IP ROUTING TABLE + link-local * 255.255.0.0 U 1000 0 0 wlp7s0 + +* A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 + +* Fastd's log to _/var/log/syslog_ You can define these locations in your fast.conf file. You can also change the log level, in case you need more information: + + --log-level error|warn|info|verbose|debug|debug2 + Sets the stderr log level; default is info if no alternative log + destination is configured. + +* Use tcpdump or wireshark to analyze your network devices diff --git a/docs/ikev2-nat-rw.html b/docs/ikev2-nat-rw.html new file mode 100644 index 0000000..4fcb983 --- /dev/null +++ b/docs/ikev2-nat-rw.html @@ -0,0 +1,101 @@ + + + + + + + + +

Strongswan road warrior setup with Virtual IPs

+ +

strongSwan is an IPsec solution providing encryption and authentication to servers and clients. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. In this HOWTO, I explain how to setup up a secure connection to your server. In this setup your host will be the gateway, you might have other servers behind this gateway you can then reach securily. In this particular setup we use public key authentication between a roadwarrior and your server. Roadwarriors is the term Strongswan uses for laptops or other mobile devices that connect from a remote location to your network. More on this particular setup can be found here: https://www.strongswan.org/testing/testresults/ikev2/mobike-virtual-ip-nat/index.html +Note: some distributions use ipsec as command, others use strongswan +

+
+ +

Setup a PKI infrastructure

+ +

To set up a public key infrastructure (PKI), we first need to create a self-signed Certificate Authority (CA). We use StrongSwan's built-in command `ipsec pki`. Later on, our CA will issue end-entity certificates. Generate a private key for the CA: +

+

ipsec pki --gen > caKey.der +

+

Now self-sign a CA certificate using the generated key. Adjust the distinguished name (DN) to your needs, it will be included in all issued certificates. +

+

ipsec pki --self --in caKey.der --dn "C=USA, O= , CN=Host CA" --ca > caCert.der +

+

Generate a private key for your host and use your CA to issue a certificate. +

+
+        ipsec pki --gen > hostKey.der`
+        ipsec pki --pub --in hostKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O=  CN=host" > hostCert.der` --san your_IP
+
+

Now place the created files in the following directories of your Host: +

+
+        /etc/ipsec.d/private/hostKey.der
+        /etc/ipsec.d/certs/hostCert.der
+        /etc/ipsec.d/cacerts/caCert.der
+
+

Similar, we can generate a private key and issue a certiciate for our client. +

+
+        ipsec pki --gen > clientKey.der
+        ipsec pki --pub --in clientKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= , CN=client" > clientCert.der
+
+

On your client you will need the client key and certificate as well as your CA certificate. To make it a bit more convenient, you can wrap these files in one .p12 file using the following command: +

+
+        openssl rsa -inform der -outform pem -in peerKey.der -out peerKey.pem
+        openssl pkcs12 -in clientCert.pem -inkey clientKey.pem -certfile caCert.pem -export -out client.p12`
+
+

Configure strongSwan

+ +

Your /etc/ipsec.conf configuration file on your host should contain the following: +

+

config setup +

+
+        conn %default
+                ikelifetime=60m
+                keylife=20m
+                rekeymargin=3m
+                keyingtries=1
+                keyexchange=ikev2
+
+        conn virtualip
+                leftsubnet=0.0.0.0/0
+                #leftid=alpha
+                #leftauth=pubkey
+                #rightauth=pubkey
+                #leftsendcert=always
+                leftfirewall=yes
+                right=%any
+                rightdns=8.8.8.8,8.8.4.4
+                rightsourceip=172.16.16.0/24
+                auto=add
+
+

Edit your /etc/ipsec.secrets and add the following line: +

+

: RSA hostKey.der +

+

Please note that both sides of the colon ':' need a white-space! +

+

Allow forwarding and configure firewall

+ +

In order to forward traffic to hosts behind the gateway the following +option has to be enabled on your host: +

+
+        sysctl net.ipv4.ip_forward=1
+        sysctl net.ipv6.conf.all.forwarding=1
+
+

This can be added to /etc/sysctl.conf to enable it permanently. +

+

Makes sure the ports accept traffic and masquerading: +

+        sudo iptables -A INPUT -p udp -dport 500/4500 -j ACCEPT
+        sudo iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE
+
+ + diff --git a/docs/ikev2-nat-rw.txt b/docs/ikev2-nat-rw.txt new file mode 100644 index 0000000..8b4520b --- /dev/null +++ b/docs/ikev2-nat-rw.txt @@ -0,0 +1,87 @@ +Strongswan road warrior setup with Virtual IPs +======= + +strongSwan is an IPsec solution providing encryption and authentication to servers and clients. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. In this HOWTO, I explain how to setup up a secure connection to your server. In this setup your host will be the *gateway*, you might have other servers behind this gateway you can then reach securily. In this particular setup we use public key authentication between a *roadwarrior* and your server. Roadwarriors is the term Strongswan uses for laptops or other mobile devices that connect from a remote location to your network. More on this particular setup can be found here: https://www.strongswan.org/testing/testresults/ikev2/mobike-virtual-ip-nat/index.html +Note: some distributions use *ipsec* as command, others use *strongswan* + +---------- + +Setup a PKI infrastructure +********** + +To set up a public key infrastructure (PKI), we first need to create a self-signed Certificate Authority (CA). We use StrongSwan's built-in command `ipsec pki`. Later on, our CA will issue end-entity certificates. Generate a private key for the CA: + + ipsec pki --gen > caKey.der + +Now self-sign a CA certificate using the generated key. Adjust the distinguished name (DN) to your needs, it will be included in all issued certificates. + + ipsec pki --self --in caKey.der --dn "C=USA, O= , CN=Host CA" --ca > caCert.der + +Generate a private key for your host and use your CA to issue a certificate. + + ipsec pki --gen > hostKey.der` + ipsec pki --pub --in hostKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= CN=host" > hostCert.der` --san your_IP + +Now place the created files in the following directories of your Host: + + /etc/ipsec.d/private/hostKey.der + /etc/ipsec.d/certs/hostCert.der + /etc/ipsec.d/cacerts/caCert.der + +Similar, we can generate a private key and issue a certiciate for our client. + + ipsec pki --gen > clientKey.der + ipsec pki --pub --in clientKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= , CN=client" > clientCert.der + +On your client you will need the client key and certificate as well as your CA certificate. To make it a bit more convenient, you can wrap these files in one .p12 file using the following command: + + openssl rsa -inform der -outform pem -in peerKey.der -out peerKey.pem + openssl pkcs12 -in clientCert.pem -inkey clientKey.pem -certfile caCert.pem -export -out client.p12` + +Configure strongSwan +********** + +Your /etc/ipsec.conf configuration file on your host should contain the following: + + config setup + + conn %default + ikelifetime=60m + keylife=20m + rekeymargin=3m + keyingtries=1 + keyexchange=ikev2 + + conn virtualip + leftsubnet=0.0.0.0/0 + #leftid=alpha + #leftauth=pubkey + #rightauth=pubkey + #leftsendcert=always + leftfirewall=yes + right=%any + rightdns=8.8.8.8,8.8.4.4 + rightsourceip=172.16.16.0/24 + auto=add + +Edit your /etc/ipsec.secrets and add the following line: + + : RSA hostKey.der + +Please note that both sides of the colon ':' need a white-space! + +Allow forwarding and configure firewall +************ + +In order to forward traffic to hosts behind the gateway the following +option has to be enabled on your host: + + sysctl net.ipv4.ip_forward=1 + sysctl net.ipv6.conf.all.forwarding=1 + +This can be added to /etc/sysctl.conf to enable it permanently. + +Makes sure the ports accept traffic and masquerading: + sudo iptables -A INPUT -p udp -dport 500/4500 -j ACCEPT + sudo iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE + diff --git a/docs/resources.html b/docs/resources.html new file mode 100644 index 0000000..4651d9f --- /dev/null +++ b/docs/resources.html @@ -0,0 +1,44 @@ + + + + + + + + +

Linux Resources

+ +

This page lists some useful resources for a more in depth understanding on specific subjects. Assumed is that you have a basic understanding of Linux and Networking. If not, you might to start with one of the followings books +

+ +

Networking

+

A good way to understand more about networking is two setup two computers: a server and a client. And the play around with the tools. The following tools and documentation are extremely useful. +

+

Netcat

+

Simple tool to open or connect to TCP or UDP ports and output data through these channels. Build and test proxies. Powerful for debugging. Cryptcat is a similar tool, but with support for cryptography +

+

Sendip

+

Create and send IP, TCP or UDP packages. You are able to edit any value within these packages. +

+

Iptables

+

Although there is more abstract software to manage firewalls, like ufw on debian-based systems and firewall-cmd on redhat systems, Iptables will help you understand what actually happens during filtering, mangling or routing a package. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html has a structured approach in explaining what happends when a package hits the firewall. Pay extra attention to Network Address Translation. Here is another nice HOWTO: https://netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html +

+

Virtual Private Networks and Tunneling

+

Please have a look at ./tunneling.html:tunneling.html +

+

Cheatsheets

+ +

Here are some good cheatsheets for commonly used tools +

+ + + + diff --git a/docs/resources.txt b/docs/resources.txt new file mode 100644 index 0000000..f7470b3 --- /dev/null +++ b/docs/resources.txt @@ -0,0 +1,40 @@ +Linux Resources +******** + +This page lists some useful resources for a more in depth understanding on specific subjects. Assumed is that you have a basic understanding of Linux and Networking. If not, you might to start with one of the followings books + + * http://linux-training.be - PDFs about the fundamentals, gives an overview of the most common tools and how to use them. PDFs contains some nice exercises. + * http://www.tldp.org - The Linux Documentation project. Look for the UNIX and Internet Fundamentals HOWTO. (Do you *really* know what happens when you turn on a PC?) + * https://netfilter.org/documentation/HOWTO/networking-concepts-HOWTO.html - Elementary HOWTO about Networking. + + +Networking +-------- +A good way to understand more about networking is two setup two computers: a server and a client. And the play around with the tools. The following tools and documentation are extremely useful. + +Netcat +~~~~~~ +Simple tool to open or connect to TCP or UDP ports and output data through these channels. Build and test proxies. Powerful for debugging. _Cryptcat_ is a similar tool, but with support for cryptography + +Sendip +~~~~~~ +Create and send IP, TCP or UDP packages. You are able to edit any value within these packages. + + +Iptables +~~~~~~~~ +Although there is more abstract software to manage firewalls, like *ufw* on debian-based systems and *firewall-cmd* on redhat systems, Iptables will help you understand what actually happens during filtering, mangling or routing a package. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html has a structured approach in explaining _what happends when a package hits the firewall_. Pay extra attention to Network Address Translation. Here is another nice HOWTO: https://netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html + + + +Virtual Private Networks and Tunneling +---- +Please have a look at + +Cheatsheets +------- + +Here are some good cheatsheets for commonly used tools + +* VI(M) - https://vim.rtorr.com +* diff --git a/docs/tinc.html b/docs/tinc.html new file mode 100644 index 0000000..10764b1 --- /dev/null +++ b/docs/tinc.html @@ -0,0 +1,354 @@ + + + + + + + + +

TINC gateway setup

+ +

Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org +Here I will show a tinc setup with an alpha (as a listening peer) and a beta (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way. +

+
+ +

Alpha peer

+ +

Create config files

+ +

/etc/tinc/gatewayvpn/tinc.conf + +

+        Name: alpha 
+        Device: /dev/net/tun
+
+ +

The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections. +

+

/etc/tinc/gatewayvpn/tinc-up + +

+        #!/bin/sh
+        ip link set $INTERFACE up
+        ip addr add  172.16.16.1/24 dev $INTERFACE      
+
+

This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like: +

+
+        $ ifconfig gatewayvpn
+        gatewayvpn   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00  
+        inet addr:172.16.16.1  P-t-P:172.16.16.1  Mask:255.255.255.0
+        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
+
+

We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha. +

+

/etc/tinc/gatewayvpn/tinc-down +

+
+        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
+ +

Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse. +

+

/etc/tinc/gatewayvpn/hosts/alpha +

+
+        Address = 1.2.3.4
+        Port = 7999
+        Subnet = 0.0.0.0/0 
+
+

This file should be send to all the other peers (only beta in this example). We create this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the whole internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc. +

+

Create private keys

+ +
+        $ root@alpha tincd -n gatewayvpn --generate-keys
+        Generating 2048 bits keys: ...........
+        Done
+        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]: 
+        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]: 
+
+

Generate public/private RSA keypair. Private key will be written to /etc/tinc/gatewayvpn/rsa-key.priv. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. /etc/tinc/gatewayvpn/hosts/alpha will look like this +

+
+        Address = 1.2.3.4
+        Port = 7999
+        Subnet = 0.0.0.0/0 
+
+        -----BEGIN RSA PUBLIC KEY-----
+        Blabla
+        -----END RSA PUBLIC KEY-----
+
+

Test your configuration

+ +

Now alpha is setup. We can test our configuration as follows: +

+
+        root@alpha:~$ tincd -n gatewayvpn --logfile /root/log
+        root@alpha:~$
+
+

Logfile should show the following output: +

+
+        root@alpha:~# cat /root/log
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul  5 2015 23:17:54) starting, debug level 0
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode)
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready
+
+

You should also be able to ping to the tunneling device: + +

+        root@alpha:~$ ping 172.16.16.1
+        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
+        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms
+        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms
+        ^C
+        --- 172.16.16.1 ping statistics ---
+        2 packets transmitted, 2 received, 0% packet loss, time 999ms
+        rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms
+
+

The tinc daemon is listening on our configured port 7999: +

+
+        root@alpha:~$ netstat -pnaut
+        tcp        0      0 0.0.0.0:7999            0.0.0.0:               LISTEN      9828 tincd         
+        udp        0      0 0.0.0.0:7999            0.0.0.0:                           9828 tincd
+
+

Beta peer

+ +

Create config files

+ +

/etc/tinc/gatewayvpn/tinc.conf + +

+        Name: beta 
+        Device: /dev/net/tun
+        ConnectTo: alpha
+
+

Beta will connect to alpha, for this connection beta will look in /etc/tinc/gatewayvpn/hosts/alpha and connect to this IP:PORT + +

/etc/tinc/gatewayvpn/tinc-up + +

+        #!/bin/sh
+        ip link set $INTERFACE up
+        ip addr add  172.16.16.2/24 dev $INTERFACE      
+
+

Beta will get assigned 172.16.16.2 +

+

/etc/tinc/gatewayvpn/tinc-down +

+
+        #!/bin/sh
+        ip addr del 172.16.16.2/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
+ + +

/etc/tinc/gatewayvpn/hosts/beta +

+
+        Subnet = 172.16.16.2/32
+        Port = 7999
+
+

We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network. +

+

Create private keys

+ +
+        tincd -n gatewayvpn --generate-keys
+        Generating 2048 bits keys: ...........
+        Done.
+        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]: 
+        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]:
+
+

So now you will also have created the private key file for beta. Public keys are written to files in the host directory. +*Note: don't forget to put /etc/tinc/gatewayvpn/hosts/beta on the alpha side and alpha on the beta side. +

+
+        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha .
+        alpha                                               100%  481     0.5KB/s   00:00    
+        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/
+        beta                                                100%  463     0.5KB/s   00:00    
+
+

Test your configuration

+ +

See alpha. +

+

Initial run

+ +

Now let's see if the configuration is correct and both peers' connections are accepted. +We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet. +

+

First start alpha: + +

+        root@alpha:~$
+        root@alpha:~$ tincd -n gatewayvpn --log-file /root/log
+
+

Then start beta: +

+
+        root@beta:~$
+        root@beta:~$ tincd -n gatewayvpn --log-file /root/log
+
+

Now test if you can ping! +

+
+        root@alpha:~# ping 172.16.16.2
+        PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data.
+        64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms
+        64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms
+        64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms
+
+        root@beta:~# ping 172.16.16.1
+        ping 172.16.16.1
+        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
+        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms
+        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms
+        64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms
+
+

Routing gateway

+ +

(Note: mostly copied from the tinc manual) +It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow. +

+

Theory

+

Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux: +

+
+        Destination     Gateway         Genmask         Flags   Metric  Ref     Use     Iface
+        192.168.1.0     0.0.0.0         255.255.255.0   U       0       0       0       eth0
+        0.0.0.0         192.168.1.1     0.0.0.0         UG      0       0       0       eth0
+
+

Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become: +

+
+        Kernel IP routing table
+        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
+        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
+        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+        0.0.0.0         172.16.16.1     0.0.0.0         UG    0      0        0 gatewayvpn
+
+

This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN. +

+

It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route: +

+
+        Kernel IP routing table
+        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
+        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
+        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+        128.0.0.0       172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
+        0.0.0.0         172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
+        0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
+
+

Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present. +

+

Scripts

+ +

To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files. +

+

/etc/tinc/gatewayvpn/tinc-up +

+
+        #!/bin/sh
+        VPN_GATEWAY=172.16.16.1
+        REMOTEADDRESS=1.2.3.4
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+
+        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route add $VPN_GATEWAY dev $INTERFACE
+        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+
+

/etc/tinc/gatewayvpn/tinc-down +

+
+        #!/bin/sh       
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=1.2.3.4
+
+        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route del $VPN_GATEWAY dev $INTERFACE
+        ip route del 0.0.0.0/1 dev $INTERFACE
+        ip route del 128.0.0.0/1 dev $INTERFACE
+
+

These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server. +

+

Setup firewall

+ +

Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. +

+
+        #!/bin/sh
+        # iptables config line to masquerade
+        
+        echo "Enabling IPv4 forwarding"
+        echo 1 >/proc/sys/net/ipv4/ip_forward
+        
+        echo "Appending Masquerade rule to iptables"
+        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
+
+

Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0. +

+

Test the gateway

+ +

Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. +

+

Troubleshooting help

+ +
    +
  • DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration +
+
+        root@beta:~$ cat /etc/resolv.conf       
+        # resolv.conf file
+        nameserver 127.0.1.0
+
+
    +
  • and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway + +
+
+        IP ROUTING TABLE
+        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
+
+
    +
  • A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 + +
  • Check your logfile while running tinc (i.e. you might forgot to create a key pair): +
+
+        2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file
+         `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory
+
+
    +
  • Overview of created files + +
+
+        root@alpha:~$ ls -R /etc/tinc/gatewayvpn
+        /etc/tinc/gatewayvpn:
+        hosts/  rsa-key.priv  tinc.conf  tinc-down  tinc-up
+        /etc/tinc/gatewayvpn/hosts:
+        alpha beta
+        
+        root@beta:~$ ls -R /etc/tinc/gatewayvpn
+        /etc/tinc/gatewayvpn:
+        hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
+        /etc/tinc/gatewayvpn/hosts:
+        alpha beta
+
+
    +
  • Use tcpdump or wireshark to analyze your network devices +
+ + + diff --git a/docs/tinc.txt b/docs/tinc.txt new file mode 100644 index 0000000..b76f45c --- /dev/null +++ b/docs/tinc.txt @@ -0,0 +1,328 @@ +TINC gateway setup +===== + +Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org +Here I will show a tinc setup with an *alpha* (as a listening peer) and a *beta* (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way. + +------------- + +Alpha peer +********** + +Create config files ++++++++ + +_/etc/tinc/gatewayvpn/tinc.conf_ + + Name: alpha + Device: /dev/net/tun + +The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections. + +_/etc/tinc/gatewayvpn/tinc-up_ + + #!/bin/sh + ip link set $INTERFACE up + ip addr add 172.16.16.1/24 dev $INTERFACE + +This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like: + + $ ifconfig gatewayvpn + gatewayvpn Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00 + inet addr:172.16.16.1 P-t-P:172.16.16.1 Mask:255.255.255.0 + UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 + +We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha. + +_/etc/tinc/gatewayvpn/tinc-down_ + + #!/bin/sh + ip addr del 172.16.16.1/24 dev $INTERFACE + ip link set $INTERFACE down + +Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse. + + +_/etc/tinc/gatewayvpn/hosts/alpha_ + + Address = 1.2.3.4 + Port = 7999 + Subnet = 0.0.0.0/0 + +This file should be send to all the other peers (only beta in this example). We _create_ this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the *whole* internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc. + +Create private keys ++++++++++ + + + $ root@alpha tincd -n gatewayvpn --generate-keys + Generating 2048 bits keys: ........... + Done + Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]: + Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]: + +Generate public/private RSA keypair. Private key will be written to _/etc/tinc/gatewayvpn/rsa-key.priv_. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. _/etc/tinc/gatewayvpn/hosts/alpha_ will look like this + + Address = 1.2.3.4 + Port = 7999 + Subnet = 0.0.0.0/0 + + -----BEGIN RSA PUBLIC KEY----- + Blabla + -----END RSA PUBLIC KEY----- + +Test your configuration ++++++++++ + +Now alpha is setup. We can test our configuration as follows: + + root@alpha:~$ tincd -n gatewayvpn --logfile /root/log + root@alpha:~$ + +Logfile should show the following output: + + root@alpha:~# cat /root/log + 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul 5 2015 23:17:54) starting, debug level 0 + 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode) + 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready + +You should also be able to ping to the tunneling device: + + root@alpha:~$ ping 172.16.16.1 + PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data. + 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms + 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms + ^C + --- 172.16.16.1 ping statistics --- + 2 packets transmitted, 2 received, 0% packet loss, time 999ms + rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms + +The tinc daemon is listening on our configured port 7999: + + root@alpha:~$ netstat -pnaut + tcp 0 0 0.0.0.0:7999 0.0.0.0: LISTEN 9828 tincd + udp 0 0 0.0.0.0:7999 0.0.0.0: 9828 tincd + + +Beta peer +******** + + +Create config files ++++++++ + +_/etc/tinc/gatewayvpn/tinc.conf_ + + Name: beta + Device: /dev/net/tun + ConnectTo: alpha + +Beta will connect to alpha, for this connection beta will look in _/etc/tinc/gatewayvpn/hosts/alpha_ and connect to this IP:PORT + +_/etc/tinc/gatewayvpn/tinc-up_ + + #!/bin/sh + ip link set $INTERFACE up + ip addr add 172.16.16.2/24 dev $INTERFACE + +Beta will get assigned 172.16.16.2 + +_/etc/tinc/gatewayvpn/tinc-down_ + + #!/bin/sh + ip addr del 172.16.16.2/24 dev $INTERFACE + ip link set $INTERFACE down + + +_/etc/tinc/gatewayvpn/hosts/beta_ + + Subnet = 172.16.16.2/32 + Port = 7999 + +We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network. + +Create private keys ++++++++++ + + tincd -n gatewayvpn --generate-keys + Generating 2048 bits keys: ........... + Done. + Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]: + Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]: + +So now you will also have created the private key file for beta. Public keys are written to files in the host directory. +*Note: don't forget to put _/etc/tinc/gatewayvpn/hosts/beta_ on the alpha side and alpha on the beta side. + + root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha . + alpha 100% 481 0.5KB/s 00:00 + root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/ + beta 100% 463 0.5KB/s 00:00 + +Test your configuration ++++++++++++ + +See alpha. + + +Initial run +********* + +Now let's see if the configuration is correct and both peers' connections are accepted. +We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet. + +First start alpha: + + root@alpha:~$ + root@alpha:~$ tincd -n gatewayvpn --log-file /root/log + +Then start beta: + + root@beta:~$ + root@beta:~$ tincd -n gatewayvpn --log-file /root/log + + +Now test if you can ping! + + root@alpha:~# ping 172.16.16.2 + PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data. + 64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms + 64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms + 64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms + + root@beta:~# ping 172.16.16.1 + ping 172.16.16.1 + PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data. + 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms + 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms + 64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms + + +Routing gateway +********** + +(Note: mostly copied from the tinc manual) +It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow. + + +Theory ++++++++ +Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux: + + Destination Gateway Genmask Flags Metric Ref Use Iface + 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 + 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 + +Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become: + + Kernel IP routing table + Destination Gateway Genmask Flags Metric Ref Use Iface + 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn + 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 + 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 + 0.0.0.0 172.16.16.1 0.0.0.0 UG 0 0 0 gatewayvpn + +This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN. + +It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route: + + Kernel IP routing table + Destination Gateway Genmask Flags Metric Ref Use Iface + 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn + 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 + 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 + 128.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn + 0.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn + 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 + +Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present. + +Scripts ++++++++++ + +To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files. + +_/etc/tinc/gatewayvpn/tinc-up_ + + #!/bin/sh + VPN_GATEWAY=172.16.16.1 + REMOTEADDRESS=1.2.3.4 + ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` + + ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY + ip route add $VPN_GATEWAY dev $INTERFACE + ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE + ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE + +_/etc/tinc/gatewayvpn/tinc-down_ + + #!/bin/sh + ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` + REMOTEADDRESS=1.2.3.4 + + ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY + ip route del $VPN_GATEWAY dev $INTERFACE + ip route del 0.0.0.0/1 dev $INTERFACE + ip route del 128.0.0.0/1 dev $INTERFACE + +These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server. + + +Setup firewall ++++++++++ + +Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. + + #!/bin/sh + # iptables config line to masquerade + + echo "Enabling IPv4 forwarding" + echo 1 >/proc/sys/net/ipv4/ip_forward + + echo "Appending Masquerade rule to iptables" + iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE + +Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0. + + +Test the gateway ++++++++++++ + +Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. + + +Troubleshooting help +******* + +* DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration + + root@beta:~$ cat /etc/resolv.conf + # resolv.conf file + nameserver 127.0.1.0 + +* and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway + + IP ROUTING TABLE + link-local * 255.255.0.0 U 1000 0 0 wlp7s0 + +* A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 + +* Check your logfile while running tinc (i.e. you might forgot to create a key pair): + + 2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file + `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory + +* Overview of created files + + root@alpha:~$ ls -R /etc/tinc/gatewayvpn + /etc/tinc/gatewayvpn: + hosts/ rsa-key.priv tinc.conf tinc-down tinc-up + /etc/tinc/gatewayvpn/hosts: + alpha beta + + root@beta:~$ ls -R /etc/tinc/gatewayvpn + /etc/tinc/gatewayvpn: + hosts/ rsa-key.priv tinc.conf tinc-down tinc-up + /etc/tinc/gatewayvpn/hosts: + alpha beta + +* Use tcpdump or wireshark to analyze your network devices diff --git a/docs/tmp.html b/docs/tmp.html new file mode 100644 index 0000000..bc9f070 --- /dev/null +++ b/docs/tmp.html @@ -0,0 +1,51 @@ + + + + + + + + +

robinkrens.nl - On VPN and bypassing a firewall

+ +

Let's say you want to connect to a company network and access all the computers in this network (behind a firewall) One way to do this is to setup a Virtual Private Network. Although you are not physically in the same building, all the other computers will think you are, hence Virtual Private Network. After you connect to this VPN, you will be assigned a local IP (i.e. 10.0.0.5) and communicate directly to all computers in this range directly. +

+

In case of bypassing a Internet Service Provider (ISP) or Great Firewall (GFW), you want to access all the websites that are normally not accessible. There are many ways to this. Software written to setup up VPNs are especially useful for this. Add some additional routing and you bypassed the firewall. Look at the following illustration +

+

[Pity you] -------- [ISP/GFW: No youtube!]-------- [YouTube.com] +

+

The ISP or GFW has some firewall rules to block certains IPs or to detect certain suspicious traffic. But let's say you have access to a server that isn't behind the firewall. Would you be able to redirect your Youtube request through this server and then send it to your PC? Well, yes. +

+

[Pity you] -------- [ISP/GFW]----------[Not blocked server]--------[Youtube.com] +

+

Hmm, still pity you. Although your server can access YouTube.com, if it sends traffic back it still has to send to the ISP/GFW. So unless the firewall rules +

+

The setup is as follows +

+

Some alternative software to bypass a huge firewall (as in your ISP or a country). A list of sample configuration. +

+

Basic Tunneling

+

Basic tunneling, or IP in IP. Basically we connect to networks that normally would not be able to talk to each other (directy) +This setup is straightforward like this: +

+

ExtIP 1.2.3.4 ---- ( INTERNET ) ---- ExtIP 5.6.7.8 +

+
+        Local: 10.0.1.0/24 ----- [TUNNEL] ----- 10.0.2.0/24
+        ExtIP: 1.2.3.4                          5.6.7.8
+                |                                   |
+                |                                   |   
+                |-------- ( INTERNET ) -------------|
+
+

This version of tunneling has been supported since the early kernel versions of linux (<1.3). +

+

No encrytion here. No IPV6 or anything other fancy. +

+
+        ip tuntap add tun0 mode tun
+        ip addr add 192.168.1.2 dev tun0
+        ip add route ...
+
+ + diff --git a/docs/tmp.txt b/docs/tmp.txt new file mode 100644 index 0000000..b76f4eb --- /dev/null +++ b/docs/tmp.txt @@ -0,0 +1,49 @@ + +robinkrens.nl - On VPN and bypassing a firewall +******** + +Let's say you want to connect to a company network and access all the computers in this network (behind a firewall) One way to do this is to setup a Virtual Private Network. Although you are not physically in the same building, all the other computers will think you are, hence *Virtual* Private Network. After you connect to this VPN, you will be assigned a local IP (i.e. 10.0.0.5) and communicate directly to all computers in this range directly. + +In case of bypassing a Internet Service Provider (ISP) or Great Firewall (GFW), you want to access all the websites that are normally not accessible. There are many ways to this. Software written to setup up VPNs are especially useful for this. Add some additional routing and you bypassed the firewall. Look at the following illustration + + + [Pity you] -------- [ISP/GFW: No youtube!]-------- [YouTube.com] + + +The ISP or GFW has some firewall rules to block certains IPs or to detect certain *suspicious* traffic. But let's say you have access to a server that isn't behind the firewall. Would you be able to redirect your Youtube request through this server and then send it to your PC? Well, yes. + + [Pity you] -------- [ISP/GFW]----------[Not blocked server]--------[Youtube.com] + +Hmm, still pity you. Although your server can access YouTube.com, if it sends traffic back it still has to send to the ISP/GFW. So unless the firewall rules + + + +The setup is as follows + + +Some alternative software to bypass a huge firewall (as in your ISP or a country). A list of sample configuration. + + +Basic Tunneling +--------------- +Basic tunneling, or IP in IP. Basically we connect to networks that normally would not be able to talk to each other (directy) +This setup is straightforward like this: + + ExtIP 1.2.3.4 ---- ( INTERNET ) ---- ExtIP 5.6.7.8 + + Local: 10.0.1.0/24 ----- [TUNNEL] ----- 10.0.2.0/24 + ExtIP: 1.2.3.4 5.6.7.8 + | | + | | + |-------- ( INTERNET ) -------------| + + +This version of tunneling has been supported since the early kernel versions of linux (<1.3). + +No encrytion here. No IPV6 or anything other fancy. + + ip tuntap add tun0 mode tun + ip addr add 192.168.1.2 dev tun0 + ip add route ... + + diff --git a/docs/tunneling.html b/docs/tunneling.html new file mode 100644 index 0000000..ab0dbfc --- /dev/null +++ b/docs/tunneling.html @@ -0,0 +1,21 @@ + + + + + + + + +

VPN and tunneling

+ +

This page lists tutorials and sample code. +

+
    +
  • Tinc setup: A simple setup with tinc as a gateway +
  • Fastd setup: Similar setup as the above with fastd. +
  • Strongswan: A mobike setup (not published). +
+ + + diff --git a/docs/tunneling.txt b/docs/tunneling.txt new file mode 100644 index 0000000..b52d4ef --- /dev/null +++ b/docs/tunneling.txt @@ -0,0 +1,9 @@ +VPN and tunneling +******** + +This page lists tutorials and sample code. + +* : A simple setup with tinc as a gateway +* : Similar setup as the above with fastd. +* Strongswan: A mobike setup (not published). + diff --git a/fastd.html b/fastd.html deleted file mode 100644 index ba4184c..0000000 --- a/fastd.html +++ /dev/null @@ -1,276 +0,0 @@ - - - - - - - - -

robinkrens.nl - Redirecting traffic using FastD

- -

FastD is a VPN daemon that has many features of OpenVPN and Tinc and is optimized for small code size and small number of dependencies. Fastd became popular on small devices like routers. In this tutorial we will configure a listening peer (alpha) and a connecting peer (anyremote). On a side note, with fastD you can setup mesh networks (n:n), as opposed to classical clients server networks (1:n). This configuration can be seen as a simple (1:1) setup between the listening alpha peer and our connecting client anyremote. All traffic from anyremote is redirected to alpha, making alpha the default gateway. This configuration has a lot of similarities with the tinc tutorial (that you can find here: http://www.robinkrens.nl/tutorials/tinc.html). Documentation and manual pages of fastd can be found here http://fastd.readthedocs.io -

-
- -

Alpha peer

- -

To run the daemon you only need one configuration file. You can place it in fastd's defualt directory /etc/fastd/fastd.conf. Here we show a standard configuration of fastd.conf with some minor changes: -

-
-        # Log warnings and errors to stderr
-        log level warn;
-
-        # Log everything to syslog
-        log to syslog level debug;
-
-        # tunnel mode (default is tap). 
-        # We use tunneling mode, since we are dealing with routing
-        mode tun;
-
-        # Set the interface name
-        # you can use any name you like
-        # this is the name to configure your interface wit
-        interface "vpngateway";
-
-        # encryption method to use
-        falls back to null if salsa is not chosen.
-        method "salsa2012+umac";
-        method "null";
-
-        # Bind to a fixed port, IPv4 only
-        # If your remote ip is 1.2.3.4, make sure 1.2.3.4:10000 is accesible
-        bind 0.0.0.0:10000;
-
-        # Secret key generated by `fastd --generate-key`
-        # --generate-key outputs a file with a secret and public key
-        # secret key goes in here. Public keys is distributed amongst other peers
-        # read about PKI infrastructures if you don't know about this.
-        secret "supersecretkey";
-
-        # (see MTU selection documentation)
-        # base MTU is 1500 and you want to use TUN mode over IPv4 with any 
-        # crypto method: Choose 1500 - 52 = 1448 bytes.
-        mtu 1448;
-
-        # on up: shell script to configure the tun interface on daemon start
-        on up "./interface-up";
-
-        # on down: shell script when daemon is terminated
-        on down "./interface-down"; 
-
-        # Include peers from the directory 'peers'
-        # anyremote is a peer trying to connect to alpha
-        include peer "peers/anyremote";
-
-

Keys can be generate by running --generate-key (written to stdout): - -

-        root@alpha:~$ fastd --generate-key > keys
-        root@alpha:~$ cat keys
-        2018-04-30 19:25:57 +0800 --- Info: Reading 32 bytes from /dev/random...
-        Secret: 5035de5b4ea448b74e9a373765207095057a9485fd9dca5fadb9c1b86347bd75
-        Public: 8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42
-
-

The secret key needs to be added to the above fastd.conf file. The public needs to be spread amongst peers (as we explain later). -on up "./interface-up" will run a simple shell script and configures our network interface vpngateway (make sure this script is executable). -This is our interface.up script: We create a virtual IP: 172.16.16.1. -

-
-        #!/bin/bash
-        ip link set $INTERFACE up
-        ip addr add 172.16.16.1/24 dev $INTERFACE
-
-

If we terminate fastd, we run a similar script as defined in interface-down - -

-        #!/bin/sh
-        ip addr del 172.16.16.1/24 dev $INTERFACE
-        ip link set $INTERFACE down
-
-

We will create the peer/anyremote file after we finished configuring anyremote and its public key -

-

Anyremote peer

- -

Similar to alpha, we create /etc/fastd/fastd.conf. Since we only need to connect to alpha we don't need to bind to a fixed port. -

-
-        # log arnings and errors to stderr
-        log level warn;
-
-        # Log everything to syslog
-        log to syslog level debug;
-
-        # tunnel mode (default is tap)
-        mode tun;
-
-        # Set the interface name
-        interface "vpngateway";
-
-        # Support salsa2012+umac and null methods, prefer salsa2012+umac
-        method "salsa2012+umac";
-        method "null";
-
-        # Secret key generated by `fastd --generate-key`
-        secret "supersecretkey";
-
-        # (see MTU selection documentation)
-        mtu 1448;
-
-        # daemon start
-        on up "./interface-up";
-
-        # daemon terminated
-        on down "./interface-down";
-
-        # if a connection is established set up the gateway
-        on establish "./set-gateway";
-
-        # if the connection is lost restore the default gateway
-        on disestablish "./restore-gateway";
-
-        # Include peers from the directory 'peers'
-        include peer "peers/alpha";
-
-

For anyremote we also need to generate a key pair and replace the "supersecretkey" with the secret key value. The public key will be given to alpha (explained in a little while) -

-
-        root@anyremote~ $ fastd --generate-keys > anyremote-keypair
-        root@anyremote~ $ cat anyremote-keypair
-        2018-05-01 19:48:49 +0800 --- Info: Reading 32 bytes from /dev/random...
-        Secret: c0a611e0d4f3075b45cf172d3221c8427008e2c6f541b5b6adda0368cb79f271
-        Public: 2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9
-
- -

on up and on down are similar to alpha (except the ip address). interface-up: - -

-        #!/bin/bash
-        ip link set $INTERFACE up
-        ip addr add 172.16.16.2/24 dev $INTERFACE
-
- -

interface-down: -

-
-        #!/bin/sh
-        ip addr del 172.16.16.1/24 dev $INTERFACE
-        ip link set $INTERFACE down
-
-

We need to include some information about how to connect to alpha. We define in a file (/etc/fastd/peers/alpha): -

-
-        root@anyremote:/etc/fastd/peers/ $ cat alpha
-        # alpha 
-        key "8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42";
-        remote 1.2.3.4:10000;
-
-

key means the public key we just created with --generate-keys the alpha section. Here we add a remote ip to which anyremote tries to connect to. Make sure port numbers are the same. -Don't forget to also add our our just created public key to our alpha server: -

-
-        root@alpha:/etc/fastd/peers/ $ cat anyremote
-        # anyremote
-        key "2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9";
-
-

This will allow alpha to accept connections from anyremote. Note: you don't need to specify a remote address, this will make it more dynamic and you can connect with anyremote from anywhere as long as you have the private key. -

-

After these steps you should be able to run both alpha and anyremote. You can run the daemon as follows: - -

-        root@alpha:~ $ fastd -c /etc/fastd/fastd.conf &
-        root@anyremote:~ $ fastd -c /etc/fastd/fastd.conf &
-
-

The interface vpngateway should show up and you should be able to ping to both hosts us. - -

Now, in our config file of anyremote we see two additionals values: on establish and on disestablish. Once the connection is (dis)established, fastd will execute these scripts. This brings us two the last step: setting the default gateway of anyremote to point to alpha -

-

Alpha as gateway for anyremote

- -

Have a look at the tinc tutorial (gateway section) about the theory of routing and gateways. -We add the following scripts in /etc/fastd of anyremote if a connection with alpha is established: (set-gateway) - -

-        #!/bin/bash
-        #ip link set $INTERFACE up
-        #ip addr add 172.16.16.2/24 dev $INTERFACE
-
-        VPN_GATEWAY=172.16.16.1
-        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
-        REMOTEADDRESS=1.2.3.4
-
-        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
-        ip route add $VPN_GATEWAY dev $INTERFACE
-        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
-        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
-
- -

And, similar, if the connecting is lost: (restore-gateway): -

-
-        #!/bin/sh
-        #ip addr del 172.16.16.2/24 dev $INTERFACE
-        #ip link set $INTERFACE down
-
-        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
-        REMOTEADDRESS=45.76.159.1
-
-        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
-        ip route del $VPN_GATEWAY dev $INTERFACE
-        ip route del 0.0.0.0/1 dev $INTERFACE
-        ip route del 128.0.0.0/1 dev $INTERFACE
-
-

Setup firewall

- -

Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded anyremote) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. -

-
-        #!/bin/sh
-        # iptables config line to masquerade
-        
-        echo "Enabling IPv4 forwarding"
-        echo 1 >/proc/sys/net/ipv4/ip_forward
-        
-        echo "Appending Masquerade rule to iptables"
-        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
-
-

I use iptables to masquerade the (-s) source address on the (-o) interface eth0. -

-

Test the gateway

- -

Restart the daemon on alpha and anyremote. Use route -n to see check your routing tables. Ping both 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. -

-

Troubleshooting help

- -
    -
  • DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration -
-
-        root@anyremote:~$ cat /etc/resolv.conf  
-        # resolv.conf file
-        nameserver 127.0.1.0
-
-
    -
  • and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway - -
-
-        IP ROUTING TABLE
-        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
-
-
    -
  • A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 - -
  • Fastd's log to /var/log/syslog You can define these locations in your fast.conf file. You can also change the log level, in case you need more information: -
-
-        --log-level error|warn|info|verbose|debug|debug2
-        Sets the stderr log level; default is info if no alternative log
-        destination is configured.
-
-
    -
  • Use tcpdump or wireshark to analyze your network devices -
- - - diff --git a/fastd.txt b/fastd.txt deleted file mode 100644 index 6db9bd6..0000000 --- a/fastd.txt +++ /dev/null @@ -1,248 +0,0 @@ -robinkrens.nl - Redirecting traffic using FastD -===== - -FastD is a VPN daemon that has many features of OpenVPN and Tinc and is optimized for small code size and small number of dependencies. Fastd became popular on small devices like routers. In this tutorial we will configure a listening peer (alpha) and a connecting peer (anyremote). On a side note, with fastD you can setup mesh networks (n:n), as opposed to classical clients server networks (1:n). This configuration can be seen as a simple (1:1) setup between the listening *alpha* peer and our connecting client *anyremote*. All traffic from anyremote is redirected to alpha, making alpha the default gateway. This configuration has a lot of similarities with the tinc tutorial (that you can find here: http://www.robinkrens.nl/tutorials/tinc.html). Documentation and manual pages of fastd can be found here http://fastd.readthedocs.io - --------------- - -Alpha peer -********** - -To run the daemon you only need one configuration file. You can place it in fastd's defualt directory _/etc/fastd/fastd.conf_. Here we show a standard configuration of _fastd.conf_ with some minor changes: - - # Log warnings and errors to stderr - log level warn; - - # Log everything to syslog - log to syslog level debug; - - # tunnel mode (default is tap). - # We use tunneling mode, since we are dealing with routing - mode tun; - - # Set the interface name - # you can use any name you like - # this is the name to configure your interface wit - interface "vpngateway"; - - # encryption method to use - falls back to null if salsa is not chosen. - method "salsa2012+umac"; - method "null"; - - # Bind to a fixed port, IPv4 only - # If your remote ip is 1.2.3.4, make sure 1.2.3.4:10000 is accesible - bind 0.0.0.0:10000; - - # Secret key generated by `fastd --generate-key` - # --generate-key outputs a file with a secret and public key - # secret key goes in here. Public keys is distributed amongst other peers - # read about PKI infrastructures if you don't know about this. - secret "supersecretkey"; - - # (see MTU selection documentation) - # base MTU is 1500 and you want to use TUN mode over IPv4 with any - # crypto method: Choose 1500 - 52 = 1448 bytes. - mtu 1448; - - # on up: shell script to configure the tun interface on daemon start - on up "./interface-up"; - - # on down: shell script when daemon is terminated - on down "./interface-down"; - - # Include peers from the directory 'peers' - # anyremote is a peer trying to connect to alpha - include peer "peers/anyremote"; - -Keys can be generate by running --generate-key (written to stdout): - - root@alpha:~$ fastd --generate-key > keys - root@alpha:~$ cat keys - 2018-04-30 19:25:57 +0800 --- Info: Reading 32 bytes from /dev/random... - Secret: 5035de5b4ea448b74e9a373765207095057a9485fd9dca5fadb9c1b86347bd75 - Public: 8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42 - -The secret key needs to be added to the above _fastd.conf_ file. The public needs to be spread amongst peers (as we explain later). -on up "./interface-up" will run a simple shell script and configures our network interface vpngateway (make sure this script is executable). -This is our _interface.up_ script: We create a virtual IP: 172.16.16.1. - - #!/bin/bash - ip link set $INTERFACE up - ip addr add 172.16.16.1/24 dev $INTERFACE - -If we terminate fastd, we run a similar script as defined in interface-down - - #!/bin/sh - ip addr del 172.16.16.1/24 dev $INTERFACE - ip link set $INTERFACE down - -We will create the _peer/anyremote_ file after we finished configuring anyremote and its public key - -Anyremote peer -********* - -Similar to alpha, we create _/etc/fastd/fastd.conf_. Since we only need to connect to alpha we don't need to bind to a fixed port. - - # log arnings and errors to stderr - log level warn; - - # Log everything to syslog - log to syslog level debug; - - # tunnel mode (default is tap) - mode tun; - - # Set the interface name - interface "vpngateway"; - - # Support salsa2012+umac and null methods, prefer salsa2012+umac - method "salsa2012+umac"; - method "null"; - - # Secret key generated by `fastd --generate-key` - secret "supersecretkey"; - - # (see MTU selection documentation) - mtu 1448; - - # daemon start - on up "./interface-up"; - - # daemon terminated - on down "./interface-down"; - - # if a connection is established set up the gateway - on establish "./set-gateway"; - - # if the connection is lost restore the default gateway - on disestablish "./restore-gateway"; - - # Include peers from the directory 'peers' - include peer "peers/alpha"; - -For anyremote we also need to generate a key pair and replace the "supersecretkey" with the secret key value. The public key will be given to alpha (explained in a little while) - - root@anyremote~ $ fastd --generate-keys > anyremote-keypair - root@anyremote~ $ cat anyremote-keypair - 2018-05-01 19:48:49 +0800 --- Info: Reading 32 bytes from /dev/random... - Secret: c0a611e0d4f3075b45cf172d3221c8427008e2c6f541b5b6adda0368cb79f271 - Public: 2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9 - - -*on up* and *on down* are similar to alpha (except the ip address). interface-up: - - #!/bin/bash - ip link set $INTERFACE up - ip addr add 172.16.16.2/24 dev $INTERFACE - -interface-down: - - #!/bin/sh - ip addr del 172.16.16.1/24 dev $INTERFACE - ip link set $INTERFACE down - -We need to include some information about how to connect to alpha. We define in a file (_/etc/fastd/peers/alpha_): - - root@anyremote:/etc/fastd/peers/ $ cat alpha - # alpha - key "8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42"; - remote 1.2.3.4:10000; - -*key* means the public key we just created with --generate-keys the alpha section. Here we add a remote ip to which anyremote tries to connect to. Make sure port numbers are the same. -Don't forget to also add our our just created public key to our alpha server: - - root@alpha:/etc/fastd/peers/ $ cat anyremote - # anyremote - key "2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9"; - -This will allow alpha to accept connections from anyremote. Note: you don't need to specify a remote address, this will make it more dynamic and you can connect with anyremote from anywhere as long as you have the private key. - -After these steps you should be able to run both alpha and anyremote. You can run the daemon as follows: - - root@alpha:~ $ fastd -c /etc/fastd/fastd.conf & - root@anyremote:~ $ fastd -c /etc/fastd/fastd.conf & - -The interface *vpngateway* should show up and you should be able to ping to both hosts us. - -Now, in our config file of anyremote we see two additionals values: *on establish* and *on disestablish*. Once the connection is (dis)established, fastd will execute these scripts. This brings us two the last step: setting the default gateway of anyremote to point to alpha - -Alpha as gateway for anyremote -********** - -Have a look at the tinc tutorial (gateway section) about the theory of routing and gateways. -We add the following scripts in _/etc/fastd_ of anyremote if a connection with alpha is established: (set-gateway) - - #!/bin/bash - #ip link set $INTERFACE up - #ip addr add 172.16.16.2/24 dev $INTERFACE - - VPN_GATEWAY=172.16.16.1 - ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` - REMOTEADDRESS=1.2.3.4 - - ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY - ip route add $VPN_GATEWAY dev $INTERFACE - ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE - ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE - -And, similar, if the connecting is lost: (restore-gateway): - - #!/bin/sh - #ip addr del 172.16.16.2/24 dev $INTERFACE - #ip link set $INTERFACE down - - ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` - REMOTEADDRESS=45.76.159.1 - - ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY - ip route del $VPN_GATEWAY dev $INTERFACE - ip route del 0.0.0.0/1 dev $INTERFACE - ip route del 128.0.0.0/1 dev $INTERFACE - - -Setup firewall -******* - -Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded anyremote) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. - - #!/bin/sh - # iptables config line to masquerade - - echo "Enabling IPv4 forwarding" - echo 1 >/proc/sys/net/ipv4/ip_forward - - echo "Appending Masquerade rule to iptables" - iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE - -I use iptables to masquerade the (-s) source address on the (-o) interface eth0. - - -Test the gateway -******** - -Restart the daemon on alpha and anyremote. Use route -n to see check your routing tables. Ping both 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. - -Troubleshooting help -******* - -* DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration - - root@anyremote:~$ cat /etc/resolv.conf - # resolv.conf file - nameserver 127.0.1.0 - -* and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway - - IP ROUTING TABLE - link-local * 255.255.0.0 U 1000 0 0 wlp7s0 - -* A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 - -* Fastd's log to _/var/log/syslog_ You can define these locations in your fast.conf file. You can also change the log level, in case you need more information: - - --log-level error|warn|info|verbose|debug|debug2 - Sets the stderr log level; default is info if no alternative log - destination is configured. - -* Use tcpdump or wireshark to analyze your network devices diff --git a/ikev2-nat-rw.html b/ikev2-nat-rw.html deleted file mode 100644 index e90cce7..0000000 --- a/ikev2-nat-rw.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - - - -

robinkrens.nl -- Strongswan road warrior setup with Virtual IPs

- -

strongSwan is an IPsec solution providing encryption and authentication to servers and clients. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. In this HOWTO, I explain how to setup up a secure connection to your server. In this setup your host will be the gateway, you might have other servers behind this gateway you can then reach securily. In this particular setup we use public key authentication between a roadwarrior and your server. Roadwarriors is the term Strongswan uses for laptops or other mobile devices that connect from a remote location to your network. More on this particular setup can be found here: https://www.strongswan.org/testing/testresults/ikev2/mobike-virtual-ip-nat/index.html -Note: some distributions use ipsec as command, others use strongswan -

-
- -

Setup a PKI infrastructure

- -

To set up a public key infrastructure (PKI), we first need to create a self-signed Certificate Authority (CA). We use StrongSwan's built-in command `ipsec pki`. Later on, our CA will issue end-entity certificates. Generate a private key for the CA: -

-

ipsec pki --gen > caKey.der -

-

Now self-sign a CA certificate using the generated key. Adjust the distinguished name (DN) to your needs, it will be included in all issued certificates. -

-

ipsec pki --self --in caKey.der --dn "C=USA, O= , CN=Host CA" --ca > caCert.der -

-

Generate a private key for your host and use your CA to issue a certificate. -

-
-        ipsec pki --gen > hostKey.der`
-        ipsec pki --pub --in hostKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O=  CN=host" > hostCert.der` --san your_IP
-
-

Now place the created files in the following directories of your Host: -

-
-        /etc/ipsec.d/private/hostKey.der
-        /etc/ipsec.d/certs/hostCert.der
-        /etc/ipsec.d/cacerts/caCert.der
-
-

Similar, we can generate a private key and issue a certiciate for our client. -

-
-        ipsec pki --gen > clientKey.der
-        ipsec pki --pub --in clientKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= , CN=client" > clientCert.der
-
-

On your client you will need the client key and certificate as well as your CA certificate. To make it a bit more convenient, you can wrap these files in one .p12 file using the following command: -

-
-        openssl rsa -inform der -outform pem -in peerKey.der -out peerKey.pem
-        openssl pkcs12 -in clientCert.pem -inkey clientKey.pem -certfile caCert.pem -export -out client.p12`
-
-

Configure strongSwan

- -

Your /etc/ipsec.conf configuration file on your host should contain the following: -

-

config setup -

-
-        conn %default
-                ikelifetime=60m
-                keylife=20m
-                rekeymargin=3m
-                keyingtries=1
-                keyexchange=ikev2
-
-        conn virtualip
-                leftsubnet=0.0.0.0/0
-                #leftid=alpha
-                #leftauth=pubkey
-                #rightauth=pubkey
-                #leftsendcert=always
-                leftfirewall=yes
-                right=%any
-                rightdns=8.8.8.8,8.8.4.4
-                rightsourceip=172.16.16.0/24
-                auto=add
-
-

Edit your /etc/ipsec.secrets and add the following line: -

-

: RSA hostKey.der -

-

Please note that both sides of the colon ':' need a white-space! -

-

Allow forwarding and configure firewall

- -

In order to forward traffic to hosts behind the gateway the following -option has to be enabled on your host: -

-
-        sysctl net.ipv4.ip_forward=1
-        sysctl net.ipv6.conf.all.forwarding=1
-
-

This can be added to /etc/sysctl.conf to enable it permanently. -

-

Makes sure the ports accept traffic and masquerading: -

-        sudo iptables -A INPUT -p udp -dport 500/4500 -j ACCEPT
-        sudo iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE
-
- - diff --git a/ikev2-nat-rw.txt b/ikev2-nat-rw.txt deleted file mode 100644 index 9f12244..0000000 --- a/ikev2-nat-rw.txt +++ /dev/null @@ -1,87 +0,0 @@ -robinkrens.nl -- Strongswan road warrior setup with Virtual IPs -======= - -strongSwan is an IPsec solution providing encryption and authentication to servers and clients. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. In this HOWTO, I explain how to setup up a secure connection to your server. In this setup your host will be the *gateway*, you might have other servers behind this gateway you can then reach securily. In this particular setup we use public key authentication between a *roadwarrior* and your server. Roadwarriors is the term Strongswan uses for laptops or other mobile devices that connect from a remote location to your network. More on this particular setup can be found here: https://www.strongswan.org/testing/testresults/ikev2/mobike-virtual-ip-nat/index.html -Note: some distributions use *ipsec* as command, others use *strongswan* - ----------- - -Setup a PKI infrastructure -********** - -To set up a public key infrastructure (PKI), we first need to create a self-signed Certificate Authority (CA). We use StrongSwan's built-in command `ipsec pki`. Later on, our CA will issue end-entity certificates. Generate a private key for the CA: - - ipsec pki --gen > caKey.der - -Now self-sign a CA certificate using the generated key. Adjust the distinguished name (DN) to your needs, it will be included in all issued certificates. - - ipsec pki --self --in caKey.der --dn "C=USA, O= , CN=Host CA" --ca > caCert.der - -Generate a private key for your host and use your CA to issue a certificate. - - ipsec pki --gen > hostKey.der` - ipsec pki --pub --in hostKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= CN=host" > hostCert.der` --san your_IP - -Now place the created files in the following directories of your Host: - - /etc/ipsec.d/private/hostKey.der - /etc/ipsec.d/certs/hostCert.der - /etc/ipsec.d/cacerts/caCert.der - -Similar, we can generate a private key and issue a certiciate for our client. - - ipsec pki --gen > clientKey.der - ipsec pki --pub --in clientKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= , CN=client" > clientCert.der - -On your client you will need the client key and certificate as well as your CA certificate. To make it a bit more convenient, you can wrap these files in one .p12 file using the following command: - - openssl rsa -inform der -outform pem -in peerKey.der -out peerKey.pem - openssl pkcs12 -in clientCert.pem -inkey clientKey.pem -certfile caCert.pem -export -out client.p12` - -Configure strongSwan -********** - -Your /etc/ipsec.conf configuration file on your host should contain the following: - - config setup - - conn %default - ikelifetime=60m - keylife=20m - rekeymargin=3m - keyingtries=1 - keyexchange=ikev2 - - conn virtualip - leftsubnet=0.0.0.0/0 - #leftid=alpha - #leftauth=pubkey - #rightauth=pubkey - #leftsendcert=always - leftfirewall=yes - right=%any - rightdns=8.8.8.8,8.8.4.4 - rightsourceip=172.16.16.0/24 - auto=add - -Edit your /etc/ipsec.secrets and add the following line: - - : RSA hostKey.der - -Please note that both sides of the colon ':' need a white-space! - -Allow forwarding and configure firewall -************ - -In order to forward traffic to hosts behind the gateway the following -option has to be enabled on your host: - - sysctl net.ipv4.ip_forward=1 - sysctl net.ipv6.conf.all.forwarding=1 - -This can be added to /etc/sysctl.conf to enable it permanently. - -Makes sure the ports accept traffic and masquerading: - sudo iptables -A INPUT -p udp -dport 500/4500 -j ACCEPT - sudo iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE - diff --git a/index.html b/index.html index c0255b2..a9f357f 100644 --- a/index.html +++ b/index.html @@ -2,64 +2,83 @@ - robinkrens.nl + woggleWEB -

robinkrens.nl

- -

This website is mostly used for email and personal articles / programming projects. - Please scan the tag below to contact me. - +

robinkrens.nl

+ +
+▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
+	 mr_woggle 
+			proudly
+					presents:
+                                                               
+                             ▀▀█          ▄     ▄ ▄▄▄▄▄▄ ▄▄▄▄▄ 
+▄     ▄  ▄▄▄    ▄▄▄▄   ▄▄▄▄    █     ▄▄▄  █  █  █ █      █    █
+▀▄ ▄ ▄▀ █▀ ▀█  █▀ ▀█  █▀ ▀█    █    █▀  █ ▀ █▀█ █ █▄▄▄▄▄ █▄▄▄▄▀
+ █▄█▄█  █   █  █   █  █   █    █    █▀▀▀▀  ██ ██▀ █      █    █
+  █ █   ▀█▄█▀  ▀█▄▀█  ▀█▄▀█    ▀▄▄  ▀█▄▄▀  █   █  █▄▄▄▄▄ █▄▄▄▄▀
+                ▄  █   ▄  █                                    
+                 ▀▀     ▀▀                                     
+
+ + +

Hi! I'm mr_woggle, but some people call me Rob. I like simple things. Simple code, simple servers, etc. This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me.

- - 
- ___________________________
-< Wish you another lovely day! >
- ------------------------------
-        \   ^__^
-         \  (oo)\_______
-            (__)\       )\/\
-                ||----w |
-                ||     ||
-
- -

My Playground

+ +

Docs

-
  • My own github server -
    • +

    Servers and Playgrounds

    -
  • Other servers -
    • + -
  • My travel map +

    Personal

    +

    Contact

    contact erweima

    -
    - © robinkrens.nl -- Peace! +
    +▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
+
    + diff --git a/index.md b/index.md deleted file mode 100644 index fc4cf6b..0000000 --- a/index.md +++ /dev/null @@ -1,19 +0,0 @@ -# robinkrens.nl - -This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me. - -## My Playground - -* [Tunneling, repackaging and VPN](./tunneling.html) -* Wechat development / 微信小程序 -* [Chinese learning](./chinese.html) -* [Linux resources](./resources.html) -* [Rob's github](http://45.76.159.1/gitweb/) -* Other servers -* My travel map -* Experiments - -## Contact -![contact erweima](files/contact.png) ---- -© robinkrens.nl -- Peace! diff --git a/old/chinese.html b/old/chinese.html new file mode 100644 index 0000000..134e4ed --- /dev/null +++ b/old/chinese.html @@ -0,0 +1,58 @@ + + + +Chinese Learning + + + + +

    Chinese Learning

    + +

    Here are some resources for the more advanced learners. Instead of using books, you might want to pick a podcast, tv show or radio program that Chinese listen to themselves. Still have to parse the Chinese correctly... +

    +
    + +

    原来æ~&hibar;è¿TM样！- http://www.ximalaya.com/7200706/album/246622/ +Podcast about some interesting scientific (useless?) facts. It's a two host show, with basically the girl 装ç–&hibar;卖傻. Recordings are quite long, but well eloborated and not too technical. +

    +

    Difficulty: 3 +

    +

    上班脱口秀 - http://www.ximalaya.com/6534662/album/336435/ +Short broadcast about current events. Supposed to be funny, but that might be a matter of taste. Great way to stay up to date. Pace is fast, a lot of slang. +

    +

    Difficulty: 4 +

    +

    新闻今日谈 https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm +Analysis of political events. A guest speaker is invited and does usually discuss two news items in 20 minutes. Hosts are from mainland, taiwan and hongkong, might have some dialect issues. +

    +

    Difficulty: 4.5 +

    +

    圓桌派
    +The continuation of 锵锵三人行, that for some reason dissapeared. Four people discussing current events, pace is slow, use a lot of trendy words. Has subtitles in Chinese +https://www.youtube.com/playlist?list=PLvXvMUSstINcZQzOoZifThjUr-rNp3ENm +

    +

    Diffuculty: 3.5 +

    +

    凤凰财知道
    +Although the name says finance, it basically discusses anyting that is even remotely related to money. Short, but quite intense. You can find subtitles somewhere in cyberspace if you search on the title. +

    +

    http://diantai.ifeng.com/#!/category/1/92395 +

    +

    Difficulty: 5 +

    +

    一èTMŽä¸€å¸­è°ˆ
    +Discussion panel with many speakers (including the audience). An excited and composed host. Often has non-native speakers on the show. About societal issues, often a 'Yes' front and 'No' front. Quite long, but has subtitles. + https://www.youtube.com/playlist?list=PLvXvMUSstINfmrcFH0LFBBYW9OcEuA3yx +

    +

    Difficulty 4.5 +

    +

    公开è&hibar;¾
    +These are some free courses you can download (most are on university level) +谈判学 - series of classes about negotiation +物流学 - series of classes about transportation +

    +

    Difficulty: 4

    + + + diff --git a/old/fastd.html b/old/fastd.html new file mode 100644 index 0000000..ba4184c --- /dev/null +++ b/old/fastd.html @@ -0,0 +1,276 @@ + + + + + + + + +

    robinkrens.nl - Redirecting traffic using FastD

    + +

    FastD is a VPN daemon that has many features of OpenVPN and Tinc and is optimized for small code size and small number of dependencies. Fastd became popular on small devices like routers. In this tutorial we will configure a listening peer (alpha) and a connecting peer (anyremote). On a side note, with fastD you can setup mesh networks (n:n), as opposed to classical clients server networks (1:n). This configuration can be seen as a simple (1:1) setup between the listening alpha peer and our connecting client anyremote. All traffic from anyremote is redirected to alpha, making alpha the default gateway. This configuration has a lot of similarities with the tinc tutorial (that you can find here: http://www.robinkrens.nl/tutorials/tinc.html). Documentation and manual pages of fastd can be found here http://fastd.readthedocs.io +

    +
    + +

    Alpha peer

    + +

    To run the daemon you only need one configuration file. You can place it in fastd's defualt directory /etc/fastd/fastd.conf. Here we show a standard configuration of fastd.conf with some minor changes: +

    +
    +        # Log warnings and errors to stderr
+        log level warn;
+
+        # Log everything to syslog
+        log to syslog level debug;
+
+        # tunnel mode (default is tap). 
+        # We use tunneling mode, since we are dealing with routing
+        mode tun;
+
+        # Set the interface name
+        # you can use any name you like
+        # this is the name to configure your interface wit
+        interface "vpngateway";
+
+        # encryption method to use
+        falls back to null if salsa is not chosen.
+        method "salsa2012+umac";
+        method "null";
+
+        # Bind to a fixed port, IPv4 only
+        # If your remote ip is 1.2.3.4, make sure 1.2.3.4:10000 is accesible
+        bind 0.0.0.0:10000;
+
+        # Secret key generated by `fastd --generate-key`
+        # --generate-key outputs a file with a secret and public key
+        # secret key goes in here. Public keys is distributed amongst other peers
+        # read about PKI infrastructures if you don't know about this.
+        secret "supersecretkey";
+
+        # (see MTU selection documentation)
+        # base MTU is 1500 and you want to use TUN mode over IPv4 with any 
+        # crypto method: Choose 1500 - 52 = 1448 bytes.
+        mtu 1448;
+
+        # on up: shell script to configure the tun interface on daemon start
+        on up "./interface-up";
+
+        # on down: shell script when daemon is terminated
+        on down "./interface-down"; 
+
+        # Include peers from the directory 'peers'
+        # anyremote is a peer trying to connect to alpha
+        include peer "peers/anyremote";
+
    +

    Keys can be generate by running --generate-key (written to stdout): + +

    +        root@alpha:~$ fastd --generate-key > keys
+        root@alpha:~$ cat keys
+        2018-04-30 19:25:57 +0800 --- Info: Reading 32 bytes from /dev/random...
+        Secret: 5035de5b4ea448b74e9a373765207095057a9485fd9dca5fadb9c1b86347bd75
+        Public: 8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42
+
    +

    The secret key needs to be added to the above fastd.conf file. The public needs to be spread amongst peers (as we explain later). +on up "./interface-up" will run a simple shell script and configures our network interface vpngateway (make sure this script is executable). +This is our interface.up script: We create a virtual IP: 172.16.16.1. +

    +
    +        #!/bin/bash
+        ip link set $INTERFACE up
+        ip addr add 172.16.16.1/24 dev $INTERFACE
+
    +

    If we terminate fastd, we run a similar script as defined in interface-down + +

    +        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
    +

    We will create the peer/anyremote file after we finished configuring anyremote and its public key +

    +

    Anyremote peer

    + +

    Similar to alpha, we create /etc/fastd/fastd.conf. Since we only need to connect to alpha we don't need to bind to a fixed port. +

    +
    +        # log arnings and errors to stderr
+        log level warn;
+
+        # Log everything to syslog
+        log to syslog level debug;
+
+        # tunnel mode (default is tap)
+        mode tun;
+
+        # Set the interface name
+        interface "vpngateway";
+
+        # Support salsa2012+umac and null methods, prefer salsa2012+umac
+        method "salsa2012+umac";
+        method "null";
+
+        # Secret key generated by `fastd --generate-key`
+        secret "supersecretkey";
+
+        # (see MTU selection documentation)
+        mtu 1448;
+
+        # daemon start
+        on up "./interface-up";
+
+        # daemon terminated
+        on down "./interface-down";
+
+        # if a connection is established set up the gateway
+        on establish "./set-gateway";
+
+        # if the connection is lost restore the default gateway
+        on disestablish "./restore-gateway";
+
+        # Include peers from the directory 'peers'
+        include peer "peers/alpha";
+
    +

    For anyremote we also need to generate a key pair and replace the "supersecretkey" with the secret key value. The public key will be given to alpha (explained in a little while) +

    +
    +        root@anyremote~ $ fastd --generate-keys > anyremote-keypair
+        root@anyremote~ $ cat anyremote-keypair
+        2018-05-01 19:48:49 +0800 --- Info: Reading 32 bytes from /dev/random...
+        Secret: c0a611e0d4f3075b45cf172d3221c8427008e2c6f541b5b6adda0368cb79f271
+        Public: 2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9
+
    + +

    on up and on down are similar to alpha (except the ip address). interface-up: + +

    +        #!/bin/bash
+        ip link set $INTERFACE up
+        ip addr add 172.16.16.2/24 dev $INTERFACE
+
    + +

    interface-down: +

    +
    +        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
    +

    We need to include some information about how to connect to alpha. We define in a file (/etc/fastd/peers/alpha): +

    +
    +        root@anyremote:/etc/fastd/peers/ $ cat alpha
+        # alpha 
+        key "8cb5e8d70d34f52716b6c4de518af2edfd6794e68ef1b3f0608cf05dd6a2ef42";
+        remote 1.2.3.4:10000;
+
    +

    key means the public key we just created with --generate-keys the alpha section. Here we add a remote ip to which anyremote tries to connect to. Make sure port numbers are the same. +Don't forget to also add our our just created public key to our alpha server: +

    +
    +        root@alpha:/etc/fastd/peers/ $ cat anyremote
+        # anyremote
+        key "2598c5d7e72f171731658ce35734ff7599e1840367422e1a9c5943c327ab5ea9";
+
    +

    This will allow alpha to accept connections from anyremote. Note: you don't need to specify a remote address, this will make it more dynamic and you can connect with anyremote from anywhere as long as you have the private key. +

    +

    After these steps you should be able to run both alpha and anyremote. You can run the daemon as follows: + +

    +        root@alpha:~ $ fastd -c /etc/fastd/fastd.conf &
+        root@anyremote:~ $ fastd -c /etc/fastd/fastd.conf &
+
    +

    The interface vpngateway should show up and you should be able to ping to both hosts us. + +

    Now, in our config file of anyremote we see two additionals values: on establish and on disestablish. Once the connection is (dis)established, fastd will execute these scripts. This brings us two the last step: setting the default gateway of anyremote to point to alpha +

    +

    Alpha as gateway for anyremote

    + +

    Have a look at the tinc tutorial (gateway section) about the theory of routing and gateways. +We add the following scripts in /etc/fastd of anyremote if a connection with alpha is established: (set-gateway) + +

    +        #!/bin/bash
+        #ip link set $INTERFACE up
+        #ip addr add 172.16.16.2/24 dev $INTERFACE
+
+        VPN_GATEWAY=172.16.16.1
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=1.2.3.4
+
+        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route add $VPN_GATEWAY dev $INTERFACE
+        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+
    + +

    And, similar, if the connecting is lost: (restore-gateway): +

    +
    +        #!/bin/sh
+        #ip addr del 172.16.16.2/24 dev $INTERFACE
+        #ip link set $INTERFACE down
+
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=45.76.159.1
+
+        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route del $VPN_GATEWAY dev $INTERFACE
+        ip route del 0.0.0.0/1 dev $INTERFACE
+        ip route del 128.0.0.0/1 dev $INTERFACE
+
    +

    Setup firewall

    + +

    Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded anyremote) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. +

    +
    +        #!/bin/sh
+        # iptables config line to masquerade
+        
+        echo "Enabling IPv4 forwarding"
+        echo 1 >/proc/sys/net/ipv4/ip_forward
+        
+        echo "Appending Masquerade rule to iptables"
+        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
+
    +

    I use iptables to masquerade the (-s) source address on the (-o) interface eth0. +

    +

    Test the gateway

    + +

    Restart the daemon on alpha and anyremote. Use route -n to see check your routing tables. Ping both 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. +

    +

    Troubleshooting help

    + +
      +
    • DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration +
    +
    +        root@anyremote:~$ cat /etc/resolv.conf  
+        # resolv.conf file
+        nameserver 127.0.1.0
+
    +
      +
    • and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway + +
    +
    +        IP ROUTING TABLE
+        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
+
    +
      +
    • A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 + +
    • Fastd's log to /var/log/syslog You can define these locations in your fast.conf file. You can also change the log level, in case you need more information: +
    +
    +        --log-level error|warn|info|verbose|debug|debug2
+        Sets the stderr log level; default is info if no alternative log
+        destination is configured.
+
    +
      +
    • Use tcpdump or wireshark to analyze your network devices +
    + + + diff --git a/old/ikev2-nat-rw.html b/old/ikev2-nat-rw.html new file mode 100644 index 0000000..e90cce7 --- /dev/null +++ b/old/ikev2-nat-rw.html @@ -0,0 +1,101 @@ + + + + + + + + +

    robinkrens.nl -- Strongswan road warrior setup with Virtual IPs

    + +

    strongSwan is an IPsec solution providing encryption and authentication to servers and clients. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. In this HOWTO, I explain how to setup up a secure connection to your server. In this setup your host will be the gateway, you might have other servers behind this gateway you can then reach securily. In this particular setup we use public key authentication between a roadwarrior and your server. Roadwarriors is the term Strongswan uses for laptops or other mobile devices that connect from a remote location to your network. More on this particular setup can be found here: https://www.strongswan.org/testing/testresults/ikev2/mobike-virtual-ip-nat/index.html +Note: some distributions use ipsec as command, others use strongswan +

    +
    + +

    Setup a PKI infrastructure

    + +

    To set up a public key infrastructure (PKI), we first need to create a self-signed Certificate Authority (CA). We use StrongSwan's built-in command `ipsec pki`. Later on, our CA will issue end-entity certificates. Generate a private key for the CA: +

    +

    ipsec pki --gen > caKey.der +

    +

    Now self-sign a CA certificate using the generated key. Adjust the distinguished name (DN) to your needs, it will be included in all issued certificates. +

    +

    ipsec pki --self --in caKey.der --dn "C=USA, O= , CN=Host CA" --ca > caCert.der +

    +

    Generate a private key for your host and use your CA to issue a certificate. +

    +
    +        ipsec pki --gen > hostKey.der`
+        ipsec pki --pub --in hostKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O=  CN=host" > hostCert.der` --san your_IP
+
    +

    Now place the created files in the following directories of your Host: +

    +
    +        /etc/ipsec.d/private/hostKey.der
+        /etc/ipsec.d/certs/hostCert.der
+        /etc/ipsec.d/cacerts/caCert.der
+
    +

    Similar, we can generate a private key and issue a certiciate for our client. +

    +
    +        ipsec pki --gen > clientKey.der
+        ipsec pki --pub --in clientKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=USA, O= , CN=client" > clientCert.der
+
    +

    On your client you will need the client key and certificate as well as your CA certificate. To make it a bit more convenient, you can wrap these files in one .p12 file using the following command: +

    +
    +        openssl rsa -inform der -outform pem -in peerKey.der -out peerKey.pem
+        openssl pkcs12 -in clientCert.pem -inkey clientKey.pem -certfile caCert.pem -export -out client.p12`
+
    +

    Configure strongSwan

    + +

    Your /etc/ipsec.conf configuration file on your host should contain the following: +

    +

    config setup +

    +
    +        conn %default
+                ikelifetime=60m
+                keylife=20m
+                rekeymargin=3m
+                keyingtries=1
+                keyexchange=ikev2
+
+        conn virtualip
+                leftsubnet=0.0.0.0/0
+                #leftid=alpha
+                #leftauth=pubkey
+                #rightauth=pubkey
+                #leftsendcert=always
+                leftfirewall=yes
+                right=%any
+                rightdns=8.8.8.8,8.8.4.4
+                rightsourceip=172.16.16.0/24
+                auto=add
+
    +

    Edit your /etc/ipsec.secrets and add the following line: +

    +

    : RSA hostKey.der +

    +

    Please note that both sides of the colon ':' need a white-space! +

    +

    Allow forwarding and configure firewall

    + +

    In order to forward traffic to hosts behind the gateway the following +option has to be enabled on your host: +

    +
    +        sysctl net.ipv4.ip_forward=1
+        sysctl net.ipv6.conf.all.forwarding=1
+
    +

    This can be added to /etc/sysctl.conf to enable it permanently. +

    +

    Makes sure the ports accept traffic and masquerading: +

    +        sudo iptables -A INPUT -p udp -dport 500/4500 -j ACCEPT
+        sudo iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE
+
    + + diff --git a/old/index.html b/old/index.html new file mode 100644 index 0000000..4be4e4f --- /dev/null +++ b/old/index.html @@ -0,0 +1,84 @@ + + + + + woggleWEB + + + + + +

    robinkrens.nl

    + +
    +▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
+	 mr_woggle 
+			proudly
+					presents:
+                                                               
+                             ▀▀█          ▄     ▄ ▄▄▄▄▄▄ ▄▄▄▄▄ 
+▄     ▄  ▄▄▄    ▄▄▄▄   ▄▄▄▄    █     ▄▄▄  █  █  █ █      █    █
+▀▄ ▄ ▄▀ █▀ ▀█  █▀ ▀█  █▀ ▀█    █    █▀  █ ▀ █▀█ █ █▄▄▄▄▄ █▄▄▄▄▀
+ █▄█▄█  █   █  █   █  █   █    █    █▀▀▀▀  ██ ██▀ █      █    █
+  █ █   ▀█▄█▀  ▀█▄▀█  ▀█▄▀█    ▀▄▄  ▀█▄▄▀  █   █  █▄▄▄▄▄ █▄▄▄▄▀
+                ▄  █   ▄  █                                    
+                 ▀▀     ▀▀                                     
+
    + + +

    Hi! I'm mr_woggle, but some people call me Rob. I like simple things. Simple code, simple servers, etc. This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me. +

    + +

    Docs

    + + + +

    Servers and Playgrounds

    + + + +

    Personal

    + +

    Contact

    +

    + contact erweima +

    + +
    +▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
+
    + + + + diff --git a/old/index.md b/old/index.md new file mode 100644 index 0000000..fc4cf6b --- /dev/null +++ b/old/index.md @@ -0,0 +1,19 @@ +# robinkrens.nl + +This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me. + +## My Playground + +* [Tunneling, repackaging and VPN](./tunneling.html) +* Wechat development / 微信小程序 +* [Chinese learning](./chinese.html) +* [Linux resources](./resources.html) +* [Rob's github](http://45.76.159.1/gitweb/) +* Other servers +* My travel map +* Experiments + +## Contact +![contact erweima](files/contact.png) +--- +© robinkrens.nl -- Peace! diff --git a/old/resources.html b/old/resources.html new file mode 100644 index 0000000..be86432 --- /dev/null +++ b/old/resources.html @@ -0,0 +1,44 @@ + + + + + + + + +

    robinkrens.nl - Linux Resources

    + +

    This page lists some useful resources for a more in depth understanding on specific subjects. Assumed is that you have a basic understanding of Linux and Networking. If not, you might to start with one of the followings books +

    + +

    Networking

    +

    A good way to understand more about networking is two setup two computers: a server and a client. And the play around with the tools. The following tools and documentation are extremely useful. +

    +

    Netcat

    +

    Simple tool to open or connect to TCP or UDP ports and output data through these channels. Build and test proxies. Powerful for debugging. Cryptcat is a similar tool, but with support for cryptography +

    +

    Sendip

    +

    Create and send IP, TCP or UDP packages. You are able to edit any value within these packages. +

    +

    Iptables

    +

    Although there is more abstract software to manage firewalls, like ufw on debian-based systems and firewall-cmd on redhat systems, Iptables will help you understand what actually happens during filtering, mangling or routing a package. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html has a structured approach in explaining what happends when a package hits the firewall. Pay extra attention to Network Address Translation. Here is another nice HOWTO: https://netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html +

    +

    Virtual Private Networks and Tunneling

    +

    Please have a look at ./tunneling.html:tunneling.html +

    +

    Cheatsheets

    + +

    Here are some good cheatsheets for commonly used tools +

    + + + + diff --git a/old/tinc.html b/old/tinc.html new file mode 100644 index 0000000..a478b86 --- /dev/null +++ b/old/tinc.html @@ -0,0 +1,354 @@ + + + + + + + + +

    robinkrens.nl - Redirecting traffic and TINC

    + +

    Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org +Here I will show a tinc setup with an alpha (as a listening peer) and a beta (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way. +

    +
    + +

    Alpha peer

    + +

    Create config files

    + +

    /etc/tinc/gatewayvpn/tinc.conf + +

    +        Name: alpha 
+        Device: /dev/net/tun
+
    + +

    The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections. +

    +

    /etc/tinc/gatewayvpn/tinc-up + +

    +        #!/bin/sh
+        ip link set $INTERFACE up
+        ip addr add  172.16.16.1/24 dev $INTERFACE      
+
    +

    This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like: +

    +
    +        $ ifconfig gatewayvpn
+        gatewayvpn   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00  
+        inet addr:172.16.16.1  P-t-P:172.16.16.1  Mask:255.255.255.0
+        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
+
    +

    We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha. +

    +

    /etc/tinc/gatewayvpn/tinc-down +

    +
    +        #!/bin/sh
+        ip addr del 172.16.16.1/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
    + +

    Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse. +

    +

    /etc/tinc/gatewayvpn/hosts/alpha +

    +
    +        Address = 1.2.3.4
+        Port = 7999
+        Subnet = 0.0.0.0/0 
+
    +

    This file should be send to all the other peers (only beta in this example). We create this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the whole internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc. +

    +

    Create private keys

    + +
    +        $ root@alpha tincd -n gatewayvpn --generate-keys
+        Generating 2048 bits keys: ...........
+        Done
+        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]: 
+        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]: 
+
    +

    Generate public/private RSA keypair. Private key will be written to /etc/tinc/gatewayvpn/rsa-key.priv. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. /etc/tinc/gatewayvpn/hosts/alpha will look like this +

    +
    +        Address = 1.2.3.4
+        Port = 7999
+        Subnet = 0.0.0.0/0 
+
+        -----BEGIN RSA PUBLIC KEY-----
+        Blabla
+        -----END RSA PUBLIC KEY-----
+
    +

    Test your configuration

    + +

    Now alpha is setup. We can test our configuration as follows: +

    +
    +        root@alpha:~$ tincd -n gatewayvpn --logfile /root/log
+        root@alpha:~$
+
    +

    Logfile should show the following output: +

    +
    +        root@alpha:~# cat /root/log
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul  5 2015 23:17:54) starting, debug level 0
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode)
+        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready
+
    +

    You should also be able to ping to the tunneling device: + +

    +        root@alpha:~$ ping 172.16.16.1
+        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
+        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms
+        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms
+        ^C
+        --- 172.16.16.1 ping statistics ---
+        2 packets transmitted, 2 received, 0% packet loss, time 999ms
+        rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms
+
    +

    The tinc daemon is listening on our configured port 7999: +

    +
    +        root@alpha:~$ netstat -pnaut
+        tcp        0      0 0.0.0.0:7999            0.0.0.0:               LISTEN      9828 tincd         
+        udp        0      0 0.0.0.0:7999            0.0.0.0:                           9828 tincd
+
    +

    Beta peer

    + +

    Create config files

    + +

    /etc/tinc/gatewayvpn/tinc.conf + +

    +        Name: beta 
+        Device: /dev/net/tun
+        ConnectTo: alpha
+
    +

    Beta will connect to alpha, for this connection beta will look in /etc/tinc/gatewayvpn/hosts/alpha and connect to this IP:PORT + +

    /etc/tinc/gatewayvpn/tinc-up + +

    +        #!/bin/sh
+        ip link set $INTERFACE up
+        ip addr add  172.16.16.2/24 dev $INTERFACE      
+
    +

    Beta will get assigned 172.16.16.2 +

    +

    /etc/tinc/gatewayvpn/tinc-down +

    +
    +        #!/bin/sh
+        ip addr del 172.16.16.2/24 dev $INTERFACE
+        ip link set $INTERFACE down
+
    + + +

    /etc/tinc/gatewayvpn/hosts/beta +

    +
    +        Subnet = 172.16.16.2/32
+        Port = 7999
+
    +

    We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network. +

    +

    Create private keys

    + +
    +        tincd -n gatewayvpn --generate-keys
+        Generating 2048 bits keys: ...........
+        Done.
+        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]: 
+        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]:
+
    +

    So now you will also have created the private key file for beta. Public keys are written to files in the host directory. +*Note: don't forget to put /etc/tinc/gatewayvpn/hosts/beta on the alpha side and alpha on the beta side. +

    +
    +        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha .
+        alpha                                               100%  481     0.5KB/s   00:00    
+        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/
+        beta                                                100%  463     0.5KB/s   00:00    
+
    +

    Test your configuration

    + +

    See alpha. +

    +

    Initial run

    + +

    Now let's see if the configuration is correct and both peers' connections are accepted. +We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet. +

    +

    First start alpha: + +

    +        root@alpha:~$
+        root@alpha:~$ tincd -n gatewayvpn --log-file /root/log
+
    +

    Then start beta: +

    +
    +        root@beta:~$
+        root@beta:~$ tincd -n gatewayvpn --log-file /root/log
+
    +

    Now test if you can ping! +

    +
    +        root@alpha:~# ping 172.16.16.2
+        PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data.
+        64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms
+        64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms
+        64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms
+
+        root@beta:~# ping 172.16.16.1
+        ping 172.16.16.1
+        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
+        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms
+        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms
+        64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms
+
    +

    Routing gateway

    + +

    (Note: mostly copied from the tinc manual) +It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow. +

    +

    Theory

    +

    Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux: +

    +
    +        Destination     Gateway         Genmask         Flags   Metric  Ref     Use     Iface
+        192.168.1.0     0.0.0.0         255.255.255.0   U       0       0       0       eth0
+        0.0.0.0         192.168.1.1     0.0.0.0         UG      0       0       0       eth0
+
    +

    Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become: +

    +
    +        Kernel IP routing table
+        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
+        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
+        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+        0.0.0.0         172.16.16.1     0.0.0.0         UG    0      0        0 gatewayvpn
+
    +

    This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN. +

    +

    It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route: +

    +
    +        Kernel IP routing table
+        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
+        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
+        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+        128.0.0.0       172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
+        0.0.0.0         172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
+        0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
+
    +

    Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present. +

    +

    Scripts

    + +

    To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files. +

    +

    /etc/tinc/gatewayvpn/tinc-up +

    +
    +        #!/bin/sh
+        VPN_GATEWAY=172.16.16.1
+        REMOTEADDRESS=1.2.3.4
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+
+        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route add $VPN_GATEWAY dev $INTERFACE
+        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+
    +

    /etc/tinc/gatewayvpn/tinc-down +

    +
    +        #!/bin/sh       
+        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
+        REMOTEADDRESS=1.2.3.4
+
+        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
+        ip route del $VPN_GATEWAY dev $INTERFACE
+        ip route del 0.0.0.0/1 dev $INTERFACE
+        ip route del 128.0.0.0/1 dev $INTERFACE
+
    +

    These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server. +

    +

    Setup firewall

    + +

    Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. +

    +
    +        #!/bin/sh
+        # iptables config line to masquerade
+        
+        echo "Enabling IPv4 forwarding"
+        echo 1 >/proc/sys/net/ipv4/ip_forward
+        
+        echo "Appending Masquerade rule to iptables"
+        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
+
    +

    Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0. +

    +

    Test the gateway

    + +

    Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. +

    +

    Troubleshooting help

    + +
      +
    • DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration +
    +
    +        root@beta:~$ cat /etc/resolv.conf       
+        # resolv.conf file
+        nameserver 127.0.1.0
+
    +
      +
    • and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway + +
    +
    +        IP ROUTING TABLE
+        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
+
    +
      +
    • A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 + +
    • Check your logfile while running tinc (i.e. you might forgot to create a key pair): +
    +
    +        2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file
+         `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory
+
    +
      +
    • Overview of created files + +
    +
    +        root@alpha:~$ ls -R /etc/tinc/gatewayvpn
+        /etc/tinc/gatewayvpn:
+        hosts/  rsa-key.priv  tinc.conf  tinc-down  tinc-up
+        /etc/tinc/gatewayvpn/hosts:
+        alpha beta
+        
+        root@beta:~$ ls -R /etc/tinc/gatewayvpn
+        /etc/tinc/gatewayvpn:
+        hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
+        /etc/tinc/gatewayvpn/hosts:
+        alpha beta
+
    +
      +
    • Use tcpdump or wireshark to analyze your network devices +
    + + + diff --git a/old/tunneling.html b/old/tunneling.html new file mode 100644 index 0000000..ac68a7a --- /dev/null +++ b/old/tunneling.html @@ -0,0 +1,21 @@ + + + + + + + + +

    robinkrens.nl - Tunneling, repackaging and VPN

    + +

    This page lists tutorials and sample code. +

    + + + + diff --git a/resources.html b/resources.html deleted file mode 100644 index be86432..0000000 --- a/resources.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - - - -

    robinkrens.nl - Linux Resources

    - -

    This page lists some useful resources for a more in depth understanding on specific subjects. Assumed is that you have a basic understanding of Linux and Networking. If not, you might to start with one of the followings books -

    - -

    Networking

    -

    A good way to understand more about networking is two setup two computers: a server and a client. And the play around with the tools. The following tools and documentation are extremely useful. -

    -

    Netcat

    -

    Simple tool to open or connect to TCP or UDP ports and output data through these channels. Build and test proxies. Powerful for debugging. Cryptcat is a similar tool, but with support for cryptography -

    -

    Sendip

    -

    Create and send IP, TCP or UDP packages. You are able to edit any value within these packages. -

    -

    Iptables

    -

    Although there is more abstract software to manage firewalls, like ufw on debian-based systems and firewall-cmd on redhat systems, Iptables will help you understand what actually happens during filtering, mangling or routing a package. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html has a structured approach in explaining what happends when a package hits the firewall. Pay extra attention to Network Address Translation. Here is another nice HOWTO: https://netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html -

    -

    Virtual Private Networks and Tunneling

    -

    Please have a look at ./tunneling.html:tunneling.html -

    -

    Cheatsheets

    - -

    Here are some good cheatsheets for commonly used tools -

    - - - - diff --git a/resources.txt b/resources.txt deleted file mode 100644 index 3b577b5..0000000 --- a/resources.txt +++ /dev/null @@ -1,40 +0,0 @@ -robinkrens.nl - Linux Resources -******** - -This page lists some useful resources for a more in depth understanding on specific subjects. Assumed is that you have a basic understanding of Linux and Networking. If not, you might to start with one of the followings books - - * http://linux-training.be - PDFs about the fundamentals, gives an overview of the most common tools and how to use them. PDFs contains some nice exercises. - * http://www.tldp.org - The Linux Documentation project. Look for the UNIX and Internet Fundamentals HOWTO. (Do you *really* know what happens when you turn on a PC?) - * https://netfilter.org/documentation/HOWTO/networking-concepts-HOWTO.html - Elementary HOWTO about Networking. - - -Networking --------- -A good way to understand more about networking is two setup two computers: a server and a client. And the play around with the tools. The following tools and documentation are extremely useful. - -Netcat -~~~~~~ -Simple tool to open or connect to TCP or UDP ports and output data through these channels. Build and test proxies. Powerful for debugging. _Cryptcat_ is a similar tool, but with support for cryptography - -Sendip -~~~~~~ -Create and send IP, TCP or UDP packages. You are able to edit any value within these packages. - - -Iptables -~~~~~~~~ -Although there is more abstract software to manage firewalls, like *ufw* on debian-based systems and *firewall-cmd* on redhat systems, Iptables will help you understand what actually happens during filtering, mangling or routing a package. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html has a structured approach in explaining _what happends when a package hits the firewall_. Pay extra attention to Network Address Translation. Here is another nice HOWTO: https://netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html - - - -Virtual Private Networks and Tunneling ----- -Please have a look at - -Cheatsheets -------- - -Here are some good cheatsheets for commonly used tools - -* VI(M) - https://vim.rtorr.com -* diff --git a/tinc.html b/tinc.html deleted file mode 100644 index a478b86..0000000 --- a/tinc.html +++ /dev/null @@ -1,354 +0,0 @@ - - - - - - - - -

    robinkrens.nl - Redirecting traffic and TINC

    - -

    Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org -Here I will show a tinc setup with an alpha (as a listening peer) and a beta (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way. -

    -
    - -

    Alpha peer

    - -

    Create config files

    - -

    /etc/tinc/gatewayvpn/tinc.conf - -

    -        Name: alpha 
-        Device: /dev/net/tun
-
    - -

    The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections. -

    -

    /etc/tinc/gatewayvpn/tinc-up - -

    -        #!/bin/sh
-        ip link set $INTERFACE up
-        ip addr add  172.16.16.1/24 dev $INTERFACE      
-
    -

    This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like: -

    -
    -        $ ifconfig gatewayvpn
-        gatewayvpn   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00  
-        inet addr:172.16.16.1  P-t-P:172.16.16.1  Mask:255.255.255.0
-        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
-
    -

    We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha. -

    -

    /etc/tinc/gatewayvpn/tinc-down -

    -
    -        #!/bin/sh
-        ip addr del 172.16.16.1/24 dev $INTERFACE
-        ip link set $INTERFACE down
-
    - -

    Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse. -

    -

    /etc/tinc/gatewayvpn/hosts/alpha -

    -
    -        Address = 1.2.3.4
-        Port = 7999
-        Subnet = 0.0.0.0/0 
-
    -

    This file should be send to all the other peers (only beta in this example). We create this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the whole internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc. -

    -

    Create private keys

    - -
    -        $ root@alpha tincd -n gatewayvpn --generate-keys
-        Generating 2048 bits keys: ...........
-        Done
-        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]: 
-        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]: 
-
    -

    Generate public/private RSA keypair. Private key will be written to /etc/tinc/gatewayvpn/rsa-key.priv. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. /etc/tinc/gatewayvpn/hosts/alpha will look like this -

    -
    -        Address = 1.2.3.4
-        Port = 7999
-        Subnet = 0.0.0.0/0 
-
-        -----BEGIN RSA PUBLIC KEY-----
-        Blabla
-        -----END RSA PUBLIC KEY-----
-
    -

    Test your configuration

    - -

    Now alpha is setup. We can test our configuration as follows: -

    -
    -        root@alpha:~$ tincd -n gatewayvpn --logfile /root/log
-        root@alpha:~$
-
    -

    Logfile should show the following output: -

    -
    -        root@alpha:~# cat /root/log
-        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul  5 2015 23:17:54) starting, debug level 0
-        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode)
-        2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready
-
    -

    You should also be able to ping to the tunneling device: - -

    -        root@alpha:~$ ping 172.16.16.1
-        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
-        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms
-        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms
-        ^C
-        --- 172.16.16.1 ping statistics ---
-        2 packets transmitted, 2 received, 0% packet loss, time 999ms
-        rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms
-
    -

    The tinc daemon is listening on our configured port 7999: -

    -
    -        root@alpha:~$ netstat -pnaut
-        tcp        0      0 0.0.0.0:7999            0.0.0.0:               LISTEN      9828 tincd         
-        udp        0      0 0.0.0.0:7999            0.0.0.0:                           9828 tincd
-
    -

    Beta peer

    - -

    Create config files

    - -

    /etc/tinc/gatewayvpn/tinc.conf - -

    -        Name: beta 
-        Device: /dev/net/tun
-        ConnectTo: alpha
-
    -

    Beta will connect to alpha, for this connection beta will look in /etc/tinc/gatewayvpn/hosts/alpha and connect to this IP:PORT - -

    /etc/tinc/gatewayvpn/tinc-up - -

    -        #!/bin/sh
-        ip link set $INTERFACE up
-        ip addr add  172.16.16.2/24 dev $INTERFACE      
-
    -

    Beta will get assigned 172.16.16.2 -

    -

    /etc/tinc/gatewayvpn/tinc-down -

    -
    -        #!/bin/sh
-        ip addr del 172.16.16.2/24 dev $INTERFACE
-        ip link set $INTERFACE down
-
    - - -

    /etc/tinc/gatewayvpn/hosts/beta -

    -
    -        Subnet = 172.16.16.2/32
-        Port = 7999
-
    -

    We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network. -

    -

    Create private keys

    - -
    -        tincd -n gatewayvpn --generate-keys
-        Generating 2048 bits keys: ...........
-        Done.
-        Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]: 
-        Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]:
-
    -

    So now you will also have created the private key file for beta. Public keys are written to files in the host directory. -*Note: don't forget to put /etc/tinc/gatewayvpn/hosts/beta on the alpha side and alpha on the beta side. -

    -
    -        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha .
-        alpha                                               100%  481     0.5KB/s   00:00    
-        root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/
-        beta                                                100%  463     0.5KB/s   00:00    
-
    -

    Test your configuration

    - -

    See alpha. -

    -

    Initial run

    - -

    Now let's see if the configuration is correct and both peers' connections are accepted. -We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet. -

    -

    First start alpha: - -

    -        root@alpha:~$
-        root@alpha:~$ tincd -n gatewayvpn --log-file /root/log
-
    -

    Then start beta: -

    -
    -        root@beta:~$
-        root@beta:~$ tincd -n gatewayvpn --log-file /root/log
-
    -

    Now test if you can ping! -

    -
    -        root@alpha:~# ping 172.16.16.2
-        PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data.
-        64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms
-        64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms
-        64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms
-
-        root@beta:~# ping 172.16.16.1
-        ping 172.16.16.1
-        PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
-        64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms
-        64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms
-        64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms
-
    -

    Routing gateway

    - -

    (Note: mostly copied from the tinc manual) -It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow. -

    -

    Theory

    -

    Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux: -

    -
    -        Destination     Gateway         Genmask         Flags   Metric  Ref     Use     Iface
-        192.168.1.0     0.0.0.0         255.255.255.0   U       0       0       0       eth0
-        0.0.0.0         192.168.1.1     0.0.0.0         UG      0       0       0       eth0
-
    -

    Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become: -

    -
    -        Kernel IP routing table
-        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
-        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
-        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
-        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
-        0.0.0.0         172.16.16.1     0.0.0.0         UG    0      0        0 gatewayvpn
-
    -

    This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN. -

    -

    It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route: -

    -
    -        Kernel IP routing table
-        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
-        172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
-        1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
-        192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
-        128.0.0.0       172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
-        0.0.0.0         172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
-        0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
-
    -

    Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present. -

    -

    Scripts

    - -

    To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files. -

    -

    /etc/tinc/gatewayvpn/tinc-up -

    -
    -        #!/bin/sh
-        VPN_GATEWAY=172.16.16.1
-        REMOTEADDRESS=1.2.3.4
-        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
-
-        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
-        ip route add $VPN_GATEWAY dev $INTERFACE
-        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
-        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
-
    -

    /etc/tinc/gatewayvpn/tinc-down -

    -
    -        #!/bin/sh       
-        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
-        REMOTEADDRESS=1.2.3.4
-
-        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
-        ip route del $VPN_GATEWAY dev $INTERFACE
-        ip route del 0.0.0.0/1 dev $INTERFACE
-        ip route del 128.0.0.0/1 dev $INTERFACE
-
    -

    These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server. -

    -

    Setup firewall

    - -

    Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. -

    -
    -        #!/bin/sh
-        # iptables config line to masquerade
-        
-        echo "Enabling IPv4 forwarding"
-        echo 1 >/proc/sys/net/ipv4/ip_forward
-        
-        echo "Appending Masquerade rule to iptables"
-        iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
-
    -

    Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0. -

    -

    Test the gateway

    - -

    Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. -

    -

    Troubleshooting help

    - -
      -
    • DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration -
    -
    -        root@beta:~$ cat /etc/resolv.conf       
-        # resolv.conf file
-        nameserver 127.0.1.0
-
    -
      -
    • and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway - -
    -
    -        IP ROUTING TABLE
-        link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
-
    -
      -
    • A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 - -
    • Check your logfile while running tinc (i.e. you might forgot to create a key pair): -
    -
    -        2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file
-         `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory
-
    -
      -
    • Overview of created files - -
    -
    -        root@alpha:~$ ls -R /etc/tinc/gatewayvpn
-        /etc/tinc/gatewayvpn:
-        hosts/  rsa-key.priv  tinc.conf  tinc-down  tinc-up
-        /etc/tinc/gatewayvpn/hosts:
-        alpha beta
-        
-        root@beta:~$ ls -R /etc/tinc/gatewayvpn
-        /etc/tinc/gatewayvpn:
-        hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
-        /etc/tinc/gatewayvpn/hosts:
-        alpha beta
-
    -
      -
    • Use tcpdump or wireshark to analyze your network devices -
    - - - diff --git a/tinc.txt b/tinc.txt deleted file mode 100644 index 06a7f42..0000000 --- a/tinc.txt +++ /dev/null @@ -1,328 +0,0 @@ -robinkrens.nl - Redirecting traffic and TINC -===== - -Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org -Here I will show a tinc setup with an *alpha* (as a listening peer) and a *beta* (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way. - -------------- - -Alpha peer -********** - -Create config files -+++++++ - -_/etc/tinc/gatewayvpn/tinc.conf_ - - Name: alpha - Device: /dev/net/tun - -The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections. - -_/etc/tinc/gatewayvpn/tinc-up_ - - #!/bin/sh - ip link set $INTERFACE up - ip addr add 172.16.16.1/24 dev $INTERFACE - -This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like: - - $ ifconfig gatewayvpn - gatewayvpn Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00 - inet addr:172.16.16.1 P-t-P:172.16.16.1 Mask:255.255.255.0 - UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 - -We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha. - -_/etc/tinc/gatewayvpn/tinc-down_ - - #!/bin/sh - ip addr del 172.16.16.1/24 dev $INTERFACE - ip link set $INTERFACE down - -Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse. - - -_/etc/tinc/gatewayvpn/hosts/alpha_ - - Address = 1.2.3.4 - Port = 7999 - Subnet = 0.0.0.0/0 - -This file should be send to all the other peers (only beta in this example). We _create_ this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the *whole* internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc. - -Create private keys -+++++++++ - - - $ root@alpha tincd -n gatewayvpn --generate-keys - Generating 2048 bits keys: ........... - Done - Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]: - Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]: - -Generate public/private RSA keypair. Private key will be written to _/etc/tinc/gatewayvpn/rsa-key.priv_. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. _/etc/tinc/gatewayvpn/hosts/alpha_ will look like this - - Address = 1.2.3.4 - Port = 7999 - Subnet = 0.0.0.0/0 - - -----BEGIN RSA PUBLIC KEY----- - Blabla - -----END RSA PUBLIC KEY----- - -Test your configuration -+++++++++ - -Now alpha is setup. We can test our configuration as follows: - - root@alpha:~$ tincd -n gatewayvpn --logfile /root/log - root@alpha:~$ - -Logfile should show the following output: - - root@alpha:~# cat /root/log - 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul 5 2015 23:17:54) starting, debug level 0 - 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode) - 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready - -You should also be able to ping to the tunneling device: - - root@alpha:~$ ping 172.16.16.1 - PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data. - 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms - 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms - ^C - --- 172.16.16.1 ping statistics --- - 2 packets transmitted, 2 received, 0% packet loss, time 999ms - rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms - -The tinc daemon is listening on our configured port 7999: - - root@alpha:~$ netstat -pnaut - tcp 0 0 0.0.0.0:7999 0.0.0.0: LISTEN 9828 tincd - udp 0 0 0.0.0.0:7999 0.0.0.0: 9828 tincd - - -Beta peer -******** - - -Create config files -+++++++ - -_/etc/tinc/gatewayvpn/tinc.conf_ - - Name: beta - Device: /dev/net/tun - ConnectTo: alpha - -Beta will connect to alpha, for this connection beta will look in _/etc/tinc/gatewayvpn/hosts/alpha_ and connect to this IP:PORT - -_/etc/tinc/gatewayvpn/tinc-up_ - - #!/bin/sh - ip link set $INTERFACE up - ip addr add 172.16.16.2/24 dev $INTERFACE - -Beta will get assigned 172.16.16.2 - -_/etc/tinc/gatewayvpn/tinc-down_ - - #!/bin/sh - ip addr del 172.16.16.2/24 dev $INTERFACE - ip link set $INTERFACE down - - -_/etc/tinc/gatewayvpn/hosts/beta_ - - Subnet = 172.16.16.2/32 - Port = 7999 - -We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network. - -Create private keys -+++++++++ - - tincd -n gatewayvpn --generate-keys - Generating 2048 bits keys: ........... - Done. - Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]: - Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]: - -So now you will also have created the private key file for beta. Public keys are written to files in the host directory. -*Note: don't forget to put _/etc/tinc/gatewayvpn/hosts/beta_ on the alpha side and alpha on the beta side. - - root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha . - alpha 100% 481 0.5KB/s 00:00 - root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/ - beta 100% 463 0.5KB/s 00:00 - -Test your configuration -+++++++++++ - -See alpha. - - -Initial run -********* - -Now let's see if the configuration is correct and both peers' connections are accepted. -We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet. - -First start alpha: - - root@alpha:~$ - root@alpha:~$ tincd -n gatewayvpn --log-file /root/log - -Then start beta: - - root@beta:~$ - root@beta:~$ tincd -n gatewayvpn --log-file /root/log - - -Now test if you can ping! - - root@alpha:~# ping 172.16.16.2 - PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data. - 64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms - 64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms - 64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms - - root@beta:~# ping 172.16.16.1 - ping 172.16.16.1 - PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data. - 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms - 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms - 64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms - - -Routing gateway -********** - -(Note: mostly copied from the tinc manual) -It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow. - - -Theory -+++++++ -Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux: - - Destination Gateway Genmask Flags Metric Ref Use Iface - 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 - 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 - -Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become: - - Kernel IP routing table - Destination Gateway Genmask Flags Metric Ref Use Iface - 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn - 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 - 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 - 0.0.0.0 172.16.16.1 0.0.0.0 UG 0 0 0 gatewayvpn - -This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN. - -It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route: - - Kernel IP routing table - Destination Gateway Genmask Flags Metric Ref Use Iface - 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn - 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 - 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 - 128.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn - 0.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn - 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 - -Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present. - -Scripts -+++++++++ - -To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files. - -_/etc/tinc/gatewayvpn/tinc-up_ - - #!/bin/sh - VPN_GATEWAY=172.16.16.1 - REMOTEADDRESS=1.2.3.4 - ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` - - ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY - ip route add $VPN_GATEWAY dev $INTERFACE - ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE - ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE - -_/etc/tinc/gatewayvpn/tinc-down_ - - #!/bin/sh - ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` - REMOTEADDRESS=1.2.3.4 - - ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY - ip route del $VPN_GATEWAY dev $INTERFACE - ip route del 0.0.0.0/1 dev $INTERFACE - ip route del 128.0.0.0/1 dev $INTERFACE - -These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server. - - -Setup firewall -+++++++++ - -Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading. - - #!/bin/sh - # iptables config line to masquerade - - echo "Enabling IPv4 forwarding" - echo 1 >/proc/sys/net/ipv4/ip_forward - - echo "Appending Masquerade rule to iptables" - iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE - -Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0. - - -Test the gateway -+++++++++++ - -Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark. - - -Troubleshooting help -******* - -* DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration - - root@beta:~$ cat /etc/resolv.conf - # resolv.conf file - nameserver 127.0.1.0 - -* and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway - - IP ROUTING TABLE - link-local * 255.255.0.0 U 1000 0 0 wlp7s0 - -* A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8 - -* Check your logfile while running tinc (i.e. you might forgot to create a key pair): - - 2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file - `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory - -* Overview of created files - - root@alpha:~$ ls -R /etc/tinc/gatewayvpn - /etc/tinc/gatewayvpn: - hosts/ rsa-key.priv tinc.conf tinc-down tinc-up - /etc/tinc/gatewayvpn/hosts: - alpha beta - - root@beta:~$ ls -R /etc/tinc/gatewayvpn - /etc/tinc/gatewayvpn: - hosts/ rsa-key.priv tinc.conf tinc-down tinc-up - /etc/tinc/gatewayvpn/hosts: - alpha beta - -* Use tcpdump or wireshark to analyze your network devices diff --git a/tmp.txt b/tmp.txt deleted file mode 100644 index b76f4eb..0000000 --- a/tmp.txt +++ /dev/null @@ -1,49 +0,0 @@ - -robinkrens.nl - On VPN and bypassing a firewall -******** - -Let's say you want to connect to a company network and access all the computers in this network (behind a firewall) One way to do this is to setup a Virtual Private Network. Although you are not physically in the same building, all the other computers will think you are, hence *Virtual* Private Network. After you connect to this VPN, you will be assigned a local IP (i.e. 10.0.0.5) and communicate directly to all computers in this range directly. - -In case of bypassing a Internet Service Provider (ISP) or Great Firewall (GFW), you want to access all the websites that are normally not accessible. There are many ways to this. Software written to setup up VPNs are especially useful for this. Add some additional routing and you bypassed the firewall. Look at the following illustration - - - [Pity you] -------- [ISP/GFW: No youtube!]-------- [YouTube.com] - - -The ISP or GFW has some firewall rules to block certains IPs or to detect certain *suspicious* traffic. But let's say you have access to a server that isn't behind the firewall. Would you be able to redirect your Youtube request through this server and then send it to your PC? Well, yes. - - [Pity you] -------- [ISP/GFW]----------[Not blocked server]--------[Youtube.com] - -Hmm, still pity you. Although your server can access YouTube.com, if it sends traffic back it still has to send to the ISP/GFW. So unless the firewall rules - - - -The setup is as follows - - -Some alternative software to bypass a huge firewall (as in your ISP or a country). A list of sample configuration. - - -Basic Tunneling ---------------- -Basic tunneling, or IP in IP. Basically we connect to networks that normally would not be able to talk to each other (directy) -This setup is straightforward like this: - - ExtIP 1.2.3.4 ---- ( INTERNET ) ---- ExtIP 5.6.7.8 - - Local: 10.0.1.0/24 ----- [TUNNEL] ----- 10.0.2.0/24 - ExtIP: 1.2.3.4 5.6.7.8 - | | - | | - |-------- ( INTERNET ) -------------| - - -This version of tunneling has been supported since the early kernel versions of linux (<1.3). - -No encrytion here. No IPV6 or anything other fancy. - - ip tuntap add tun0 mode tun - ip addr add 192.168.1.2 dev tun0 - ip add route ... - - diff --git a/tunneling.html b/tunneling.html deleted file mode 100644 index ac68a7a..0000000 --- a/tunneling.html +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - - - -

    robinkrens.nl - Tunneling, repackaging and VPN

    - -

    This page lists tutorials and sample code. -

    - - - - diff --git a/tunneling.txt b/tunneling.txt deleted file mode 100644 index 30def6c..0000000 --- a/tunneling.txt +++ /dev/null @@ -1,9 +0,0 @@ -robinkrens.nl - Tunneling, repackaging and VPN -******** - -This page lists tutorials and sample code. - -* : A simple setup with a peers forwarding traffic. -* : Similar setup as the above with fastd. -* Strongswan: A mobike setup (not published). - -- 2.7.4