In this article, I’ll show how to deploy PNETLab on Google Cloud using Terraform for automation, and Tailscale to securely access the lab without exposing it to the public Internet.

Goals

• Automate PNETLab server deployment with Terraform.
• Secure access to the lab without exposing it to the public internet.
• Configure a domain for easy access to the lab.

Prerequisites

• GCP & Tailscale accounts.
• GCP CLI installed.
• Terraform installed.
• Own a domain name (optional).

Network Diagram Overview

Here’s an overview of what we’re going to build:

Prepare the GCP Project

Create a Project

Before we begin, make sure that you’ve authenticated to GCP. Once done, create a project for our PNETLab deployment.

$ PROJECT_ID=pnetlab-$RANDOM
$ echo $PROJECT_ID
pnetlab-xxx
$ mkdir $PROJECT_ID
$ cd $PROJECT_ID
$ gcloud projects create $PROJECT_ID
$ gcloud config set project $PROJECT_ID

Then, link the project to your billing account.

$ gcloud billing accounts list              
ACCOUNT_ID            NAME                OPEN  MASTER_ACCOUNT_ID
AAAAAA-BBBBBB-CCCCCC  My Billing Account  True
$ gcloud billing projects link $PROJECT_ID --billing-account=AAAAAA-BBBBBB-CCCCCC

Enable the Compute API

Before you can use Google Cloud’s compute resources, we need to enable the Compute API which allows your project to access and manage VM instances.

$ gcloud services enable compute.googleapis.com

Note: I’m using GCP’s free trial credits for this setup, if you’re on a paid account, the steps remain the same.

Instance Deployment

Preparing Terraform Code

We’ll use the following folder structure.

$ tree
.
├── README.MD
└── terraform
    ├── terraforms.tfvars # sensitive informations goes here (project_id, region, user/keys)
    ├── main.tf # defined gcp resources
    └── variables.tf

1 directories, 4 files

Within the terraform folder, initialize the terraform working directory.

$ terraform init

terraform.tfvars

terraforms.tfvars contains the following (make your adjustment):

project_id      = ""
region          = ""
zone            = ""
os_image        = "projects/ubuntu-os-cloud/global/images/ubuntu-1804-bionic-v20240116a"
ssh_user        = "username"
ssh_pub_user    = "ssh-ed25519 AAAAC3N... root"
ssh_pub_ansible = "ssh-ed25519 AAAAC3N... ansible"

main.tf

main.tf file contains the following:

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
    version = "~> 4.5" }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

# SETUP NETWORK #
resource "google_compute_network" "pnetlab_vpc" {
  name                    = "pnetlab-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "pnetlab_subnet" {
  name          = "pnetlab-subnet"
  network       = google_compute_network.pnetlab_vpc.id
  ip_cidr_range = "10.10.1.0/24"
}

resource "google_compute_firewall" "allow_ssh_access" {
  name    = "allow-ssh"
  network = google_compute_network.pnetlab_vpc.id

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = [ "0.0.0.0/0" ]
}

# NAT
resource "google_compute_router" "pnetlab_router" {
  name = "pnetlab-router"
  region = var.region
  network = google_compute_network.pnetlab_vpc.id

}

resource "google_compute_router_nat" "pnetlab_router_nat" {
  name = "pnetlab-router-nat"
  region = var.region
  router = google_compute_router.pnetlab_router.name
  nat_ip_allocate_option = "AUTO_ONLY" # use dynamic public ip for nat
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES" # nat any sources ip range available within the vpc

}

# SETUP EXT DISK #
resource "google_compute_disk" "additional_disk" {
  name   = "pnetlab-additional-disk"
  type   = "pd-standard"  # Choose disk type (pd-standard, pd-ssd, etc.)
  size = 100 
  lifecycle {
    prevent_destroy = true
  }
}

# SETUP INSTANCES #
# ubuntu-1804-bionic-v20240116a                                 ubuntu-os-cloud      ubuntu-1804-lts
resource "google_compute_instance" "pnetlab_server" {
  name         = "pnetlab-server"
  machine_type = "n2-standard-2"
  tags         = ["pnetlab"]

  boot_disk {
    initialize_params {
      image = var.os_image # cloud image
      size  = 20                 # assign 20gb
      type  = "pd-standard"
    }
  }
  
  # external disk 100gb
  attached_disk {
    source = google_compute_disk.additional_disk.id
  }

  network_interface {
    network    = google_compute_network.pnetlab_vpc.id
    subnetwork = google_compute_subnetwork.pnetlab_subnet.id

    # Disable public IP
    # access_config {
    #  network_tier = "STANDARD"
    # }
  }

  scheduling {
    automatic_restart           = true
    on_host_maintenance         = "MIGRATE"
    preemptible                 = false
    provisioning_model          = "STANDARD"
  }

  advanced_machine_features {
    enable_nested_virtualization = true
  }
  
  metadata = {
    ssh-keys = "${var.ssh_user}:${var.ssh_pub_user} \n${var.ssh_user}:${var.ssh_pub_ansible}"
  }
}

variables.tf

variables.tf define the variables we used in the tfvars file, it contains:

variable "project_id" {
  type        = string
  description = "Project ID"
}

variable "region" {
  type        = string
  description = "Project region"
  default     = "us-central"
}

variable "zone" {
  type        = string
  description = "Project zone"
  default     = "us-central1-a"
}

variable "os_image" {
  type        = string
  description = "OS family"
}

variable "ssh_user" {
  type        = string
  description = "The sudo user"
}

variable "ssh_pub_user" {
  type        = string
  description = "The public key used for authentication to an instance. Format: [public key] [username]"
}

variable "ssh_pub_ansible" {
  type        = string
  description = "The public key used for configuration management. Format: [public key] [username]"
}

Run Code

With all the resource files defined, we will run the following command in the terraform directory.

$ terraform fmt         # Format your Terraform files  
$ terraform validate    # Check for syntax errors  
$ terraform plan -out pnetlab-deploy       #Preview the infrastructure changes  
$ terraform apply pnetlab-deploy -auto-approve  # Deploy the resources  

Verify Deployment

After it finishes, check if the instance is running:

$ gcloud compute instances list --filter="name=pnetlab-server" --project="$PROJECT_ID"

PNETLab Installation

Install PNETLab

SSH into the instance using gcloud cli.

$ gcloud compute ssh INSTANCE_NAME --zone=YOUR_ZONE

Add pnetlab repository with the following command.

$ echo "deb [trusted=yes] http://repo.pnetlab.com ./" | sudo tee -a /etc/apt/sources.list

Update the repository and install pnetlab.

root@pnetlab-server:~# apt-get update
root@pnetlab-server:~# apt-get install pnetlab

Note: I switched my user to root with $ sudo su -

Configure the Instance

Swap

Create a swap disk, allocate the size according to your need.

root@pnetlab-server:~# fallocate -l 1G /swapfile
root@pnetlab-server:~# chmod 600 /swapfile
root@pnetlab-server:~# mkswap /swapfile
root@pnetlab-server:~# swapon /swapfile
root@pnetlab-server:~# cp /etc/fstab{,.bak}
root@pnetlab-server:~# '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

DNS

Edit file /etc/network/interfaces add line dns-nameservers 8.8.8.8 to the configuration of interface pnet0.

...
# The primary network interface
iface eth0 inet manual
auto pnet0
iface pnet0 inet dhcp
    dns-nameservers 8.8.8.8
    bridge_ports eth0
    bridge_stp off
...

And restart the networking service.

root@pnetlab-server:~# sudo service networking restart

Disk

Time to add the additional disk we defined in the terraform resource. The purpose of this disk is to store all the pnetlab project files as well as the images later.

In my case, the additional disk is available at /dev/sdb.

root@pnetlab-server:~# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 40.4M  1 loop /snap/snapd/20671
loop1     7:1    0  368M  1 loop /snap/google-cloud-cli/203
loop2     7:2    0 63.9M  1 loop /snap/core20/2105
sda       8:0    0   20G  0 disk 
├─sda1    8:1    0 19.9G  0 part /
├─sda14   8:14   0    4M  0 part 
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0  100G  0 disk 

We’ll create an LVM disk out of it.

root@pnetlab-server:~# vgcreate /dev/vg01 /dev/sdb
  Volume group "vg01" successfully created
root@pnetlab-server:~# lvcreate -l 100%FREE --name lv01 vg01 
  Logical volume "lv01" created.
root@pnetlab-server:~# mkfs.ext4 /dev/vg01/lv01 
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done                            
Creating filesystem with 26213376 4k blocks and 6553600 inodes
Filesystem UUID: f1173542-f07c-493f-89e6-188439880465
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

Then we set a mount point for the volume we just created.

root@pnetlab-server:~# mkdir /mnt/unetlab
root@pnetlab-server:~# mount /dev/vg01/lv01 /mnt/unetlab

Edit the /etc/fstab file and add the following line to mount /mnt/unetlab on boot:

/dev/vg01/lv01  /mnt/unetlab  ext4  defaults  0  0

Now we’ll create a new directory for PNETLab project files and image files in our newly mounted disk.

root@pnetlab-server:~# mkdir /mnt/unetlab/addons
root@pnetlab-server:~# mkdir /mnt/unetlab/labs

Next, we’ll remove the old directories for project files and image files, and replace them with symbolic links pointing to the new directories on the mounted disk.

root@pnetlab-server:~# rm -rf /opt/unetlab/addons/ 
root@pnetlab-server:~# rm -rf /opt/unetlab/labs/
root@pnetlab-server:~# ln -s /mnt/unetlab/addons/ /opt/unetlab/
root@pnetlab-server:~# ln -s /mnt/unetlab/labs/ /opt/unetlab/

Change ownership of the new labs directory to ensure PNETLab’s services can access it back.

root@pnetlab-server:~# chown -R www-data:www-data /mnt/unetlab/labs/

Grub

Remove the default grub config.

root@pnetlab-server:~# rm /etc/default/grub.d/50-cloudimg-settings.cfg
root@pnetlab-server:~# update-grub
root@pnetlab-server:~# reboot

Restart and Verify

Once all the steps above are complete, restart the server and verify if the pnetlab service is running using the following command and check these ports: 80, 443 for pnetlab web services and 4822 for guacamole proxy.

root@pnetlab-server:~# netstat -tlpn  

Update Version (Optional)

After the installation completed, we can directly upgrade PNETLab to the latest version. It’s an optional, so I will just put the official guide link on how to upgrade the lab version: go here.

Setup Tailscale VPN

For this step, I will assume that you already generated an auth key in the Tailscale admin console.

Install Tailscale

First, install Tailscale by executing the install script.

root@pnetlab-server:~# curl -fsSL https://tailscale.com/install.sh | sh 

Configure Subnet Router

We will configure the instance as a subnet router, simply turning the server into a router. This will enable direct access between PNETLab appliances network and our local network via the Tailscale network.

To achieve that, we first need to enable IP forwarding on the server.

root@pnetlab-server:~# echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
root@pnetlab-server:~# echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
root@pnetlab-server:~# sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

To register your instance as a node in your Tailscale network and enable it to act as a subnet router, run the following command:

root@pnetlab-server:~# tailscale up --auth-key=tskey-auth-XXXXX  --advertise-route=10.0.10.0/24

Note:

• Replace tskey-auth-XXXXX with your actual auth key and 10.0.10.0/24 with your designated local network on the PNETLAB server:

• The --advertise-routes=10.0.10.0/24 option tells the instance to advertise the subnet 10.0.10.0/24 to your Tailscale network. Once advertised, other devices in your Tailscale network can route traffic to this subnet through this instance.

Revisit your Tailscale’s admin console. You should see a Subnets label on the pnetlab node.

Open the node settings, select “edit route settings…” and tick your network there.

Verify Routing

To verify, you can simply ping any interface IP of the instance that you have advertised. The image below is an example of mine, where I’m pinging the Docker interface.

Configure Domain Name

We can use a custom domain name to access PNETLab. To do so, we will obtain a LetsEncrypt’s certificate to replace the self-signed one and then configure a new DNS record: pnetlab.yourdomain.com. This record will be pointing to Tailscale IP of our instance.

For this step, I will assume that you already own a domain and know how to complete an ACME DNS challenge (proving control over a domain).

Obtain LetsEncrypt SSL

Within the instance, install certbot and prepare the work folder.

root@pnetlab-server:~# sudo apt install -y certbot
root@pnetlab-server:~# mkdir letsencrypt/work letsencrypt/config letsencrypt/logs

We can obtain a Let’s Encrypt certificate with the following command.

root@pnetlab-server:~# certbot certonly --agree-tos --email admin@yourdomain.com --manual --preferred-challenges=dns -d \*.yourdomain.com --config-dir ./letsencrypt/config --work-dir ./letsencrypt/work --logs-dir ./letsencrypt/logs

Complete the ACME DNS challenge on your DNS provider (NameCheap, Hostinger, etc). After successful validation, the CA (Let’s Encrypt) will issue the certificate, which should be available at ./letsencrypt/config/live/yourdomain.com.

Next, edit /etc/apache2/sites-available/pnetlabs.conf and change these values with your certificate path.

SSLCertificateFile   /path/to/your/cert/cert1.pem
SSLCertificateKeyFile /path/to/your/certkey/privkey1.pem

Restart the apache services

root@pnetlab-server:~# systemctl restart apache2

Create DNS A record

Go to your DNS hosting provider and add a new records with the following data:

• Type: A
• Hostname/Domain Name: pnetlab.yourdomain.com
• IPv4: pnetlab-tailscale-ip

Here’s an example of mine, where I’m using Cloudflare for DNS management.

100.126.1.2 is the tailscale node IP of my pnetlab server.

Verify if your domain is mapped correctly using the dig command or Google Toolbox.

$ dig pnetlab.gcp.fahmifj.space                         
...[SNIP]...
;; QUESTION SECTION:
;pnetlab.fahmifj.space.	IN	A

;; ANSWER SECTION:
pnetlab.fahmifj.space. 300	IN	A	100.126.1.2
...[SNIP]...

Once you done and get connected to Tailscale network, you should be able to access PNETLab at pnetlab.yourdomain.com.

Troubleshoot

If you happen to meet these errors, try the following solutions.

Cannot install packages

Try disable/comment this whole url line from the repository.

#deb [trusted=yes] http://i-share.top/repo ./
#deb [trusted=yes] http://repo.pnetlab.com ./

Cloud Appliance: DHCP not working

Verify udhcpd service is running and enabled.

$ service udhcpd status
$ cat /etc/default/udhcpd | grep ENABLED

Update to enabled and restart and see if it’s working.

Conclusion

We’ve completed all the necessary steps to deploy a PNETLab server on Google Cloud. With this setup, we can do our networking stuff in the lab safely without exposing it to the internet.

That’s all, see you in the next post!

The lab is designed to resemble a small enterprise Windows environment with minimal requirements that enough to run on a mid-range specification.

Assumptions & Threat Model

This lab assumes:

• An internal attacker with network access
• Minimal internal monitoring
• Default or weak Windows security configurations
• Misconfigured behavior

Prerequisites

Knowledge

• Virtualization (VirtualBox)
• Windows and Windows Server installation
• Basic Active Directory concepts (Domain, DNS, SPNs)
• Basic networking and routing

Hardware

Recommended minimum (sorted by priority):

• Storage: 256 GB SSD (or high-speed USB 3.x)
• RAM: 8 GB minimum, 16 GB recommended
• CPU:
  • Minimum: Intel i3 6th gen / Ryzen 3
  • Recommended: i5 / Ryzen 5 (H or K variants)

The lab was built and tested on an 8 GB system by aggressively disabling unused services after installation.

Software

• VirtualBox (Download)
• Kali Linux (attacker) (Download)
• Windows 10 evaluation image file (Download)
• Windows Server 2019 evaluation image file (Download)

Topology Overview

The environment consists of:

• 1 Domain Controller
• 2 Domain-joined Windows clients
• 1 Attacker machine (Kali Linux)

Two network segments are used:

• 192.168.1.0/24 – Internal domain network
• 10.10.10.96/28 – Segmented network used for pivoting scenarios

Note: It’s NIC (Network Interface Card) not NC

Network Segments

This lab intentionally uses two network segments to simulate an internal enterprise environment and to enable pivoting scenarios later on.

VirtualBox Setup

System Configuration

Initial installation:

• Server: 2424 MB
• Clients: 1280 MB each

Post-installation (after disabling unnecessary services):

• Server: 1280 MB
• Clients: 1024 MB
• Attacker: 1024 MB

This configuration allows all VMs to run concurrently on an 8 GB host. For initial setup, the two clients can stay inside 192.168.1.0/24 network.

Network Configuration

For each VM (initial setup):

• Adapter 1
  • Type: Internal Network
  • Name: windows_domain
  • IP Range: 192.168.1.0/24

For the Domain Controller only:

• Adapter 2
  • Name: internal_windows
  • IP Range: 10.10.10.96/28

This makes the Domain Controller act as a bridge between segments.

Active Directory Setup

Server

Initial Setup

• Admin credentials: administrator:p@$$w0rd!
• PC Name: server19-DC (restart after)
• Network (Static):
  • Adapter 1: 192.168.1.100/24
  • Adapter 2: 10.10.10.100/28

Promote Server to Domain Controller

• Server Manager > Manage > Add Roles and Features.
• Add Roles and Features Wizard:
  • Installation type: “Role-based or feature-based installation”
  • Server selection: server19-DC
  • Server roles: “Active Directory Domain Services” and check the “Include management tools”.
  • Features: Check the “Group Policy Management”
  • Confirmation: Check on “Restart destination server automatically if required”
  • Close after it’s done.
• Server Manager > Notification flag > Click on “Promote this server to a domain controller”
• Active Directory Domain Services Configuration Wizard:
  • Deployment configuration: “Add a new forest” and set “server19.local” as root domain name
  • Domain controller options: set “Windows Server 2016” as FFL (Forest Functional Level) and DFL (Domain Functional Level). Checklist DNS server and set the same admin password for DSRM password.
  • Additional options: set NetBIOS domain name to SERVER19
  • Let the rest options in default state until installation section.
  • Restart after installation complete.

Create Domain Accounts

• John Smith
  • User logon name: jsmith@server19.local
  • Password: jsmith@123
• Carl Smith
  • User logon name: cmisth@server19.local
  • Password: @csmith@

All password is set to never expires.

Create Fake Service Account

Fake SQL Service

• User logon name: SQLService@server19.local
• Password: Mysql@Password123

Set service principle name:

setspn -a SERVER19-DC/SQLService.SERVER19.local:60111 SERVER19\SQLService
setspn -T SERVER19.local -Q */*

Configure File Sharing (SMB):

• Server manager > File and Storage Services > Shares > Task > New Share.
• New Share Wizard:
  • Profile: SMB Share Quick
  • Share Location: C:\Shares\DATA (Create the shares folder in C:)
  • Other Settings: Allow caching of share
  • Permission: Leave it default
  • Confirmation and create.

Clients

Initial Setup

• Client 1:
  • IP: 192.168.1.101/24 (static)
  • PC name: NESCOFFEE
• Client 2:
  • IP: 192.168.1.102/24 (static)
  • PC name: MILO

For pivoting

• Client 2:
  • IP: 10.10.10.101/28(static)

Create Local Accounts

Same with domain accounts, but add an L at the end of username/password.

• Username: cmisthL, password: jsmithL@123
• Username: jsmithL, password: @csmith@

Joining Domain

Client 1:

• Use Server’s IP as DNS server: 192.168.1.100
• Hit Win+I, type “access”, click on Connect.
• Microsoft account window:
  • Click on “Join this device to a local Active Directory domain” under the alternate actions.
  • Use the server administrator password to join.
  • Skip the Add an account section
  • Restart

Client 2 has the same steps

Create Local Admin

• Set John Smith (jsmith@server19.local) as local administrator for NESCOFFEE.
• Set Carl Smith (cmisth@server19.local) as local administrator for MILO.

Attacker

Initial Setup

• Put it on the same network
• Set static IP: 192.168.1.10/24
• Perform ping test

Attack Scenarios

Here are some attack scenarios that can be reproduced using this lab:

• LLMNR Poisoning

  • Example: https://www.aptive.co.uk/blog/llmnr-nbt-ns-spoofing/

• AS-REP Roasting

  • Example: ASREP-Roasting tags

• Kerberoasting

  • Example: https://pentestlab.blog/2018/06/12/kerberoast/

• Take Over IPv6 DNS

  • Example: https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

• DCSync

  • Example: DCSync tags

Attack scenario(s) that requires two clients online + server:

• SMB Relay
  • Examples: HackTheBox - APT, SMB Relay Attack

However, migrating a site to another domain could negatively impact SEO. Although I’m not really concerned about it, I think it’s a great opportunity to learn something from this case.

So, instead of moving everything, I keep GH Pages as the primary site and let the custom domain act as a mirror. Both domains serve the same content without redirecting one to the other.

This post documents the setup and explains why keeping GitHub Pages as the primary works better for me.

Cloudflare Workers as Reverse Proxy

Cloudflare provides a feature called Workers. It allows you to write and run serverless code, similar in concept to Google Cloud Functions.

Using this feature, I write a Worker that acts as a reverse proxy. Its job is to fetch my GitHub Pages content and serve it back on the custom domain.

                       ┌──────────────────────────┐
                       │   fahmifj.github.io      │
                       │    (upstream hosting)    │
                       └──────────┬───────────────┘
                                  │ GitHub Pages origin
                                  ▼
                          Cloudflare Worker
                          (proxy + rewrite)
                                  │
                                  ▼
                            fahmifj.space
                           (custom domain)

Create Worker (v1)

This first version of the Worker functions purely as a content fetcher.

export default {
  async fetch(request) {
    const url = new URL(request.url);

    // Force everything to fetch from GitHub Pages 
    url.hostname = "fahmifj.github.io";

    const response = await fetch(url.toString(), {
      headers: request.headers,
      redirect: "follow"
    });

    // Copy GitHub response and serve it
    return new Response(response.body, response);
  }
};

The result is straightforward, it serves the same content as GitHub Pages.

Attach Custom Domain to Worker

Next, I attach my custom domain to the Worker (Workers & Pages > My Worker > Settings > Domain & Routers).

At this point, fahmifj.space is already serving the same content as fahmifj.github.io.

Worker with URL Rewriter (v2)

Hugo builds my site with absolute URLs based on my GH Pages domain, which is fahmifj.github.io. Because of this, clicking most links on the custom domain sends users back to GH Pages.

To fix that, I need to make an adjustment on the Worker to rewrite all the GitHub Pages URLs and replace them with the custom domain. With the help of ChatGPT, I also add a condition to:

• Block search engines indexing bot.
• Return 404 for the sitemap.
• Remove canonical link before the contents are served on the custom domain.

export default {
  async fetch(request) {
    const upstream = "fahmifj.github.io"; // GitHub Pages domain
    const mirror = "fahmifj.space"; // Custom domain

    const url = new URL(request.url);

    // Prevent indexing by googlebot

    const ua = request.headers.get("user-agent")?.toLowerCase() || "";
    const bots = [
        "googlebot", 
        "bingbot", 
        "slurp", 
        "duckduckbot", 
        "baiduspider", 
        "yandex"
    ];

    if (bots.some(bot => ua.includes(bot))) {
      return new Response("Not for indexing", { status: 403 });
    }

    // Do not serve sitemap
    if (url.pathname === "/sitemap.xml") {
      return new Response("", { status: 404 });
    }


    url.hostname = upstream;
    
    // Read HTML response
    const upstreamResponse = await fetch(url.toString(), {
      headers: request.headers,
      redirect: "follow",
    });

    const contentType = upstreamResponse.headers.get("content-type") || "";
    if (!contentType.includes("text/html")) {
      return upstreamResponse;
    }

    // Add no-index header (no crawling on my custom domain)
    const headers = new Headers(upstreamResponse.headers);
    headers.set("X-Robots-Tag", "noindex, nofollow");

    //  Rewrite all URLs from upstream → custom domain
    return new HTMLRewriter()
      // Rewrite links
      .on("a[href]", {
        element(el) {
          rewriteAttr(el, "href", upstream, mirror);
        }
      })
      // Rewrite assets
      .on("img[src], script[src], link[href]", {
        element(el) {
          rewriteAttr(el, "src", upstream, mirror);
          rewriteAttr(el, "href", upstream, mirror);
        }
      })
      // Remove canonical tag
      .on("link[rel='canonical']", {
        element(el) {
          el.remove();
        }
      })
      .transform(new Response(upstreamResponse.body, {
        status: upstreamResponse.status,
        headers
      }));
  }
};

/* ---- Helper ---- */

function rewriteAttr(element, attr, upstream, mirror) {
  const value = element.getAttribute(attr);
  if (!value) return;

  if (value.includes(upstream)) {
    element.setAttribute(
      attr,
      value.replace(`https://${upstream}`, `https://${mirror}`)
    );
  }
}

Conclusion

With this setup, the custom domain acting as a mirror can coexist with GH Pages.

You might think that it is odd to keep using GitHub pages even though I already have a custom domain. The reason is simple: I want my blog to stay online as long as possible by relying on a free service provided by GitHub itself.

If I used my custom domain as the primary site, I would be responsible for maintaining that domain (or even server). The custom domain can expire in one or two year and I might forget renewing it or even I decide to switch to another TLD. These all could negatively impact SEO*.

*or .. maybe I’m just a lazy sysadmin.

But with GitHub Pages as the primary site, I don’t have to worry about maintaining a domain. GitHub handles everything and the canonical URL stays consistent. This way, I will still have the freedom to change my custom domain in the future without worrying about SEO.

Okay that’s it. See you in the next post!