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.

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.

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. For some reason Google makes me go through North America according to traceroute/mtr, hence the difference.

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: Enable IPv6 on the console and get your DUID. Enable IPv6 on the NIC: ifconfig igb0 inet6 -ifdisabled accept_rtadv up 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 Add this in /usr/local/etc/dhcp6c.

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.

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.

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? Tip Update: there is now an official and more reliable CLI. Well you can, with speedtest-cli, a open source python script that uses the speedtest.net API. It’s lightweight and easy to install: you just have to install Python 2.x or 3.x on your machine and download the .