alastair87/nordlynx

Quick reference

Maintained by: Julio Gutierrez
Where to get help: Github discussions

Supported tags

edge (updated weekly)
latest (updated monthly)
YYYY-mm-dd (created monthly)

Quick reference (cont.)

Where to file issues: Github issues
Supported architecture: (more info) amd64, arm32v7, arm64
Published image artifact details: DockerHub, Github packages
Continuous integration: Github actions
Source: Github

What is NordLynx?

NordLynx is a technology built around the WireGuard® VPN protocol. It lets you experience WireGuard’s speed benefits without compromising your privacy. You can find more information about NordLynx in this blog post.

What is WireGuard?

WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.

Road warriors, roaming and returning home

If you plan to use Wireguard both remotely and locally, say on your mobile phone, you will need to consider routing. Most firewalls will not route ports forwarded on your WAN interface correctly to the LAN out of the box. This means that when you return home, even though you can see the Wireguard server, the return packets will probably get lost.

This is not a Wireguard specific issue and the two generally accepted solutions are NAT reflection (setting your edge router/firewall up in such a way as it translates internal packets correctly) or split horizon DNS (setting your internal DNS to return the private rather than public IP when connecting locally).

Both of these approaches have positives and negatives however their setup is out of scope for this document as everyone's network layout and equipment will be different.

Usage

Here are some example snippets to help you get started creating a container.

docker-compose (recommended, click here for more info)

---
version: "3"
services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx
    cap_add:
      - NET_ADMIN #required
    environment:
      - PRIVATE_KEY=xxxxxxxxx #required

docker-compose (using secret)

version: "3.9"
services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx
    cap_add:
      - NET_ADMIN #required
    environment:
      - PRIVATE_KEY_FILE=/run/secrets/privatekey
    secrets:
      - privatekey 
secrets:
  privatekey:
    file: ./privatekey.txt

docker cli (click here for more info)

docker run -d \
  --cap-add=NET_ADMIN #required \
  -e PRIVATE_KEY=xxxxxxxxx #required \
  ghcr.io/bubuntux/nordlynx

Review the wiki for more practical usages and host specific instructions.

Module

Wireguard module is required, please install it manually if need it.

Environment

Variable	Default	Description
`PRIVATE_KEY`	[Required]	The private key can be obtained using `docker run --rm --cap-add=NET_ADMIN -e USER=XXX -e PASS=YYY bubuntux/nordvpn:get_private_key` or following these instructions.
`PRIVATE_KEY_FILE`		File from which to get PASS, if using docker secrets this should be set to /run/secrets/<secret_name>. This file should contain just the account password on the first line.
`LISTEN_PORT`	51820	A 16-bit port for listening.
`INTERFACE`	eth0	The network interface to use inside the container.
`ADDRESS`	10.5.0.2/32	A comma-separated list of IP (v4 or v6) addresses (optionally with CIDR masks) to be assigned to the interface.
`DNS`	103.86.96.100 103.86.99.100	A comma-separated list of IP (v4 or v6) addresses to be set as the interface's DNS servers, or non-IP hostnames to be set as the interface's DNS search domains.
`TABLE`		Controls the routing table to which routes are added. There are two special values: `off` disables the creation of routes altogether, and `auto` (suggested for most users) adds routes to the default table and enables special handling of default routes.
`ALLOWED_IPS`	0.0.0.0/0	A comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed. For Synology, read this.
`PERSISTENT_KEEP_ALIVE`	25	A second interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently.
`PRE_UP`/`POST_UP` `PRE_DOWN`/`POST_DOWN`		Script snippets which will be executed by bash before/after setting up/tearing down the interface, most commonly used to configure custom DNS options or firewall rules. The special string `%i` is expanded to INTERFACE. For Synology, read this.
`QUERY`		Query for the api nordvpn
`PUBLIC_KEY`		Public key of the server to connect (auto select base on recommendation api).
`END_POINT`		Ip address of the server to connect (auto select base on recommendation api).
`ALLOW_LIST`		List of domains that are going to be accessible outside vpn (IE rarbg.to,yts.mx).
`NET_LOCAL`		CIDR networks (IE 192.168.1.0/24), add a route to allows replies once the VPN is up.
`NET6_LOCAL`		CIDR IPv6 networks (IE fe00:d34d:b33f::/64), add a route to allows replies once the VPN is up.
`RECONNECT`		Time in seconds to re-establish the connection.
`TZ`	UTC	Specify a timezone to use EG Europe/London.

Sysctl

net.ipv4.conf.all.src_valid_mark=1 May be required. (depends on multiple factors)
net.ipv6.conf.all.disable_ipv6=1 Recommended when only using ipv4.

alastair87 / nordlynx