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.
This is a side entry in the "ISP@Home" series, where things have officially entered meme territory. If some concepts or background feel under-explained, you might want to check out earlier posts in the series first.
Preface
After the main series and its Ex chapters, we’ve finally arrived—PH!
Under the combined pressure of RIPE ASN price hikes, scarce VPS providers offering BGP sessions, and me having zero actual need, my public ASN collapsed. In its place: welcome DN42!
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. |
It’s basically a miniature Internet. Participants can register their own ASNs and IP ranges, announce them via BGP within this VPN network, and run services inside it.
Now, since we’ve already played with BGP on the real Internet, there’s no point in just re-creating the exact same setup in DN42. So of course, I’m going to pull some wild stunts here instead!
Joining DN42
DN42, being an experimental and educational network, makes applying for an ASN and IP space way easier than the real Internet—and there’s plenty of detailed documentation. At this point, I don’t see much value in rewriting it. I strongly recommend reading the following before proceeding:
The overall setup is similar to public BGP, but with a few key differences:
- In public BGP, you usually look for upstreams or peers. In DN42, everyone mostly just peers with each other, though DN42 peers typically send you a “full table” of routes.
- Since we have multiple VPS instances, we need to handle internal routing and interconnection within our AS.
As a DN42 newbie, I recommend starting by peering with an AS that supports Automatic Peering—it’s more introvert-friendly—and it also helps verify your config is working. You can copy the Bird configuration from the DN42 Bird2 guide.
For BGP handling, we’re doing something similar to our previous Anycast setup: for example, if I have the DN42 subnet 172.20.42.224/27, I’ll announce this entire range from all my VPS instances in DN42.
Why? In the real Internet, a single Point of Presence (PoP) might be a full datacenter, and burning through a /24 IPv4 block isn’t unusual. But in DN42, the smallest prefix you can announce is /29. Using one /29 per VPS would be wasteful. So instead, we announce our entire IP range from every machine, and once traffic enters our AS, we route it internally to the actual host that owns the IP.
This setup requires your VPS instances to meet the following conditions (quoted from Lan Tian’s blog):
1 | 1. Any two servers can communicate with each other (i.e., pingable). |
For now, we’re going with option 2.1: full mesh. We set up P2P WireGuard and BGP sessions between every pair of our AS-internal VPS instances.
Unfortunately, DN42 isn’t as well-equipped as the real Internet—there aren’t many public testing tools. After setup, try joining the related Telegram groups; they often have ping bots to test if your network is reachable.
Once confirmed, hop into IRC or other chat groups and peer with fellow enthusiasts to expand your connectivity. (I kinda feel like this is some kind of cyber ham radio club.)
NixOS!
Previously, I used Ansible to manage my HomeLab and VPS fleet. I considered Nix back then, but didn’t adopt it since my HomeLab runs on Proxmox VE, which isn’t a great fit for Nix.
Later, as I kept switching VPS providers, Ansible deployments started feeling too slow. So I took this opportunity to finally switch all my VPS instances to NixOS (and honestly, my VPS aren’t mission-critical—blowing them up is fine). My HomeLab stays as-is.
My method: I used the reinstall script to overwrite the original OS with NixOS stable, then deployed my actual Nix Flake configuration via colmena.
Wait, how did I write the Nix code?
Well… I let AI do it. Yep. Since my VPS aren’t critical and I didn’t want to dive deep into Nix—a somewhat niche language—I took a huge shortcut: I prompted Copilot to convert my old Ansible playbooks into Nix. The result was… acceptable. After a few iterations, it worked. Aside from some vibe-coded horrors__mountains, I reached my goal pretty quickly: https://github.com/lyc8503/infra. Feel free to check out my configs.
I also added an AI Content Warning right at the top of the README—because I’m very sincere and responsible (questionable). In the future, I’ll add CWs to all code primarily generated by AI.
Honestly, NixOS is surprisingly AI-friendly. Even if you break everything, you can confidently git reset and redeploy to get back to a known state.
Wrap-up
I’ve got my DN42 network AS4242420167 up and running. It’s still small, so there’s not that much to play with yet—but at least my scattered VPS resources are now unified into one big internal network. Now I have a loosely distributed datacenter spanning the globe. I’ve also peered with several folks in the community.
Being an experimental network, I won’t prioritize stability—instead, I’ll focus on pulling off weird, fun stunts you can’t do elsewhere.
Some (possible) TODOs:
- [DONE] Self-host various services, minimizing third-party reliance (e.g., DNS, email)
- Public shell access
- Peer info page and automated peering
- [DONE] Deploy my hand-rolled C++ DNet network stack
- Optimize the current full-mesh setup
If I do something interesting, expect a follow-up post.
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/