The first thing I noticed was that ethX renamed to enXY.

To get back to the old naming scheme, you can fix this by adding the following in /etc/network/interfaces:

rename enX0=eth0
rename enX1=eth1

And reboot.

Most of this can be copied from the amd64 post -- with a minor change for making it work on RPi4. This is the full git repo (including both rpi and amd64).

The main difference is in the run.sh file. The installation is a bit different and we'll need to install the Raspberry Pi kernel headers.

WireGuard is also installed from testing instead of Debian backports.

Note that for older RPi's (ie gen 1) you'll need to compile from scratch.

Setting up dkms (2.6.1-4) ...
Setting up wireguard-dkms (1.0.20200429-1~bpo10+1) ...
Loading new wireguard-1.0.20200429 DKMS files...
It is likely that 4.19.0-8-cloud-amd64 belongs to a chroot's host
Building for 4.19.0-8-amd64 and 4.19.0-8-cloud-amd64
Building initial module for 4.19.0-8-amd64
Error! Bad return status for module build on kernel: 4.19.0-8-amd64 (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200429/build/make.log for more information.
dpkg: error processing package wireguard-dkms (--configure):
 installed wireguard-dkms package post-installation script subprocess returned error exit status 10
Setting up build-essential (12.6) ...
Setting up libalgorithm-diff-xs-perl (0.04-5+b1) ...
Setting up libalgorithm-merge-perl (0.08-3) ...
dpkg: dependency problems prevent configuration of wireguard:
 wireguard depends on wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219); however:
  Package wireguard-dkms is not configured yet.
  Package wireguard-modules is not installed.

dpkg: error processing package wireguard (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (241-7~deb10u3) ...
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 wireguard-dkms
 wireguard
E: Sub-process /usr/bin/dpkg returned an error code (1)

The solution was to install bc. Seems like Debian is not pulling the right dependencies. I'll be adding it to my Dockerfile.

So I am running two WireGuard servers -- one on a Raspberry Pi 4, and one in an amd64 virtual machine. This post will be about getting WireGuard working on amd64 in a Docker container.

As this container rarely get rebuild, I am running unattended-upgrades inside the container to make sure security updates are applied.

I am also running Bind9 to act as a caching DNS server inside the container. Ideally this should be running from its dedicated container but that makes everything more complicated and not worth it for what I am trying.

I am also

The public repo that acts as a proof of concept can be found here.

start.sh -- this file starts (or restarts) and builds the container. It will also create the files as needed, set the forwarding DNS server, etc.

Dockerfile -- the example will start a basic container based on debian-slim, set up the port forwarding, install the tools we need, and copy over the configs

run.sh -- this file will be executed after the container has been built. We need to install WireGuard from this file or it will fail due to the volume not being mounted and not having the right params.
This will also start the named (bind9) server.
I manually set ip address add dev wg0 10.200.200.1/24 because using Address in wg0.conf caused issues. I haven't recently tested if that's still the case.

named.conf.options -- pretty standard bind9 config file; I want to be in control of my forwarding server because I am using NextDNS and want to apply a different config.

And of course your wg0.conf.

Running docker exec wireguard wg should give details about your connected hosts.

I've been running WireGuard for a few months now and I've been loving it.

I first started using it about a year ago when in China — OpenVPN was once again being actively blocked and it was driving me nuts. Overnight I set up a DigitalOcean server in Singapore and ran WireGuard from it — both my phone and laptop were able to actively bypass the GFW and (at that time) surf the internet freely once more. As WireGuard gains popularity, I am sure the GFW will start detecting it — it's a quiet but not a stealthy protocol.

Since then I've dug quite a bit deeper in WireGuard and am really looking forward to what it's going to bring.

WireGuard differentiates itself to be an extremely simple VPN server (which can make getting started and debugging a bit more challenging) — but it wants to seamlessly work together with existing tools. One of the main features still missing is for example running a DHCP server on the server and dynamically assigning IPs (like oVPN does).

It's also pretty cool because any node can both be a server and a client at the same time. In my setup I am running two servers: one running at home in Singapore on a RPi4 (1Gbit fiber connection) and one on a virtual machine in Amsterdam (1Gbit as well). The RPis at my parents are connected to the server in Amsterdam, my iPad and phones are connected to the server in Singapore. If I am in Europe I might switch over and let my iDevices connect to the AMS server instead.

The example above clearly shows speed gains by cloaking the traffic in UDP packets. The shared folder has only two nodes (sender and receiver) and shows several big files being transferred from Amsterdam to Singapore. Resilio Sync uses the Bittorrent protocol, something ISPs generally hate and tend to slow down as much as they can — thanks Starhub.

Wireguard also allows the client to decide what to route through the server: only the VPN LAN traffic, or a whole subnet, or 0.0.0.0/0? So for my iPhone I for example route all traffic through VPN to avoid hotel/airport/... WiFi's to mine/log/scan my data. For my laptop I have two configs, one to only connect to the LAN, but another that routes all my traffic through the VPN if I want to avoid exposure or circumvent censoring.

Note that I am not running WireGuard to remain anonymous and I'll definitely leak some information — just trying to minimise and remain in control of what I leak. This is not a Tor replacement.

Shell servers... so 2005. I remember in the good old IRC days people asking for (free) shell servers to run their eggdrop and stuff. OMG am I getting old? Anyhow...

I ssh quite often. I manage quite a few servers (~15?) and routers that require me to login and do some random stuff. I also work on a laptop quite often and that means closing the lid and moving around.

First of all, mosh is amazing and allows you to stay connected via ssh, even with crappy (airport/hotel) internet as well as moving around networks -- that solves half the problem. If you are not using it, start using it now!

Second, during my datacenter technician days at Google we used to have a "jump server" -- a shell server that allowed us to bridge the corporate network and ssh into prod machines. Doubt that's still used nowadays, but the idea stuck. I wanted something similar to ssh from, wherever I was, and easily connect to my servers. And as the network the shell server is running on is stable, I only need to use mosh to the shell server. Thereafter, the connection very rarely dies.

And I guess, third, I recently purchased an iPad Pro and I really need to have my local "dev" environment with my git repo that I edit quite frequently but iPadOS isn't really your average computer, and doesn't even have a proper terminal. This is my experiment to make iPadOS work as a main computer when on the move.

Enter box -- Docker shell server...

I've copied over the files I use to this example repo, and added some comments. Mind you that this repo acts as a proof of concept and isn't kept up to date, as I have my own private repo -- but this should give you a good idea on how to set up your own shell server with Docker.

start.sh -- this is a simple script that I execute when I first run or need to update the container. I execute the same file on two different servers: Liana, my Raspberry Pi at home and Ocean, my server in Amsterdam.

zsh.sh -- this installs what I care about for zsh. This could be part of the Dockerfile but for some reason I separated it. ¯\_(ツ)_/¯

git.sh -- this clones my Git repos so I can edit and commit stuff from the shell server.

run.sh -- this file is launched by Dockerfile at the end and executes what matters: the ssh daemon. It also adds a Wireguard route and executes the scripts above.

Dockerfile -- this installs everything I need and configures the whole thing. I've added tons of comments that should get you going.

I am also cloning misc and homefiles as submodules in files/ -- but you should change this to something that works for you. See the Dockerfile for more info.

Couple of weeks ago I started to play with NextDNS -- and I really recommend anyone that's something privacy minded and cares about the stuff happening on their network.

I've set up several configs (home, parents, FlatTurtle TurtleBox (the NUCs controlling the screens)) and Servers. Once it's out of beta and better supported on Unifi and Ubiquiti hardware I might deploy it to our public WiFi (well, most access points don't look like that -- but you get the point) networks too.

Looking at the logs was an eye-opener seeing what goes through your network. You can play around and block (or whitelist) certain domains.

I figured out my Devialet does an insane amount of requests to cache.radioline.fr for example. This domain has a 30s TTL. It shows that the majority of my DNS requests are actually automated pings and not in any way human traffic.

Anyhow -- I've since installed the NextDNS CLI straight on my EdgeRouter Lite acting as a caching DNS server and forwarding using DoH.

I've turned off dnsmasq (/etc/default/dnsmasq => DNSMASQ_OPTS="-p0") and have NextDNS listen to :53 directly.

Note that every EdgeOS update seems to wipe out the NextDNS installation, and requires a fresh install... Pain in the ass and doesn't seem like that's fixable.

This is my ERL NextDNS config (/etc/nextdns.conf)

hardened-privacy false
bogus-priv true
log-queries false
cache-size 10MB
cache-max-age 0s
report-client-info true
timeout 5s
listen :53
use-hosts true
setup-router false
auto-activate true
config 34xyz8
detect-captive-portals false
max-ttl 0s

The explanation of every flag is explain on their Github page and they are very responsive via issues or through their chat on my.nextdns.io.

All right -- next thing I've noticed is that my Google Home devices are not sending any DNS requests -- which means the devices use hard coded DNS servers.

I have a separate vlan (eth1.90) for Google Home (includes my Android TV, OSMC, Nest Home Hub and all other GHome and Chromecast devices). For this vlan I set up a deflector to be able to cast and ping/ssh from my "main" network/vlan to GHome vlan.

Using this guide I redirected all external DNS traffic to the ERL so I can monitor what's happening. The important part was the following:

yeri@sg-erl# show service nat rule 4053
destination {
port 53
}
inbound-interface eth1.90
inside-address {
address 10.3.34.1
port 53
}
protocol tcp_udp
type destination

This allows to "catch" all UDP and TCP connections to :53 and redirect them the ERL DNS server (10.3.34.1). The GHome devices were acting a bit weird after committing the change, but a reboot of the device fixed it.

Note that you need to set this up per vlan. If you want to catch DNS requests for your Guest or IoT vlan, you'll need to do the same.

Using 2Gb of RAM seems to do the trick.

On a Debian machine.

The solution was changing PCI slot , blowing away all the dust in the mobo PCI slot and on the pins of the PCI card, and gently inserting and removing it a couple of times.

After that it worked correctly.

Using two of them (and my Guruplug as WiFi AP) I connected my new apartment with my old house (= parents) over VPN.

This way I can access the printers/scanners and NAS at home.

The 2 rPI’s are used as router (using a Macbook Air USB-to-Ethernet adapter as 2nd ethernet (eth1) port). Basic howto’s are easily found using Google to do this (a good starting point).

I made my own installation of Raspbian (as the downloadable image contains too much crap), details here (actually not that easy to find when Googling for bootstrap raspbian etc).

I’ve connected three different LANs over an OpenVPN connection:

• LAN1 (home): 192.168.1.0 (Gateway: 192.168.1.1, VPN ip: 10.9.8.254)
• LAN2 (apartment, ethernet): 10.60.111.0 (Gateway: 10.60.111.1, VPN ip: 10.9.8.250)
• LAN3 (apartment, wifi): 10.10.10.0 (Gateway: 10.10.10.1, VPN ip: 10.9.8.246)

OpenVPN range: 10.9.8.0. The subnet is 255.255.255.0 in all cases.

LAN3 is connected via LAN2 to the internet. So the default gateway of router 10.10.10.1 is 10.60.111.1.

The gateway/routers are all Debian-based Linux systems. I’m using EDPnet as ISP, and thus need to use those Sagem/Belgacom approved routers (BBox-2 hardware). These Sagems are set in bridged mode, and don’t do the PPP stuff. PPPoeconfig on Debian takes care of most of the stuff. As EDPnet provides ipv6, I can ping6 from those routers.

The idea is to connect/ping each and every LAN from any of the clients connected the LANs (without running OpenVPN on the clients; only run it on the gateways).

For example: my PC with ip 10.10.10.15 wants to connect to the NAS with ip 192.168.1.100.

This can easily be achieved by setting a client-config-dir in the openvpn.conf file (or whatever the name of your config):

client-config-dir /etc/openvpn/tiete

And don’t forget to add route pushes:

push "route 192.168.1.0 255.255.255.0"
push "route 10.60.111.0 255.255.255.0"
push "route 10.10.10.0 255.255.255.0"

But here comes the annoying part. As I’m pushing routes 10.60.111.0 via VPN, which is supposed to be my Guruplug’s default gateway as well (ISP > eth0:RaspberryPi:eth1 > eth0:Guruplug, remember?) this was causing quite some routing fuck ups.

The easiest way to solve this was to turn off VPN on the Guruplug all together, and route 10.10.10.0 over the Raspberry Pi, by adding this line to /etc/network/interfaces:

up route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.60.111.2 dev eth1

Then I’ll change the client specific configs on the VPN. Create a file in whatever you picked as client-config-dir, and name it the actual VPN name (the name used when creating the key).

As I have three routers, I created three files (sheeva for my guruplug, Pi for my first rPI and Industry for my 2nd. Yep… Fancy names).

I also want to give a static IP address to the gateways, so I use the option:

ifconfig-push 10.9.8.<valid-ip> 10.9.8.<valid-ip - 1>

And I’ll also add the iroute option to push routes.

This is what it looks like for the router on the 192.168.1.0 network (“Pi”):

ifconfig-push 10.9.8.254 10.9.8.253
iroute 192.168.1.0 255.255.255.0

For “Sheeva”, the WiFi AP on 10.10.10.0:

ifconfig-push 10.9.8.246 10.9.8.245

And for 10.60.111.0 plus 10.10.10.0 routed over 10.60.111.0 (“Industry”):

ifconfig-push 10.9.8.250 10.9.8.249
iroute 10.60.111.0 255.255.255.0
iroute 10.10.10.0 255.255.255.0

And don’t forget to set up masquerading over tun0 (or tun+) with iptables.

Now… Oddly enough, this didn’t require that much configuration, cursing and stress… And, well, it kind of just works.

From my Mac to my NAS:

nazgul ~ $ traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 64 hops max, 52 byte packets
 1 sheeva (10.10.10.1) 1.936 ms 1.159 ms 0.800 ms
 2 10.60.111.1 (10.60.111.1) 1.456 ms 1.776 ms 1.539 ms
 3 10.9.8.254 (10.9.8.254) 55.745 ms 55.046 ms 54.734 ms
 4 192.168.1.100 (192.168.1.100) 62.302 ms 55.327 ms 54.795 ms

From Pi (gateway 192.168.1.1) to nazgul, my Mac:

pi ~ # traceroute 10.10.10.15
traceroute to 10.10.10.15 (10.10.10.15), 30 hops max, 60 byte packets
 1 10.9.8.250 (10.9.8.250) 65.892 ms 74.177 ms 73.957 ms
 2 10.60.111.2 (10.60.111.2) 73.441 ms 72.902 ms 72.342 ms
 3 10.10.10.15 (10.10.10.15) 71.780 ms 71.187 ms 70.760 ms

From Heartbeat (10.9.8.102), my Munin stats server to the printer:

heartbeat ~/bin # traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 30 hops max, 60 byte packets
 1 pi (10.9.8.254) 39.835 ms 40.794 ms 41.567 ms
 2 192.168.1.90 (192.168.1.90) 41.541 ms 42.452 ms 43.307 ms

From Heartbeat to Sheeva’s eth0 IP:

heartbeat ~/bin # traceroute 10.60.111.2
traceroute to 10.60.111.2 (10.60.111.2), 30 hops max, 60 byte packets
 1 industry (10.9.8.250) 32.716 ms 32.615 ms 34.359 ms
 2 sheeva (10.60.111.2) 34.405 ms 34.349 ms 35.014 ms

From Heartbeat to an Android device (not sure why the latency spike):

heartbeat ~/bin # traceroute 10.10.10.72
traceroute to 10.10.10.72 (10.10.10.72), 30 hops max, 60 byte packets
 1 industry (10.9.8.250) 31.337 ms 32.269 ms 32.218 ms
 2 sheeva (10.60.111.2) 33.006 ms 33.052 ms 32.996 ms
 3 10.10.10.72 (10.10.10.72) 471.564 ms 472.169 ms 473.082 ms

Next up (once I have spare time): try to sync local DNS and fix local ipv6.

I’ll put most of the configs on Github at some point.

Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb --with-mysql-dir=/usr/include/mysql
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lmygcc... no
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/bin/ruby1.8
--with-mysql-config
--without-mysql-config
--with-mysql-dir
--with-mysql-include
--without-mysql-include=${mysql-dir}/include
--with-mysql-lib
--without-mysql-lib=${mysql-dir}/lib
--with-mysqlclientlib
--without-mysqlclientlib
--with-mlib
--without-mlib
--with-mysqlclientlib
--without-mysqlclientlib
--with-zlib
--without-zlib
--with-mysqlclientlib
--without-mysqlclientlib
--with-socketlib
--without-socketlib
--with-mysqlclientlib
--without-mysqlclientlib
--with-nsllib
--without-nsllib
--with-mysqlclientlib
--without-mysqlclientlib
--with-mygcclib
--without-mygcclib
--with-mysqlclientlib
--without-mysqlclientlib
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.8.1 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.8.1/ext/mysql_api/gem_make.out

Can be solved by installing libmysqlclient15-dev

# apt-get install libmysqlclient15-dev

Here are some examples:

Zero - One - Four - vm1 - Sauron

The config files:

Sauron (including Squid stats),

Zero (including fan stats).

List of files included:

• indexmaker; simple script (included with MRTG) to generate a simple index file with all the graphs
• snmp-if.sh; will show you the IDs of the interfaces on the server/pc. These IDs have to be edited in the mrtg.cfg file; e.g.:

Target[eth0]: 2:public@localhost:

Make sure 2 is indeed the ID of eth0. Be aware that virtual interfaces, like the TUN/TAP interfaces (using by openVPN for example), can change ID each time they are restarted/rebooted.

• mrtg.cfg; check the config file as an example.

Some day, I’ll write a decent howto, but for now, you’ll have to do with this.

If there’s any question, just leave a comment.