Igor Bubelov

Tailscale

Wed, 19 Oct 2022 00:00:00 +0000

I’ve been running WireGuard for years and it’s been solid. Lately, there’s a whole cottage industry of projects trying to slap a shiny GUI on WireGuard to make it “easy” for non-tech people. Tailscale is the one everyone won’t shut up about, so I decided to check it out.

Verdict: total letdown. It was more annoying to set up than plain WireGuard, and it forces you to use some third-party login. Maybe that makes sense in a corporate hellscape, but certainly not for my self-hosted stuff.

Wi-Fi 6 Router

Sat, 17 Apr 2021 00:00:00 +0000

First, let me say that Wi-Fi 6 is not a revolutionary change in wireless communications. Yes, it’s a bit faster, and it has certain features aimed to make Wi-Fi more efficient in crowded places, but overall, I didn’t notice any difference in my home setup. I just saw a banner on my Internet provider’s website, and I decided to ask my provider about the possibility of upgrading the router. It uses GPON, so I can’t really go shopping and pick any router I like, unfortunately. It turned out, they offer free router upgrades, so I decided to use this opportunity. The router hardware is faster, which allows it to keep latency low under load, and their new firmware finally got advanced enough to allow custom MAC to IP mappings. I really missed that feature. Those improvements have nothing to do with Wi-Fi 6, by the way.

Getting Familiar With nftables

Fri, 18 Sep 2020 00:00:00 +0000

The more I experiment with nftables, the more I like it. It’s not high level enough to be a black box Voodoo magic, and it’s not low level enough to be a royal pain in the ass.

Let’s look at the following example:

#!/usr/sbin/nft -f

flush ruleset

### CHAINS
# INPUT - all incoming packets are checked against the rules in this chain
# OUTPUT - all outgoing packets are checked against the rules in this chain
# FORWARD - all packets being sent to another computer are checked against the rules in this chain
###

### CT STATES
# NEW - the packet has started a new connection
# ESTABLISHED - the packet is associated with a connection which has seen packets in both directions
# RELATED - the packet is starting a new connection, but is associated with an existing connection
###

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept comment "Accept localhost traffic"
    ct state established,related accept comment "Accept traffic originated from here"
    tcp dport ssh accept comment "Accept SSH traffic"
  }

  chain output {
    type filter hook output priority 0;
  }

  # Drop everything, it's not a router
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
}

Not much code to describe a firewall ruleset! It’s also easy to read and modify. All the action happens in the input chain which is responsible for filtering all the incoming traffic. It starts with a default-deny mode which means it doesn’t allow any incoming traffic to pass unless you add a special rule that allows certain kinds of traffic under certain conditions.

First, I wanted to allow any traffic coming from the loopback interface:

## iif = 'if input interface is ...'
## lo = loopback interface
iif lo accept comment "Accept localhost traffic"

Next, it would be nice to tell the firewall to accept any traffic sent to this computer as a response to locally initiated requests:

### CT STATES
# NEW - the packet has started a new connection
# ESTABLISHED - the packet is associated with a connection which has seen packets in both directions
# RELATED - the packet is starting a new connection, but is associated with an existing connection
###
ct state established,related accept comment "Accept traffic originated from here"

And finally, it would be nice to have an SSH port open if you’re dealing with the remote machine. Shutting yourself from your own server can be a costly mistake, and it’s not uncommon. Here is how to allow SSH traffic, assuming your SSH daemon is set to listen on a well known port 22 (which you should change, by the way):

tcp dport ssh accept comment "Accept SSH traffic"

If you don’t want to get spammed by unwelcome SSH login attempts, just set your SSH daemon to listen to another port. Let’s say our SSH daemon is listening on the port 40736. That would mean that we need to add the following rule:

tcp dport 40736 accept comment "Accept SSH traffic"

If you decide to host an HTTP server on this machine, just add http and https ports to that rule:

tcp dport { 40736, http, https } accept comment "Accept SSH and HTTP(S) traffic"

That’s it. Opening additional ports is trivial and the documentation is good. I’m just starting with this thing, and I’m planning to experiment with the logging and tracing tools in the following weeks.

IP Forwarding With Nftables

Sun, 23 Aug 2020 00:00:00 +0000

I have a Digital Ocean droplet which I use as a proxy for my self-hosted home server. I’ve been using some hacky solution based on iptables but it was a pain in the ass, so I’ve decided to get rid of this piece of technical debt and the first thing that I noticed was the deprecation of iptables utility itself.

It certainly looks like nftables is the future, so I played with it for a while, and I settled with the following config for my proxy:

#!/usr/sbin/nft -f

define wan = eth0
define wg = wg0
define wg_net = 10.0.0.0/24

# TODO Since Linux kernel 5.2, there is support for performing stateful NAT in inet family chains.
table ip wg {
  chain prerouting {
    # Priority = NF_IP_PRI_NAT_DST (-100, destination NAT)
    type nat hook prerouting priority -100;
    iif $wan tcp dport { http, https } dnat 10.0.0.2
  }

  chain postrouting {
    # Priority = NF_IP_PRI_NAT_SRC (100, source NAT)
    type nat hook postrouting priority 100;
    # Mask WireGuard packets as if they come from this server
    oif $wan ip saddr $wg_net masquerade
  }

  chain input {
    type nat hook input priority 100;
  }

  chain output {
    type nat hook output priority -100;
  }
}

It looks way cleaner than the iptables equivalent, and it can certainly be refactored to look even more readable. I really like its declarative way of describing the traffic rules.

The prerouting chain just redirects all the TCP traffic coming to the ports 80 or 443 to my home-based Raspberry Pi 4. Both DO droplet and RPi share the same WireGuard network between them. The RPi IP address is 10.0.0.2, that’s why dnat points there in the config above. I should probably convert this magic number into a variable, thankfully nftables supports that.

The postrouting chain is pretty interesting. It allows me to use that DO droplet as a VPN server. It masks all the outgoing traffic with this server’s IP address but that traffic can originate from any node in my WireGuard network. Such a VPN won’t give you a lot of privacy since most of the mainstream hosting providers know your name, email and even your credit card info, but it can certainly be used to circumvent certain kinds of Internet censorship in your real location.

WireGuard

Sat, 30 May 2020 00:00:00 +0000

I have a Nextcloud server in my house, and it works great inside my local network, but it also needs to be reachable from the Internet and that’s where it gets a bit tricky. My server has a local IP, but it doesn’t have a globally reachable IP, and there are no easy ways to get one from a regular residential ISP.

The most convenient way to reach a website is by its domain name. Any browser can execute a DNS query to figure out the actual IP addresses behind a particular domain name you’re trying to access, and once that address is found, your browser of choice can finally initiate a connection.

So, my Nextcloud server needs the following things to be globally reachable:

A domain.
A unique IP address to point that domain to.

I already had a domain and the only thing missing was a unique IP address to put inside an A record. It turned out that Digital Ocean has a data center close enough (ping < 30 ms) to my house, and I decided to rent a cheap virtual machine there and use its globally reachable IP address for my local Nextcloud server.

It’s fair to stop there and ask yourself “why didn’t this guy just host his stupid Nextcloud on that droplet directly? What’s the point of hosting stuff from home?”. Those are good questions and the answer is: privacy and cost. I don’t want to hold my private data anywhere except in my house, and I also don’t want to pay a lot of money for storage space that I already have and can use for free. Even buying a new HDD or an SSD is much, much cheaper than renting the equivalent space in the cloud.

So, my domain’s A record can point all the traffic to that DO droplet, which has a unique and globally reachable IP address, so the only extra thing I needed to do was to connect my home server with that VM somehow. I had heard that setting up OpenVPN is not particularly easy, and I wanted to find an easier solution. A few web searches later, I ended up reading about a tool called autossh.

This excellent post helped me get it up and running in no time but, unfortunately, autossh is kind of cryptic and sometimes it just stops working without logging any reason why. That’s why I had to get rid of autossh and find a way to set up a proper VPN.

It turned out that setting up a VPN can be pretty easy, thanks to WireGuard. It’s also the fastest out there. I highly recommend using WireGuard if you need a fast and reliable connection between your home computer and some server on the Internet.

Wi-Fi vs Wired Networking on Raspberry Pi 4

Mon, 06 Jan 2020 00:00:00 +0000

I ran a few tests to find out how to boost network transfer speed on the Raspberry Pi 4, and whether it’s worth the hassle.

TL;DR

Prefer wired connections when it’s not too inconvenient. For maximum data throughput, you should also use an SSD because regular SD cards won’t let you fully utilize the potential of your wired connection.

Preface

The Raspberry Pi 4 is a capable SBC that comes with two built-in network interfaces: Gigabit Ethernet and IEEE 802.11ac Wi-Fi. Having options is good, but it’s also a common source of confusion. Which interface should we use and why?

In this article, I compare wired and Wi-Fi interfaces in terms of their maximum data throughput. If you’re new to networking, you might also benefit from reading about network latency and its role in the performance of networked software. In short, wired connections usually have an order of magnitude better latency than wireless ones, and that might be more important than the amount of megabytes you can push per second. That said, let’s do some tests!

First, it’s good to keep in mind that we can’t trust the benchmarks completely. Real-world performance can depend on many factors, and it’s always a good idea to reproduce the same tests with your own hardware and in your own environment.

Test Structure

Here is what my test does:

Generate 1 GB of random data on my laptop
Send this data to my Raspberry Pi and measure the average speed
Fetch this data from my Raspberry Pi and measure the average speed

I repeated this test with four different configurations:

A Raspberry Pi that uses Wi-Fi and stores data on an SD card
A Raspberry Pi that uses Wi-Fi and stores data on an SSD
A Raspberry Pi that uses Ethernet and stores data on an SD card
A Raspberry Pi that uses Ethernet and stores data on an SSD

That’s it. Now, it’s time to generate that random data.

Generating Test Data

We can use dd to generate a new file and /dev/urandom is a great data source:

dd if=/dev/urandom of=big.file bs=64M count=16 iflag=fullblock

Let’s clarify these arguments and their purpose:

if - input file. In our case, we attach our input to the stream of random data available on any Linux distribution.
of - output file. It’s the name of the file we want to create. Feel free to use any name you want.
bs - in our case, it means that we want to generate our random file piece by piece and there should be count pieces in it. It also means that we can tweak both arguments; the only important thing is that bs * count should be close to our target size (1 GB).
count - as mentioned above, it’s just a multiplier for bs

Testing Data Throughput Over Wi-Fi and Ethernet

Let’s send some data to the Raspberry Pi (Laptop --> Pi):

rsync --progress big.file pi@cloud.local:~/big.file

big.file
  1,073,741,824 100%   32.10MB/s    0:00:31 (xfr#1, to-chk=0/1)

I used rsync because it’s easy to use, and it reflects my real workloads (syncing a lot of files, doing backups and so on).

Now we can download that big file from the Raspberry Pi and measure the average transfer speed (Laptop <-- Pi):

rsync --progress pi@cloud.local:~/big.file big.file.back

big.file
  1,073,741,824 100%   42.69MB/s    0:00:23 (xfr#1, to-chk=0/1)

That’s it. I repeated this test for each of the tested setups, and here are the results:

Results

From	To	Interface	Storage	Speed (Mbit/s)	Speed (MB/s)
Dell XPS 13 (2018)	Raspberry Pi 4	Wi-Fi	SD	58.24	7.28
Dell XPS 13 (2018)	Raspberry Pi 4	Wi-Fi	SSD	55.84	6.98
Dell XPS 13 (2018)	Raspberry Pi 4	Gigabit Ethernet	SD	159.60	19.95
Dell XPS 13 (2018)	Raspberry Pi 4	Gigabit Ethernet	SSD	340.56	42.57
Raspberry Pi 4	Dell XPS 13 (2018)	Wi-Fi	SD	80.72	10.09
Raspberry Pi 4	Dell XPS 13 (2018)	Wi-Fi	SSD	82.00	10.25
Raspberry Pi 4	Dell XPS 13 (2018)	Gigabit Ethernet	SD	339.20	42.40
Raspberry Pi 4	Dell XPS 13 (2018)	Gigabit Ethernet	SSD	341.52	42.69

Interesting results, but let’s try an alternative approach to measuring network throughput before jumping to any conclusions.

Testing Raspberry Pi 4 Throughput With iPerf

We can easily measure “raw” network performance by moving as much data as possible between two computers for a certain period of time. One of those computers has to play the role of a client by generating a lot of gibberish and sending it to the second machine, which can simply discard all of that traffic upon arrival.

There are many ways to perform such a test, but iperf is something of an industry standard, and it’s very easy to use, which makes it a good choice for our quick test.

Let’s make Raspberry Pi 4 a server:

ssh pi@pi.local
sudo apt install iperf
iperf --server

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

Now, we can use iperf from another computer and instruct it to connect to the Raspberry Pi in order to measure the network throughput between them:

sudo apt install iperf
iperf --client pi.local

Client connecting to cloud.local, TCP port 5001
TCP window size: 85.0 KByte (default)

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   942 Mbits/sec

Here are my results for wired and Wi-Fi connections:

Interface	Speed (Mbit/s)
Gigabit Ethernet	942
Wi-Fi (IEEE 802.11ac)	86

Both tests point to the same conclusion.

Conclusion

Although using Wi-Fi is more convenient because it gives you more flexibility, don’t expect your network transfer speed to be anywhere above 86 Mbit/s if you connect your Raspberry Pi wirelessly. 86 Mbit/s is actually not that bad if you use an SD card because many modern SD cards can’t go beyond ~80 Mbit/s when they write data, although they can read a bit faster. Not being able to take advantage of that extra read speed is the main drawback of using Wi-Fi on a Raspberry Pi 4.

Things get a bit different if you prefer to store your data on an SSD. Modern solid-state drives can move gigabytes in seconds, but your Wi-Fi connection wouldn’t let you take advantage of that extra throughput. Switching to a wired connection boosts transfer speed up to about 30-40 MB/s when using rsync, which is better, but still a far cry from the theoretical limit of 125 MB/s (that’s the max speed of a Gigabit Ethernet adapter that is used in Raspberry Pi 4). It might be due to encryption overhead, which puts some pressure on the CPU and makes it a bottleneck. That’s precisely why benchmarking is hard: there are many components that might affect the results.

GL.iNet GL-AR750S-Ext

Sun, 27 Oct 2019 00:00:00 +0000

I wanted to experiment with OpenWRT, so I bought a GL.iNet travel router, mostly out of laziness, since they ship with OpenWRT pre-installed. The choice exceeded my expectations, and I’ve had a lot of fun diving into the configuration.

Having full SSH access to your router is a game-changer for control, though it also comes with the expected slick web interface. But the feature that amused me the most is a dedicated hardware switch on the device itself. Flick it, and it instantly wraps my entire wireless network in a WireGuard VPN tunnel. No software toggles, no app launches, just a physical button for full-network privacy. That’s the kind of thoughtful, practical design I didn’t know I wanted until I had it.