Referenced your comment in my top-level reply - you got the mechanism right. One thing worth adding on the statistical angle: building a baseline requires known AWG traffic to train on first. CPS (I1-I5) randomizes packet timing and cadence on top of headers, which makes even gathering that training data harder. Per-target surveillance is real but it’s a different threat model from what the tool addresses.
Hey, saw your PR #43 - the QEMU build matrix is a solid start. Left a comment there about two things: the /output mount path issue in the CI workflow, and the awg-tools version question (the PPA arm64 build might still be 1.x). Are you working on those, or would it help if I tested on my end?
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.
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.
Fair call - the client-driven install is a legit option if you want a GUI. The script is the other angle: read it before running, watch it work over SSH, no background magic. Same protocol, different workflow.
Also thanks for the “it works from Russia” confirmation further up - means more than any testing I could run myself.
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.
Blocking has to happen real-time on every packet — a DPI box needs a fixed pattern to match. AWG shifts its headers per install, so there’s no stable rule to write. Statistical detection (what litchralee described above) is possible but too slow and expensive to run inline at ISP scale - you’d need to collect and analyze flow data over hours before making a call. By then the connection is long gone.