OPNSpeedGuard

oooh man!
So much work turning this into a python package.
I absolutely hate python’s approach to import. Combining the worst parts of both C++ linkers and javascript dynamic typing. Spent an hour figuring out why config variables are not persistent across modules only to realize I made a typo, and apparently it’s valid to create a new variable at runtime across scripts D:.

Anyways, it’s now published on PyPI! Also made a short demo video, too bad I got unlucky with QoS and the results were not that impressive. Still though it works!

Ready for release!

CLI functions are now added! Next step would be packaging into a module, writing docs, then publishing.
I guess I’ll explain more about what this tool does here since the descr doesn’t have enough space.

In Wireguard or basically any other VPN protocols, connecting to a “server”, or what wg call peers, is basically the same as connecting your computer to virtually join the network that other peer is connected to. Wg has a cool feature called allowed_ips, in traditional setups this would just be loopback or RFC1918, but a “road-warrior” setup sets this to 0.0.0.0/0, ::/0, which is the entire internet, basically allowing you to access the internet through this peer. And this is how VPNs like mullvad work.

The problem comes when governments don’t very much like these setups, so peers are often blocked or severely rate limited. Since how it’s setup we can only connect to one peer at one time, but we also have to be connected to check if it’s usable or fast, meaning you’ll have to manually check each peer to see which one’s the best. This is made worse with OPNSense’s mediocre wg web panel.

A trick is used to check peer activity. While we cant test internet connection through each peer at the same time, we can just test tunnel activity, and that’s enough for most cases. (why not ping? DPI and ML doohickeys make peers pingable but block their wg tunnels once traffic signatures are matched.)

This tool also adds some automated individual speedtest features, so it’s now way less painful managing such a setup. Just run the script in the background when bandwidth drops, and it will (eventually) find a good peer to connect to.

Very big devlog!
The script is done!
Wow!
Now the system automatically switches and perform speed tests when a peer doesn’t reach the speed requirements. Modularizing the config system was the right move, now a single json toggle can run the script in automatic mode, emulating user input via presets. Also took some time to create a final run report since all the log spam made reading whats going on impossible. Oh so a quiet toggle is also added lol.

Maybe some testing and this can be shipped. It’s just a script after all, albeit quite convoluted.

Maybe I’ll turn this into a docker container and turn this into a service, but that feels like feature creep, and this tool is plenty enough for me for now.

Rewritten most of the code for better modularity and automatic mode.
User input are now separated into another module which can be overridden with predetermined values read from a json file.
Most API calls and peer management is delegated to another module, so instead of handling raw API ouputs, they’re abstracted into peer objects. This makes the main logic much cleaner, and it allows some possible advanced features in the future, like collecting stats for which peer works the best.

Rewriting is mostly done, next step is adding speedtest for automatic peer selection.
Left is the original one, the selected part on the right is the new one. Code is much cleaner now.

Refactoring the project from a script into an automated service based on webhook :o

A json-based config parser is being done, plus stuff are being segmented into classes