Tailscale is a service based on WireGuard that lets one’s devices form a peer-to-peer private network in a easy and seamless manner.

I have been using it for over a year now, so I can now do a quick review on how I use the service on a day-to-day basis.

Setup

Although it is possible to set up WireGuard manually to connect devices, it gets harder when peers are behind NAT. Tailscale takes charge of NAT traversal automagically. It’s also much simpler to setup, because once you’re connected to your Tailscale account, all your peers are added automatically and kept up-to-date. Currently, I connect to all my personal servers through Tailscale!

While I usually use a VPN in public places like cafes, I don’t always do on networks I trust more, like my home or University. Nearly all of my network traffic is encrypted thanks to HTTPS, so my DNS requests are the only plaintext data I sent out in the wild.

I’ve been using DNS-over-TLS (DoT) on my Android phone for nearly 2 years thanks to Android’s native DoT support since version 9. After doing a little bit of research a while ago, I thought it would be a hassle to use an encrypted DNS protocol on my MacBook, but it turns out to be very simple.

Have you ever wondered which DNS resolver is the closest to your location?

There is an Android app called DNS Speed Test that I have been using for a long time that allows to make latency tests on the go.

As you can see here in Seoul Cloudflare is by far the fastest, since I hit the Seoul PoP.

IPv6 works out of the box on Hetzner Cloud VMs. However, once you start adding IPv6 to an existing or new interface, IPv6 connectivity completely falls apart.

I started to notice this a year and half ago, when I was trying to setup LXD. With the help of a fellow sysadmin, we tried to hunt down the issue, without success, but found a dirty workaround.

Then it was reported again on my openvpn-install script, and more recently on my wireguard-install script, so I decided to dive into this issue once more.

WireGuard is a fast and modern VPN protocol.

It is a point-to-point VPN, which means it does not have a client-server architecture, but peers, and does not rely on a PKI, unlike OpenVPN. It is super simple to setup to connect multiple machines together.

WireGuard supports roaming, which means you can switch between network connections and not have to reconnect to your peers. On servers, it’s rarely useful, but when one of the peer is a mobile client like a laptop or a smartphone, it’s a life saver, because the usage of WireGuard is completely transparent.

Despite Online.net supporting FreeBSD, they don’t mention it at all in their IPv6 wiki page.

After a bit of research, I found two posts about that.

The first one uses WIDE DHCPv6 (also known as KAME DHCPv6, dhcp6c or dhcp6.

Since this is the only functioning tutorial I found, I will write here the steps I did to get IPv6:

1. Enable IPv6 on the console and get your DUID.
2. Enable IPv6 on the NIC:

ifconfig igb0 inet6 -ifdisabled accept_rtadv up

3. Transform the DUID into a binary file (needed for dhcp6c):

echo <DUID> | awk '{ gsub(":"," "); printf "0: 0a 00 %s\n", $0 }' | xxd -r > /var/db/dhcp6c_duid

4. Add this in /usr/local/etc/dhcp6c.conf:

id-assoc pd {
        prefix-interface igb0 {
        };
};

id-assoc na {
};

interface igb0 {
    send ia-pd 0;
    send ia-na 0;
};

5. Now run dhpc6c manually or start the service:

dhcp6c -Df -c /usr/local/etc/dhcp6c.conf em0

# or

service dhcp6c restart

6. You should have your public IPv6 /128 now (2001:bc8:...).

ifconfig igb0

root@fdb:~ # ping6 -c 3 angristan.xyz
PING6(56=40+8+8 bytes) 2001:bc8:xxx::1 --> 2a01:4f8:1c1c:2cc3::bad:c0de
16 bytes from 2a01:4f8:1c1c:2cc3::bad:c0de, icmp_seq=0 hlim=55 time=21.645 ms
16 bytes from 2a01:4f8:1c1c:2cc3::bad:c0de, icmp_seq=1 hlim=55 time=22.948 ms
16 bytes from 2a01:4f8:1c1c:2cc3::bad:c0de, icmp_seq=2 hlim=55 time=21.708 ms

--- angristan.xyz ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 21.645/22.100/22.948/0.600 ms

7. Automate all of this at boot time by adding this to /etc/rc.conf:

ifconfig_igb0_ipv6="inet6 -ifdisabled accept_rtadv up"
dhcp6c_enable="YES"
dhcp6c_interfaces="igb0"
rtsold_enable="YES"

Done!

Here’s a quick tip, that also applies to any linux machine using dhcpd.

Every now and then my Raspberry Pi or my router can reboot, and I’m not certain than my Pi will get the same IP address from the DHCP server.

Sure, I could fix it on the DHCP server using the Pi’s MAC address, but if you’re a lazy bum like me you can tell dhcpd to request a specific IPv4 address.

I’m currently running Ubuntu 18.04 and I noticed that by default I was using systemd-resolved for DNS:

stanislas@xps ~> cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53

Most of the recent systemd distributions use it, Ubuntu does since 16.10. It has the same role as dnsmasq.

After having played around a bit with LXC and discovered its main features, you may want to have a proper network setup for your containers.

There are multiple network setups possible and multiple ways to implement them. In this post, we are going to setup a bridge, using lxc-net. It requires very little configuration and should be enough for a simple LXC architecture.

More details about this bridge setup:

• Containers will have an IPv4 within their own subnet
• Containers will be able to access each other within this subnet
• The host will be able to access the containers trough this subnet
• Containers will have access to the internet thanks to the bridge interface

Note that I’m using Debian 9 for this tutorial. Also, if you’re using LXD to manage your LXC containers, this isn’t necessary as it does everything automatically.

Have you ever wanted to make a speedtest from your terminal, and not from these heavy websites stuffed with ads? How about from a headless machine like a server?