

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.

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.