this post was submitted on 06 Apr 2026
142 points (98.0% liked)

Selfhosted

56957 readers
315 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

WireGuard is blocked by DPI in 10+ countries now. AmneziaWG 2.0 is a fork that makes the traffic look like random noise - DPI can't tell it apart from normal UDP. Same crypto under the hood, negligible speed overhead.

I wrote an installer that handles the whole setup in one command on a clean Ubuntu/Debian VPS - kernel module, firewall, hardening, client configs with QR codes. Pure bash, no dependencies, runs on any $3/month box. MIT license.

Been running it from Russia where stock WireGuard stopped working mid-2025.

you are viewing a single comment's thread
view the rest of the comments
[–] bivlked@lemmy.world 2 points 1 week ago (7 children)

Author here. Didn't expect this post to blow up like this — thanks for all the questions.

A bug came up right after I posted, and I just pushed out v5.8.0 for it. A user couldn't get the tunnel up on a mobile connection in Russia, and I traced it back to the H1-H4 hash ranges: turns out I was hardcoding the same four ranges into every install, so every server running this script had an identical static fingerprint. The TSPU apparently learned those defaults - my bad.

The fix: H1-H4 now get randomized per install from /dev/urandom - different values every time, no shared defaults. Each server speaks its own dialect.

On the detection-vs-blocking point (possiblylinux127, WhyJiffie): you're right that shape-shifting headers don't make traffic invisible, just unmatchable to a simple rule. litchralee nailed it further up - statistical analysis over time could still fingerprint this, but that's a per-target attack, not something a national DPI box runs on everyone. For the ISP-level blocking that's actually happening in Russia and Iran right now, per-install randomization is what matters.

[–] litchralee@sh.itjust.works 0 points 1 week ago (3 children)

Hi! Firstly, thank you for using /dev/urandom as the proper source for random bytes.

Regarding the static H1-H4 issue, does your repo have any sort of unit tests that can verify the expected behavior? I'm aware that testing isn't exactly the most pressing thing when it comes to trying to overcome ISP- and national-level blocking. But at the same token, those very users may be relying on this software to keep a narrow security profile.

To be abundantly clear, I'm very glad that this exists, that it doesn't reinvent the WireGuard wheel, and that you're actively fixing bug reports that come in. What I'm asking is whether there are procedural safeguards to proactively catch this class of issues in advance before it shows up in the field? Or if any are planned for the future.

[–] bivlked@lemmy.world 2 points 3 days ago (2 children)

Fair question. When the H1-H4 thing happened, my first thought was "why didn't the tests catch this?" - because there wasn't a test for it. Now there is.

I use bats - 85 tests in 10 files. The H1-H4 fix got its own test_h_ranges.bats with 10 cases, including an INT32_MAX boundary check that runs 20 iterations. All scripts also pass shellcheck with zero warnings.

Every release gets tested on a fresh VPS - Ubuntu 24.04 and Debian 13, full install through both reboots, then every manage command. For bigger changes I get a second pair of eyes on the code - that's how we caught a restore function not enforcing 600 perms on key files before it shipped.

No CI yet though - tests run locally and on the VPS, not on every push. GitHub Actions is next. The ARM PR (#43) is already adding CI for the ARM builds, so it's a good time to wire up x86_64 too.

[–] litchralee@sh.itjust.works 1 points 3 days ago* (last edited 3 days ago) (1 children)

Glad to see this! And thanks for getting back to me.

Btw, is there a presence for the project on Mastodon? I'd like to follow along on new stuff in this space. Or even an RSS feed that can be pulled by a bot on Mastodon?

[–] bivlked@lemmy.world 2 points 3 days ago

No dedicated Mastodon account yet. For updates, GitHub Releases works as an RSS/Atom feed: https://github.com/bivlked/amneziawg-installer/releases.atom - subscribe in any feed reader. Considering fosstodon.org as a future home if there's enough interest.

load more comments (3 replies)