Why WireGuard?

While most modern routers support OpenVPN and WireGuard protocols, the latter is faster and more efficient when traveling through the encrypted tunnels, providing a superior VPN experience.

Why This Extra Step When Using NordVPN?

Unlike other VPN providers, NordVPN builds its proprietary solution, NordLynx, on WireGuard. Thus, it is not possible to configure it directly on your router unless you want to rely on the slower OpenVPN.

Prerequisites

• A NordVPN customer.
• A router that supports WireGuard VPN protocol.
• An environment to run Linux commands. Install jq if it doesn’t exist.
• Expert in CMD/CTRL+C and CMD/CTRL+V.

Step 1: Generate Access Token in NordVPN

• Go to this NordVPN link.
• Click on the Set up NordVPN manually button.

• After completing the email verification, you will land on a page that allows you to generate an access token. Click on the Generate new token button.

• Leave the token expiration as is. Click on the Generate token button.

• Copy the access token to a text file and close the pop-up dialog.

Step 2: Use NordVPN APIs to Extract WireGuard Configuration

Fortunately, NordVPN provides a helpful Rest API that returns a list of recommended servers based on your current location. We can use this to query for a list of WireGuard-compatible servers.

#!/usr/bin/env bash

ACCESS_TOKEN="[YOUR-ACCESS-TOKEN]"
TOTAL_CONFIGS=3
DNS="1.1.1.1"

CREDENTIALS_URL="https://api.nordvpn.com/v1/users/services/credentials"
SERVER_RECOMMENDATIONS_URL="https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=$TOTAL_CONFIGS"

PRIVATE_KEY=$(curl -s -u token:"$ACCESS_TOKEN" "$CREDENTIALS_URL" | jq -r .nordlynx_private_key)

curl -s "$SERVER_RECOMMENDATIONS_URL" | \
  jq -r --arg private_key "$PRIVATE_KEY" --arg dns "$DNS" '
    .[] |
    {
      filename: (.locations[0].country.name + " - " + .locations[0].country.city.name + " - " + .hostname + ".conf"),
      ip: .station,
      publicKey: (.technologies | .[] | select(.identifier == "wireguard_udp") | .metadata | .[] | .value)
    } |
    {
      filename: .filename,
      config: [
        "# " + .filename,
        "",
        "[Interface]",
        "PrivateKey = \($private_key)",
        "Address = 10.5.0.2/32",
        "DNS = \($dns)",
        "",
        "[Peer]",
        "PublicKey = " + .publicKey,
        "AllowedIPs = 0.0.0.0/0, ::/0",
        "Endpoint = " + .ip + ":51820"
      ] | join("\n")
    } |
    "echo \"" + .config + "\" > \"" + .filename + "\""
  ' | sh

Required Changes:

• Line 3: Replace [YOUR-ACCESS-TOKEN] with the access token you have just copied.

Optional Changes:

• Line 4: By default, this script generates 3 different WireGuard config files based on your location. If one of the servers is oversaturated, you can point to a different server next time without rerunning the script.
• Line 5: Currently, I use CloudFlare DNS (1.1.1.1) since it has the fastest response time. However, you can update it to point to your favorite DNS server, for example, Google’s 8.8.8.8.

Other Helpful Explanations:

• Line 10: Retrieve your private key.
• Line 12: Retrieve the recommended WireGuard-compatible servers based on your current location and generate the WireGuard config files.

Suppose you plan to travel to a different location with your travel router. In that case, typically, you want to pre-configure your travel router with the nearest WireGuard servers based on your destinations before departing. To do this, you can choose a desired location in the NordVPN software installed on your current machine before rerunning this script. For example, you might pick Finland because you fancy eating the delicious Kaalikääryleet that you can’t pronounce. Still, you want to do it safely before Instagramming it in real-time during your long weekend.

After running the script, you should see 3 WireGuard configuration files created.

$ ls -a | cat                                                                                ✔ 
.
..
Finland - Helsinki - fi183.nordvpn.com.conf
Finland - Helsinki - fi195.nordvpn.com.conf
Finland - Helsinki - fi198.nordvpn.com.conf
nordvpn-wireguard.sh

Step 3: Configure WireGuard on Router

The following instructions apply to the GL.iNet travel routers, in my case, Beryl AX (GL-MT3000). Follow your router’s instructions as needed.

IMPORTANT: Before proceeding, ensure you have disabled the VPN from your machine so that it relies on the VPN configured on the travel router based on the steps below.

• Change your SSID to point to your travel router.
• Go to http://192.168.8.1/
• Log into the Admin Panel.
• Go to VPN > WireGuard Client.

• Upload the WireGuard configuration files. Rename the New Provider group to NordVPN to make it more meaningful.

• Pick a server and click Start.

• After a few seconds, the icon should change from orange to green.

• Go to https://whatismyipaddress.com/ to verify your IP. The IP should point to your VPN server’s location.

• Enjoy your Kaalikääryleet!

The post NordVPN: Extracting WireGuard Configuration appeared first on My Shitty Code.

Table of Contents

This post shows how you can use Rclone to back up your data from a Synology NAS to a storage bucket in GCP.

Why Backing Up Synology NAS

Backing up data is like wearing a seat belt when driving, where nothing bad happens 99% of the time. However, when the 1% strikes unexpectedly one day, the “future” you will be grateful that you do not lose any precious data, such as childhood photos, important documents, etc.

When you own several machines at home, it makes sense to centralize the shared data in a local NAS, such as Synology NAS. You may also configure Time Machine to seamlessly back up each Mac to Synology NAS every weekend. It is equally important to back up the data in Synology NAS to the cloud. Your car’s seat belt might be faulty, but you still have an airbag. If a thief breaks into your house, steals your shiny NAS, and burns your house down, you still have your data in the cloud.

The moral of the story is always to back up your data, preferably using the 3-2-1 rule.

Why Rclone

The most confusing part of the Synology NAS backup process is there are several ways to do this. The three popular solutions are Cloud Sync, Hyper Backup, and Rclone. Each solution allows us to push data to various cloud providers. This Reddit post nicely sums it all up. If I can summarize the most significant disadvantage of each solution in a few words, it will be:

• Cloud Sync silently ignores file names with unsupported characters.
• Hyper Backup landlocks you to Synology solution because you can’t browse the backed-up files in the cloud.
• Rclone doesn’t have a pretty GUI.

Rclone seems more palatable among these solutions because I know all my data will be backed up. When disaster strikes next time, I also don’t have to deal with the proprietary format during my data recovery process. Who knows if Synology will still be around 20 years from now?

Why GCP

In the past, I configured my Synology NAS to perform a seamless backup to CrashPlan using this Docker solution. It has worked flawlessly for many years. The main reasons I want to move the backups to my personal GCP org are:

• I have free GCP credits. Even without the GCP credits, based on the GCP Pricing Calculator, it is still cheaper to back up my data to a regional Archive storage bucket than CrashPlan.
• I can customize the number of backup versions and retention policies.
• It is faster to recover all my data if needed.
• I want to secure the data and GCP resources myself.

You can swap out GCP with a cloud provider of your choice. For example, you can use Rclone to back up all your photos to Amazon Photos for free if you have a Prime membership and your photo formats are supported. My RAW images (supported) also have corresponding XMP files (not supported), and I want to back up other file formats too.

Configuration

This diagram below helps you to visualize the solution.

Setting up GCP Resources

The best way to secure the data backups is to create a separate GCP project where only a specific service account has sufficient permission to write to a storage bucket. At a high level:

• Create a GCP project.
• Create a storage bucket.
  • Enable object versioning and limit them to N versions (to prevent rising storage costs).
• Create a service account.
• Grant service account with Storage Object Admin (roles/storage.objectAdmin) at the project level.
• Create a service account key.
• Download the service account key file in JSON format to the local machine first. In this post, this file is named service-account.json.
• BONUS: If you are paranoid, configure a VPC Service Control perimeter and put that project within the perimeter. This ensures only the whitelisted IPs can access these project resources. This way, even if the service account key is compromised, adversaries cannot access the protected resources unless they also spoof the IPs.

Setting Up Rclone in Synology NAS

Ways to Install Rclone

There are multiple ways to install Rclone in Synology NAS:

• Install Rclone directly in Synology NAS.
• Install Rclone using Docker (rclone/rclone).
• Install Rclone with GUI using Docker (romancin/rclonebrowser).

In this post, I use the second solution (without GUI) because simpler implementation means less chance of the tool breaking in the future. Besides, this is a “set-and-forget” process, and I don’t need to use the GUI most of the time.

What’s in /docker/appdata/rclone

/docker/appdata should already exist when the Docker package is installed in Synology NAS. You only need to create a child folder named rclone (or any name you like). This folder contains three files:

• excludes.txt = File patterns to be excluded from the backup process.
• rclone.conf = Rclone configuration.
• service-account.json = The service account key file that you downloaded to your local machine from GCP.

Here’s my example of excludes.txt, and customize it to your needs:

@eaDir/**
.**

rclone.conf can be generated using rclone config command. However, that must be done outside Synology NAS (i.e., on your local machine). That said, most of this command’s interactive steps are unnecessary since you created the storage bucket earlier. All you need is exactly this and nothing else:

[gcp]
type = google cloud storage
service_account_file = /config/rclone/service-account.json

Downloading Docker Image

Go to DSM > Docker to download rclone/rclone image.

Creating Docker Container (with –dry-run)

This step ensures the Rclone is configured properly before any files are copied to the storage bucket to prevent incurring unnecessary costs.

First, create a new container.

Use rclone/rclone image.

No changes to the network settings.

Enter the container name, and go to Advanced Settings.

Under Execution Command, enter the following command:

sync /data gcp:[BUCKET_NAME] --exclude-from /config/rclone/excludes.txt --gcs-bucket-policy-only --verbose --dry-run

Replace [BUCKET_NAME] with your own bucket name.

IMPORTANT: Synology does not allow us to edit the execution command after creating a container!

No changes to the port settings.

Define the volume mounts:

• /config/rclone = contains the Rclone configuration files.
• /data = contains data to be backed up.
  • Because you can’t perform a volume mount on root /, each root folder needs to be volume-mounted to a subfolder within /data that you wish to back up.

TIP: Consider mounting a data folder with the least amount of data when doing the dry run test. You can add/remove folders on an existing container later.

Review the summary.

Once the container is created, click on the toggle to run it.

Review the container log. You can drop a few files into the mounted folder and rerun the container. The files should show up in the log.

Creating Docker Container (without –dry-run)

Now that you have a working container to perform the dry run test, it’s time to back up the data to the cloud.

As mentioned earlier, it is not possible to edit the existing container’s execution command. The existing container contains the –dry-run flag on the execution command. The simplest way is to export the container setting, which will be used to create a new container without the –dry-run flag.

Export just the container settings to a local machine.

Open the JSON file, locate and remove –dry-run from cmd. Save the file.

{
   "CapAdd" : [],
   "CapDrop" : [],
   "cmd" : "sync /data gcp:[BUCKET_NAME] --exclude-from /config/rclone/excludes.txt --gcs-bucket-policy-only --verbose --dry-run",
   "cpu_priority" : 0,
   "enable_publish_all_ports" : false,
   ...
}

Return to the Docker container window to import this JSON file to create a new container.

Upload the modified JSON file and provide a new container name.

Now, there are 2 Rclone containers: one with the –dry-run flag and another without it. It is up to you whether to retain or delete the container with the –dry-run flag.

Scheduling Docker Container to Run

To ensure the Rclone runs to back up the files to the cloud, create a task scheduler. In this example, a triggered task is created so that Rclone can perform the backups on boot-up.

Ensure to run the task as root.

Specify the following script to execute. This script ensures the Docker service is running first before starting the container to perform the backup.

while (synopkg status Docker | jq -r '.status' | grep -vq "running"); do
  sleep 10
done

docker container start rclone

That’s it! Every time the Synology NAS boots up, the Rclone container will run to perform any necessary data backup to the cloud.

The post Rclone: Backing Up Synology NAS to GCP appeared first on My Shitty Code.

This article also assumes you know how to dynamically create a WordPress post using REST API.

For simplicity, the cURL command is used instead of a programming language like PHP or Python.

PROBLEM

Let’s assume we want to create a post with one paragraph and 2 columns, each containing a paragraph too. When creating a similar structure directly using Gutenberg Block Editor, the generated source code like this:

<p>hello</p>
<div class="is-layout-flex wp-block-columns">
<div class="is-layout-flow wp-block-column">
<p>left</p>
</div>
<div class="is-layout-flow wp-block-column">
<p>right</p>
</div>
</div>

Using the same structure, we are going to create the same post using REST API instead:

export auth=...
export wp_url=...

content=$(echo '
<p>hello</p>
<div class="is-layout-flex wp-block-columns">
<div class="is-layout-flow wp-block-column">
<p>left</p>
</div>
<div class="is-layout-flow wp-block-column">
<p>right</p>
</div>
</div>
' | jq -Rsa .)

curl -H "Content-Type: application/json" \
  -H "Authorization: Basic $auth" \
  -X POST "$wp_url/wp-json/wp/v2/posts" \
  -d "{\"title\":\"test\", \"content\": $content}"

When opening the newly created post in edit mode, the post uses Classic Editor, and not Gutenberg Block Editor.

When attempting to convert the post to Gutenberg blocks…

Some blocks are converted successfully. However, most of the complex or nested blocks are converted to Custom HTML blocks instead. This is because it is not smart enough to know which Gutenberg blocks to use.

This becomes problematic and time-consuming when you have to manually convert each post to use Gutenberg Block Editor, and fix sections that failed to convert to the correct blocks.

SOLUTION

If you know you are going to create future new posts using known Gutenberg blocks (ex: paragraph, column, image, etc), the easiest approach is to manually create a temporary post using Gutenberg Block Editor first.

Using the same example, the paragraph and 2-column structure are manually created using Gutenberg Block Editor.

Now, click on the kebab on the top right, then select Code editor.

This will display the source code in block format, which looks like this:

<!-- wp:paragraph -->
<p>hello</p>
<!-- /wp:paragraph -->

<!-- wp:columns -->
<div class="wp-block-columns"><!-- wp:column -->
<div class="wp-block-column"><!-- wp:paragraph -->
<p>left</p>
<!-- /wp:paragraph --></div>
<!-- /wp:column -->

<!-- wp:column -->
<div class="wp-block-column"><!-- wp:paragraph -->
<p>right</p>
<!-- /wp:paragraph --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->

Now that we know what the format looks like, we can automate the post creations using REST API.

content=$(echo '
<!-- wp:paragraph -->
<p>hello</p>
<!-- /wp:paragraph -->

<!-- wp:columns -->
<div class="wp-block-columns"><!-- wp:column -->
<div class="wp-block-column"><!-- wp:paragraph -->
<p>left</p>
<!-- /wp:paragraph --></div>
<!-- /wp:column -->

<!-- wp:column -->
<div class="wp-block-column"><!-- wp:paragraph -->
<p>right</p>
<!-- /wp:paragraph --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->
' | jq -Rsa .)


curl -H "Content-Type: application/json" \
  -H "Authorization: Basic $auth" \
  -X POST "$wp_url/wp-json/wp/v2/posts" \
  -d "{\"title\":\"test\", \"content\": $content}"

Finally, we can create methods/functions with our favorite programming language to generate these blocks, which will be fed to the REST API to create a new WordPress post that is 100% compatible with Gutenberg blocks.

The post WordPress: Creating Gutenberg-Block Compatible Posts Using Rest API appeared first on My Shitty Code.

To configure a proxy server that only allows whitelisted URLs through.

SOLUTION

Install Squid… in this case, on Ubuntu.

sudo apt install -y squid

Ensure the service is running.

my@shittycode:/etc/squid$ sudo systemctl status squid
● squid.service - Squid Web Proxy Server
Loaded: loaded (/lib/systemd/system/squid.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-04-21 17:20:54 CDT; 3min 3s ago
Docs: man:squid(8)
Process: 9008 ExecStartPre=/usr/sbin/squid --foreground -z (code=exited, status=0/SUCCESS)
Process: 9012 ExecStart=/usr/sbin/squid -sYC (code=exited, status=0/SUCCESS)
Main PID: 9013 (squid)
Tasks: 4 (limit: 44379)
Memory: 16.1M
CGroup: /system.slice/squid.service
├─9013 /usr/sbin/squid -sYC
├─9015 (squid-1) --kid squid-1 -sYC
├─9016 (logfile-daemon) /var/log/squid/access.log
└─9017 (pinger)

Apr 21 17:20:54 shittycode squid[9015]: Max Swap size: 0 KB
Apr 21 17:20:54 shittycode squid[9015]: Using Least Load store dir selection
Apr 21 17:20:54 shittycode squid[9015]: Set Current Directory to /var/spool/squid
Apr 21 17:20:54 shittycode squid[9015]: Finished loading MIME types and icons.
Apr 21 17:20:54 shittycode squid[9015]: HTCP Disabled.
Apr 21 17:20:54 shittycode squid[9015]: Pinger socket opened on FD 14
Apr 21 17:20:54 shittycode squid[9015]: Squid plugin modules loaded: 0
Apr 21 17:20:54 shittycode squid[9015]: Adaptation support is off.
Apr 21 17:20:54 shittycode squid[9015]: Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 12 flags=9
Apr 21 17:20:55 shittycode squid[9015]: storeLateRelease: released 0 objects

Create a file ( /etc/squid/whitelist.txt ) containing the whitelisted URLs. In this example, only one URL is whitelisted.

my@shittycode:/etc/squid$ cat whitelist.txt
www.google.com

To simplify the configuration, backup /etc/squid/squid.conf and create the same file with these minimal configurations.

my@shittycode:/etc/squid$ cat squid.conf

# An ACL named 'whitelist'
acl whitelist dstdomain '/etc/squid/whitelist.txt'

# Allow whitelisted URLs through
http_access allow whitelist

# Block the rest
http_access deny all

# Default port
http_port 3128

Restart the service to pick up the change.

sudo systemctl restart squid

To test the configuration, when hitting a non-whitelisted URL, it should return 403.

my@shittycode:/etc/squid$ curl -x localhost:3128 -I -L yahoo.com
HTTP/1.1 403 Forbidden
Server: squid/4.10
Mime-Version: 1.0
Date: Wed, 21 Apr 2021 22:22:02 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3507
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from shittycode
X-Cache-Lookup: NONE from shittycode:3128
Via: 1.1 shittycode (squid/4.10)
Connection: keep-alive

When hitting a whitelisted URL, it should return 200.

my@shittycode:/etc/squid$ curl -x localhost:3128 -I -L www.google.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Date: Wed, 21 Apr 2021 22:21:03 GMT
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Expires: Wed, 21 Apr 2021 22:21:03 GMT
Cache-Control: private
Set-Cookie: 1P_JAR=2021-04-21-22; expires=Fri, 21-May-2021 22:21:03 GMT; path=/; domain=.google.com; Secure
Set-Cookie: NID=214=AAK1Z6cV4cXlOGLIdHrKhiyzW2iBKpkN5-3OXvVrxEGrw-VekbvM1uFMMUAGubhAciT8NcyCVto2fpDPHJXRBECcqJRFTsUDNb3WBUNIgvK0zWpyxz8bl1aSqB22nQhf2fEwfDM9nAkVZyQG8rst054qOfAHO9kDvkrZRWn9HyM; expires=Thu, 21-Oct-2021 22:21:03 GMT; path=/; domain=.google.com; HttpOnly
X-Cache: MISS from shittycode
X-Cache-Lookup: MISS from shittycode:3128
Via: 1.1 shittycode (squid/4.10)
Connection: keep-alive

The post Squid: Configuring Whitelisted URLs appeared first on My Shitty Code.

Step by step instructions for my future self to obtain the SSL certificate and to configure it in Nginx because my fragile little brain cannot retain them at the moment.

INSTRUCTIONS

Generate a private key and store it in a safe place.

openssl genrsa -out myshittycode_com.key 2048

Generate a certificate signing request (CSR).

openssl req -new -sha256 \
  -key myshittycode_com.key \
  -out myshittycode_com.csr	\
  -subj "/C=US/ST=ShittyState/L=ShittyCity/OU=ShittyUnit/O=ShittyCompany/CN=myshittycode.com"

Request a SSL certificate from Certificate Authority (ex: Sectigo) using the generated CSR.

If approved, you will receive an email similar to the below.

To configure the SSL certificate in Nginx, don’t use Certificate (w/ chain), PEM encoded because it contains the certificates in the following order:-

• Root CA certificate
• Intermediate CA certificate
• Certificate

Nginx wants them in this order:-

• Certificate
• Root CA certificate
• Intermediate CA certificate

To pull this off, download Certificate only, PEM encoded and Root/Intermediate(s) only, PEM encoded.

Then combine them into one file in the proper order.

cat myshittycode_com_cert.cer myshittycode_com_interm.cer > myshittycode_com_bundle.crt

In nginx.conf, add the bundle certificate, private key and server name.

server {
  listen               443;
  ssl                  on;
  ssl_certificate      /etc/pki/tls/certs/myshittycode_com_bundle.crt;
  ssl_certificate_key  /etc/pki/tls/private/myshittycode_com.key;
  server_name          myshittycode.com;

  location / {
    ...
  }
}

Restart Nginx service.

The post Nginx: Requesting and Configuring SSL Certificate appeared first on My Shitty Code.