This article is currently an experimental machine translation and may contain errors. If anything is unclear, please refer to the original Chinese version. I am continuously working to improve the translation.
Preface
After the original “Running My Own ISP” series (this post and Ex), we’ve finally arrived at — PH!
Under the combined pressures of RIPE ASN price hikes, the scarcity of VPS providers offering BGP sessions, and my lack of actual production needs, my public AS was shut down. In its place: the DN42 network!
1 | dn42 is a large, dynamic VPN that employs Internet technologies (BGP, whois database, DNS, etc.). Participants connect to each other using network tunnels (GRE, OpenVPN, WireGuard, Tinc, IPsec) and exchange routes using the Border Gateway Protocol. |
Think of it as a miniature version of the Internet. Participants can register their own ASNs and IP ranges, announce them via BGP within this private VPN, and even host services.
Now, since we’ve already played with BGP in the real Internet, there’s no need to just clone the same setup in DN42. So of course, I’ll be doing some (ridiculous) new things on DN42!
Joining DN42
DN42, being an experimental and educational network, makes applying for an ASN and IP range much easier than in the real world—and the documentation is actually decent. I don’t think I need to rehash it all here. Instead, I highly recommend reading the following before proceeding:
- Official Getting Started Guide
- Introduction to the DN42 Experimental Network and Registration Guide by Lan Tian
The overall onboarding process is similar to public BGP, but there are a few key differences:
- In the public Internet, you typically look for upstream providers or peers. In DN42, everyone mostly just peers with each other, but DN42 peers usually send you a full table of “global” routes.
- In DN42, I have multiple VPS instances, so I need to handle internal AS routing and interconnection.
As a newcomer, I recommend starting by peering with an AS that supports Automatic Peering—it’s more introvert-friendly—and helps verify your configuration is correct. You can borrow the Bird configuration from the DN42 website.
Regarding BGP setup, I’m reusing the anycast-like approach from my public Internet days. For example, if I own the DN42 IP block 172.20.42.224/27, I’ll announce the entire /27 prefix from every VPS that joins DN42.
In the real Internet, a single Point of Presence (PoP) could be a whole data center with dozens of machines—burning through a /24 IPv4 block isn’t unusual. But in DN42, the smallest routable IPv4 prefix is /29. Using a /29 per VPS would be wasteful. So instead, I announce the full block from all nodes, and once traffic enters my AS, I route it internally to the correct machine.
This setup requires the following (quoted from Lan Tian’s blog):
1 | 1. Any two servers must be able to communicate with each other (e.g., pingable). |
For now, I’m going with option 2.1: full mesh. I’m setting up point-to-point WireGuard tunnels and BGP sessions between every pair of VPS instances in my AS.
Unfortunately, DN42 lacks the infrastructure and tooling of the real Internet—there aren’t many public testing tools. After setup, try joining the related Telegram groups; they often have ping bots you can use to test if your network is reachable.
Once confirmed, you can join IRC or other communities and peer with fellow enthusiasts to expand connectivity across DN42. (I feel like this is some kind of cyber ham radio thing.)
NixOS!
Previously, I used Ansible to manage my HomeLab and VPS fleet. At the time, I considered Nix, but didn’t adopt it because my HomeLab runs on Proxmox VE, which isn’t ideal for Nix.
Later, as I kept switching VPS providers, Ansible deployments started feeling slow. So I took this opportunity to convert all my VPS instances to NixOS (since they’re low-priority, it’s fine if they blow up), while keeping my HomeLab unchanged.
My approach: use the reinstall script to overwrite the original OS with NixOS stable, then deploy my actual Nix Flake configuration using colmena.
What? You want to know how I write Nix code?
Well… I let AI do it. Yep. Since my VPS aren’t critical and I don’t want to dive deep into Nix—a somewhat niche language—I took a massive shortcut: I prompted GitHub Copilot to convert my old Ansible playbooks into Nix. The result was surprisingly decent—after a few iterations, it worked. Aside from some vibe-coded monstrosities, I quickly achieved my goal: https://github.com/lyc8503/infra. Feel free to check out my setup.
I’ve also honestly—and responsibly?—added an AI Content Warning at the top of the README. Going forward, I’ll tag all code primarily generated by AI with a CW.
Honestly, NixOS is pretty AI-friendly. Even if you mess up, you can confidently git reset and redeploy to get back to a working state.
Summary
I’ve got my DN42 network AS4242420167 up and running. It’s small, so the possibilities are limited—but at least it unifies my scattered VPS resources into one giant internal network. Now I own a distributed data center spanning the globe. I’ve also peered with several community members.
Since this is an experimental network, I won’t prioritize stability. Instead, I’ll focus on doing fun, weird things you can’t easily pull off elsewhere.
Some (possible) TODOs:
- [DONE] Self-host various services to minimize third-party reliance (e.g., DNS, email)
- Public shell access
- Peer information page and automated peering
- [WIP] Deploy my hand-rolled C++ DNet network stack
- Optimize the current full-mesh setup
If I come across anything interesting, I’ll share it in future blog posts.
This article is licensed under the CC BY-NC-SA 4.0 license.
Author: lyc8503, Article link: https://blog.lyc8503.net/en/post/dn42-1-join/
If this article was helpful or interesting to you, consider buy me a coffee¬_¬
Feel free to comment in English below o/