Skip Navigation

bivlked

@ bivlked @lemmy.world

Posts
1
Comments
7
Joined
4 wk. ago

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • 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.

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • 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?

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • 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.

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • 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.

  • amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    Jump

  • 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.

  • Selfhosted @lemmy.world
    bivlked @lemmy.world

    amneziawg-installer: one-command VPN server that works where WireGuard gets blocked

    github.com /bivlked/amneziawg-installer