robinkrens.nl - git repository - robinkrens.nl/blob - vimwiki/Tinc.wiki

   1 = Tinc =
   2
   3 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.
   4
   5 == Alpha peer ==
   6 Create config files /etc/tinc/gatewayvpn/tinc.conf
   7
   8 {{{
   9 Name: alpha
  10 Device: /dev/net/tun
  11 }}}
  12
  13 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.
  14
  15 /etc/tinc/gatewayvpn/tinc-up
  16 {{{
  17 #!/bin/sh
  18 ip link set $INTERFACE up
  19 ip addr add  172.16.16.1/24 dev $INTERFACE
  20 }}}
  21
  22 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:
  23
  24 {{{
  25 $ ifconfig gatewayvpn
  26 gatewayvpn   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00
  27 inet addr:172.16.16.1  P-t-P:172.16.16.1  Mask:255.255.255.0
  28 UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  29 }}}
  30
  31 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.
  32
  33 /etc/tinc/gatewayvpn/tinc-down
  34
  35 {{{
  36 #!/bin/sh
  37 ip addr del 172.16.16.1/24 dev $INTERFACE
  38 ip link set $INTERFACE down
  39 }}}
  40
  41 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.
  42
  43 /etc/tinc/gatewayvpn/hosts/alpha
  44
  45 {{{
  46 Address = 1.2.3.4
  47 Port = 7999
  48 Subnet = 0.0.0.0/0
  49 }}}
  50
  51 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.
  52
  53 === Create private keys ===
  54
  55 {{{ $ root@alpha tincd -n gatewayvpn --generate-keys
  56 Generating 2048 bits keys: ...........
  57 Done
  58 Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]:
  59 Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]:
  60 }}}
  61
  62 Generate public/private RSA keypair. Private
  63 key will be written to
  64 /etc/tinc/gatewayvpn/rsa-key.priv. Public key
  65 will be written to all the files in
  66 /etc/tinc/gatewayvpn/hosts/. So after running
  67 this command.
  68 /etc/tinc/gatewayvpn/hosts/alpha will look
  69 like this:
  70
  71 {{{
  72 Address = 1.2.3.4
  73 Port = 7999
  74 Subnet = 0.0.0.0/0
  75 -----BEGIN RSA PUBLIC KEY-----
  76 Blabla
  77 -----END RSA PUBLIC KEY-----
  78 }}}
  79
  80 === Test your configuration ===
  81 Now alpha is setup. We can test our configuration as follows:
  82
  83 {{{
  84 root@alpha:~$ tincd -n gatewayvpn --logfile /root/log
  85 root@alpha:~$
  86 }}}
  87
  88 The logfile should show the following output:
  89
  90 {{{
  91 root@alpha:~# cat /root/log
  92 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul  5 2015 23:17:54) starting, debug level 0
  93 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode)
  94 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready
  95 }}}
  96
  97 You should also be able to ping to the tunneling device:
  98
  99 {{{
 100 root@alpha:~$ ping 172.16.16.1
 101 PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
 102 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms
 103 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms
 104 ^C
 105 --- 172.16.16.1 ping statistics ---
 106 2 packets transmitted, 2 received, 0% packet loss, time 999ms
 107 rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms
 108 }}}
 109
 110 The tinc daemon is listening on our configured port 7999:
 111
 112 {{{
 113 root@alpha:~$ netstat -pnaut
 114 tcp        0      0 0.0.0.0:7999            0.0.0.0:               LISTEN      9828 tincd
 115 udp        0      0 0.0.0.0:7999            0.0.0.0:                           9828 tincd
 116 }}}
 117
 118 == Beta peer ==
 119
 120 Create config files /etc/tinc/gatewayvpn/tinc.conf
 121
 122 {{{
 123 Name: beta
 124 Device: /dev/net/tun
 125 ConnectTo: alpha
 126 }}}
 127
 128 Beta will connect to alpha, for this connection beta will look in /etc/tinc/gatewayvpn/hosts/alpha and connect to this IP:PORT
 129
 130 /etc/tinc/gatewayvpn/tinc-up
 131
 132 {{{
 133 #!/bin/sh
 134 ip link set $INTERFACE up
 135 ip addr add  172.16.16.2/24 dev $INTERFACE
 136 }}}
 137
 138 Beta will get assigned 172.16.16.2
 139
 140 /etc/tinc/gatewayvpn/tinc-down
 141
 142 {{{
 143 #!/bin/sh
 144 ip addr del 172.16.16.2/24 dev $INTERFACE
 145 ip link set $INTERFACE down
 146 }}}
 147
 148 /etc/tinc/gatewayvpn/hosts/beta
 149
 150 {{{
 151 Subnet = 172.16.16.2/32
 152 Port = 7999
 153 }}}
 154
 155 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.
 156
 157 === Create private keys ===
 158
 159 {{{
 160 tincd -n gatewayvpn --generate-keys
 161 Generating 2048 bits keys: ...........
 162 Done.
 163 Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]:
 164 Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]:
 165 }}}
 166
 167 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.
 168
 169 {{{
 170 root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha .
 171 alpha                                               100%  481     0.5KB/s   00:00
 172 root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/
 173 beta                                                100%  463     0.5KB/s   00:00
 174 }}}
 175
 176 === Test your configuration ===
 177 See alpha.
 178
 179 == Initial run ==
 180 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.
 181
 182 First start alpha:
 183
 184 {{{
 185 root@alpha:~$
 186 root@alpha:~$ tincd -n gatewayvpn --log-file /root/log
 187 }}}
 188
 189 Then start beta:
 190
 191 {{{
 192 root@beta:~$
 193 root@beta:~$ tincd -n gatewayvpn --log-file /root/log
 194 }}}
 195
 196 Now test if you can ping!
 197
 198 {{{
 199 root@alpha:~# ping 172.16.16.2
 200 PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data.
 201 64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms
 202 64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms
 203 64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms
 204 root@beta:~# ping 172.16.16.1
 205 ping 172.16.16.1
 206 PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
 207 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms
 208 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms
 209 64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms
 210 }}}
 211
 212 == Routing gateway ==
 213 (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.
 214
 215 === Theory ===
 216 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:
 217 {{{
 218 Destination     Gateway         Genmask         Flags   Metric  Ref     Use     Iface
 219 192.168.1.0     0.0.0.0         255.255.255.0   U       0       0       0       eth0
 220 0.0.0.0         192.168.1.1     0.0.0.0         UG      0       0       0       eth0
 221 }}}
 222
 223 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:
 224 {{{
 225 Kernel IP routing table
 226 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 227 172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
 228 1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
 229 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
 230 0.0.0.0         172.16.16.1     0.0.0.0         UG    0      0        0 gatewayvpn
 231 }}}
 232
 233 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.
 234
 235 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:
 236
 237 {{{
 238 Kernel IP routing table
 239 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 240 172.16.16.1     0.0.0.0         255.255.255.255 UH    0      0        0 gatewayvpn
 241 1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
 242 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
 243 128.0.0.0       172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
 244 0.0.0.0         172.16.16.1     128.0.0.0       UG    0      0        0 gatewayvpn
 245 0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
 246 }}}
 247
 248 Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present.
 249 Scripts
 250 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.
 251
 252 /etc/tinc/gatewayvpn/tinc-up
 253
 254 {{{
 255 #!/bin/sh
 256 VPN_GATEWAY=172.16.16.1
 257 REMOTEADDRESS=1.2.3.4
 258 ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
 259 ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
 260 ip route add $VPN_GATEWAY dev $INTERFACE
 261 ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
 262 ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
 263 }}}
 264
 265 /etc/tinc/gatewayvpn/tinc-down
 266
 267 {{{
 268 #!/bin/sh
 269 ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
 270 REMOTEADDRESS=1.2.3.4
 271 ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
 272 ip route del $VPN_GATEWAY dev $INTERFACE
 273 ip route del 0.0.0.0/1 dev $INTERFACE
 274 ip route del 128.0.0.0/1 dev $INTERFACE
 275 }}}
 276
 277 These script use the iproute2 commands, because they are easier to work with. The VPNGATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINALGATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server.
 278
 279 == Setup firewall ==
 280 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.
 281 {{{
 282 #!/bin/sh
 283 # iptables config line to masquerade
 284
 285 echo "Enabling IPv4 forwarding"
 286 echo 1 >/proc/sys/net/ipv4/ip_forward
 287
 288 echo "Appending Masquerade rule to iptables"
 289 iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
 290 }}}
 291
 292 Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0.
 293
 294 == Test the gateway ==
 295 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.
 296
 297 == Troubleshooting help ==
 298 DNS request are not forwarded through the
 299 gateway. Check your resolver config files
 300 (/etc/resolv.conf). Debian-based systems
 301 might have the following configuration:
 302
 303 {{{
 304 root@beta:~$ cat /etc/resolv.conf
 305 # resolv.conf file
 306 nameserver 127.0.1.0
 307 }}}
 308
 309 and in your routing table you might have the
 310 following entry. A local / caching DNS server
 311 might still send packages to your router. Use
 312 wireshark to see if there are any DNS
 313 queries, not going to the VPN gateway:
 314
 315 {{{
 316 IP ROUTING TABLE
 317 link-local      *               255.255.0.0     U     1000   0        0 wlp7s0
 318 }}}
 319
 320 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):
 321
 322
 323 {{{
 324 2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file
 325 `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory
 326 }}}
 327
 328 Overview of created files
 329
 330 {{{
 331 root@alpha:~$ ls -R /etc/tinc/gatewayvpn
 332 /etc/tinc/gatewayvpn:
 333 hosts/  rsa-key.priv  tinc.conf  tinc-down  tinc-up
 334 /etc/tinc/gatewayvpn/hosts:
 335 alpha beta
 336 }}}
 337
 338 {{{
 339 root@beta:~$ ls -R /etc/tinc/gatewayvpn
 340 /etc/tinc/gatewayvpn:
 341 hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
 342 /etc/tinc/gatewayvpn/hosts:
 343 alpha beta
 344 }}}
 345
 346 Use tcpdump or wireshark to analyze your network devices