DEV Community: Romeo Mihalcea

Create your own WireGuard server in minutes

Romeo Mihalcea — Sat, 21 Nov 2020 16:04:50 +0000

With the rise in privacy concerns over tech giants battling for our data I thought it would be fit to have a small talk about creating your own VPN server. Now I know there are countless of other tutorials out there but there's never enough attention over this subject.

What is WireGuard

WireGuard is the new kid, the much needed tool in the VPN world to bring everything to the next step. It is a small, fast and effective new VPN protocol that stormed everything since its early days. Very quickly it received great reviews for its performance and it is now included in the new Kernels for Linux and Android. I don't recall ever hearing about any other library to be included so fast in the Kernel so that says a lot I guess.

Wireguard is much leaner and faster when compared with other protocols and this makes it the preferred choice for many. How much faster? You can read our Wireguard vs OpenVPN article to see a comparison of the two.

How much does it cost to own my VPN server

Not much at all - with as much as $5 you can get a good VPS that can host a VPN server which handles the traffic for your entire family without breaking a sweat. Creating a server used to be a challenge but now, you can do it in 2 minutes. I suggest having a look at Digitalocean, Linode, Hetzner Cloud and others alike. Plenty of options.

My own server vs a VPN plan

Simply because we cannot trust anybody. Most of the VPN providers have to abide the law which in many cases imposes that logs are kept and offered to gov. institutions for analyzing. We're trying to avoid being processed and analysed at every move so, sending our entire data stream to a VPN provider is nothing more than just adding an extra hop in the same chain.

Having your own VPN server will break this chain and put a stop to the leak of data that we experience with ISPs or VPN providers and the process is simple. You can either let others create a secure VPN server for you or build it yourself following guides like this one.

How to create a WireGuard server

First of all, WireGuard does not have the notion of "servers". Everything is a peer and peers are connected with one another. The config files consist of 2 parts: an [Interface] which addresses the local instructions and multiple [Peer] sections which define remote connections.

What operating system to use?

I recommend Debian, the latest you can find with the selected provider. I will use Debian 10 (Buster) for this tutorial.

The first thing to do is to go ahead and add the Wireguard release channel to your sources list. The sources are like search channels for software and, without them, your operating system cannot find anything:

$ sudo sh -c "echo 'deb http://deb.debian.org/debian/ unstable main' >> /etc/apt/sources.list.d/unstable.list"
$ sudo sh -c "printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' >> /etc/apt/preferences.d/limit-unstable"

Now issue an apt update command to re-fetch the sources and we should be able to install Wireguard with apt install wireguard.

[SERVER] Create your keys

Peers connect via IP addresses but they have to authenticate before a connection can be established. Keys come in pairs (public and private) and each peer must know the other peers beforehand which means writing down to the config file the public key for each peer.

With the install of Wireguard we now have access to the wg and wg-quick commands which allows us to create our keys:

$ (umask 077 && wg genkey > wg-private.key)
$ wg pubkey < wg-private.key > wg-public.key

If you run ls -la you will see the keys have been created. You can also run cat wg-private.key to view the contents of each file.

[SERVER] Create the config file

Now that we have the keys we are almost done setting up the server. We have to create the config file and bring up the VPN interface that will listen on the selected port.

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = server+private+key+here
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

The only thing you have to change here is the eth0 interface name. On some systems it may have a different name. To get yours you can execute this handy command: route | grep '^default' | grep -o '[^ ]*$'

We have created the server config but haven't added any peers yet. That's because we need to generate the keys for the client now so we can add them to our peers list. The server will listen on the private address 10.10.0.1. You may be wondering what is the purpose of the public key because we haven't used it yet. It will be added to the client config in our next steps.

The PostUp and PostDown instructions are executed when the server is started and stopped and they enable IP forwarding so that you can exchange packets with your server. IP forwarding must also be enabled on the server by editing the */etc/sysctl.conf file and adding:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

[CLIENT] Create keys

We also need the client keys so we can add authenticated peers to the server. Repeat the steps from the server in order to generate keys but this time on the local machine. If you're on windows or MacOS you can download the Wireguard gui package and copy the keys from there.

[CLIENT] Create config file

Once you have the keys we can create the local configuration file:

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.2/24
PrivateKey = client+private+key+here
DNS = 10.10.10.1

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = server_ip_address:51820

Our client config is done. It has a local description ([Interface]), it will be allocated the 10.10.10.2 address, that's the next address after the server and it also forwards dns queries to the server.

The [Peer] in this case is the server so, before attempting a connection, we also add a peer to the server that contains our public key otherwise our connection will be refused.

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = server+private+key+here

[Peer]
PublicKey = client+public+key+here
AllowedIPs = 10.10.10.2/32

Time to bring up the server: wg-quick up wg0.
To bring it up automatically after restart (at boot): systemctl enable wg-quick@wg0

Connect to the server

With all peers defined and keys ready to be exchanged it is now time to connect to our server. Remember that wireguard is stateless and it will probably report a successful connection even though it is not. You should test your IP address, dns leaks and other stuff to verify the connection was made.

CNAME cloaking or how are we being tracked even with ad-blockers installed

Romeo Mihalcea — Mon, 09 Mar 2020 15:47:24 +0000

For many years we relied on regular ad blockers to clean our screen from ads, trackers and other junk but there's a way that these websites use to bypass our efforts and it works very well.

Regular ad blockers intercept your browser's requests and analyze each one to see if there are matching rules against it. The flaw is in this technique because the extension only has access to the first party (the requested url) without being able to monitor what is taking place once a request does not match any of its rules - at the DNS level for example.

In this post I'm going to explain how one can mask/cloak a tracking domain behind some DNS trickery, bypassing browser based ad-blockers. It takes only a few minutes to buy a new domain and setup a CNAME alias to achieve this masking technique so it is very easy.

A CNAME is a domain that points to another domain, an alias. You can think of it as a permanent redirect but executed at the DNS level. Many tools rely on CNAMEs to serve content and I'm going to pick Netlify as an example here. Our blog is hosted on Netlify. Each deployed website is assigned a unique subdomain in the form of unique-subdomain.netlify.com. In our case it is festive-nobel-876c06.netlify.com and you can try it in your browser to see it works.

If you want to use your own domain (of course you are) for this address (blog.dnsadblock.com) you need to point it to festive-nobel-876c06.netlify.com using a CNAME.

Presuming that festive-nobel-876c06.netlify.com is serving some tracking scripts and it is being blocked by ad blocking extensions I can simply alias a new domain to it and import the script using it:

<script src="https://blog.dnsadblock.com/itrackyou.js"></script>

Since festive-nobel-876c06.netlify.com appears only after the request was allowed (when the DNS is being resolved) it will pass without issues:

$: dig blog.dnsadblock.com

;; ANSWER SECTION:
blog.dnsadblock.com.    103 IN  CNAME   festive-nobel-876c06.netlify.com.
festive-nobel-876c06.netlify.com. 20 IN A   157.230.120.63

So how can we combat these techniques? Are ad-blockers dead? Not really. I know they are trying hard to kill or limit ad-blockers but they are still effective. The solution is to combine multiple tools. Our ad blocking DNS servers are monitoring and testing rules against CNAME aliases as well so this technique won't fly.

If you are curious to see just how much tracking takes place on a regular machine have a look at this screenshot. This is my computer and I'm using dnsadblock only on it. This screenshot only reflects my activity and you can also see periods of inactivity when I'm testing other DNS servers so the numbers could be higher.

Deploy a blazing-fast, feature-rich and free to use website with a blog in under 10 minutes

Romeo Mihalcea — Thu, 03 Jan 2019 02:39:10 +0000

2018 was a great year for me as a developer. I managed to put together an open-source project (still under heavy development) that was sitting on the back of my mind for many years.

I don't know about you but, as a programmer that is comfortable with both the backend and frontend, I'm always testing new ideas, apps and websites. Doing so for years and years I noticed a repetitive task that was getting quite annoying. Each of my projects required a presentation website with a blog where I get to talk about it in more detail.

That means at least one web server with a database attached. It's not hard but takes a lot of time that I would rather spend on something else instead so I stopped and brainstormed my next project that would end this repetitive cycle of costly deployments.

Every good house starts with a strong foundation

My framework of choice was Gatsby. It had most of the things that I would consider to be required:

it has to compile to static files
easy to deploy to a CDN such as Netlify
image optimization in place
vibrant community
hackable because I like to get my hands dirty
extensible via plugins
uses GraphQl to fetch data

    query($slug: String, $tags: [String], $categories: [String]) {
        post: markdownRemark(fields: { slug: { eq: $slug } }) {
            ...postFragment
        }
    }

The result had to be something oriented towards programmers. I hate wysiwyg editors with a passion because there are many constraints and the output never seems to be predictable. I wanted something where I put the power of the framework at reach for both the developer and content editor.

Developers and Publishers express without barriers

Slowly but surely Qards took shape. My goal was to give more power to the writer by using, what I like to call, "smart cards". The content editor should be able to create interactive presentations using widgets that respond to events, to dates, to browser types, regions or any other external factors that can be made available to a frontend engineer. Some of those widgets include:

automatically generated toc (table of contents) (developed)
charts (planned)
accordions (developed)
images (developed)
galleries (developed)
video embeds (developed)
audio playlist (developed)
code blocks (developed)
callouts (developed)
countdowns (developed)
grid lists (planned)
references to other posts (developed)
etc

One other must-have for such a platform was the ability to add custom widgets via an internal plugin system (still under development/planned). The developer creates directives and data requirements which are interpreted by the admin interface (Netlify CMS) where the content publisher is able to create those experiences. That's right, let's navigate from simple posts to "experiences" for our visitors. We're all affected by bounce rates that connect directly with dull interfaces.

Let's get the word out

One month later into the project I had a clear path and an idea that was no longer just a blurry shape. I like to test such things before an official launch by putting it out there on ProductHunt and other similar platforms.

Qards was quickly picked-up and got to 2nd place for that day which was not bad at all for something which was not even in an alpha stage.

The feedback was more than helpful and my mailing list reached 2,000+ in one night so it was a productive experience for me. That's everything I needed to validate my project. I was going to use it anyway but I wasn't sure if I could make something for the general public out of it.

More than just a blog

I may be advertising a blog but Qards is more than that. Being powered by Gatsby, it can be your next big project...with a blog. You simply get the added benefit of not having to worry about content any more.

In summary

In summary I would like to recap everything that Qards is and does so here's a list of all the parts that make this project work:

powered by Gatsby and Netlify CMS, comes with all benefits
free to use and free to deploy to Netlify or other CNDs (free SSL as well)
rich, interactive widgets to keep your readers engaged
more power to the content editors (think of it like Bootstrap for publishers)
compiles to static files
offline support
pluggable
extensible
hackable
free to use and develop with 0 restrictions
- code/content sits on Github or Gitlab
- static files are served by any CDN you can think of
open source
tested (work in progress)
developer oriented
developed in Typescript
blazing fast
appealing default design
themable
deployable and ready to publish in under 10 minutes
markdown content
progressive loading, image optimization and lazy loading of content
un-hackable, always on production deployments
awesome performance index

If I managed to spark your interest please have a look at Some of the supported cards to get a feel of what this project can do for you.

Also, it's still an early phase so AMA and feel free to suggest new things.