Homelab

22 readers

1 users here now

Rules

Be Civil.
Post about your homelab, discussion of your homelab, questions you may have, or general discussion about transition your skill from the homelab to the workplace.
No memes or potato images.
We love detailed homelab builds, especially network diagrams!
Report any posts that you feel should be brought to our attention.
Please no shitposting or blogspam.
No Referral Linking.
Keep piracy discussion off of this community

founded 1 year ago

MODERATORS

communick@selfhosted.forum

rglullis@communick.news

VPN Randomizer (alien.top)

submitted 11 months ago by ingestbot@alien.top to c/homelab@selfhosted.forum

15 comments fedilink hide all child comments

I've developed a Python application which rotates VPN gateways from one or more providers. This will change your outbound IP address, and optionally VPN provider(s), on a random basis within a given time period (eg, every 2-4 hours). This uses Docker, the Gluetun VPN client, virtual machines, and optionally HAProxy, MQTT, InfluxDB and Unbound DNS.

I'd really appreciate feedback from members of this subreddit, whether that's in regards to the general concept, the example architecture I've included in the repo (below), the code itself, or whatever else you might have!

Randomizer supports all providers supported by the Gluetun VPN client including custom providers. The randomizer project has been biased towards Wireguard and Linux, with OpenVPN and other OSes in near-term consideration. It's my intention to keep the project as flexible as possible allowing ease in adopting personal modifications.

https://github.com/ingestbot/randomizer

you are viewing a single comment's thread
view the rest of the comments

[–] ErnLynM@alien.top 1 points 11 months ago (1 children)

That's cool AF. Do you have any moments of connectivity in between VPN switches?

[–] ingestbot@alien.top 1 points 11 months ago

A most excellent question and an issue just recently addressed.

Gluetun includes a control server which allows state changes to the VPN connection. Early on I would send a stopped and let the healthcheck take care of the recovery. At some point I found that 6 second lapse to cause a bit of trouble so I played with sending a stopped and immediate running. The result is a near instantaneous recovery (and random reallocation) of the tunnel.

Here's are a couple of examples:

2023-11-20T14:42:31Z INFO [vpn] stopping
2023-11-20T14:42:31Z INFO [http server] 200 PUT /status wrote 22B to 172.21.0.1:40896 in 129.856648ms
2023-11-20T14:42:31Z INFO [vpn] starting
2023-11-20T14:42:31Z INFO [wireguard] Connecting to 188.241.176.194:2049
2023-11-20T14:42:31Z INFO [http server] 200 PUT /status wrote 22B to 172.21.0.1:40902 in 108.677199ms
2023-11-20T14:42:32Z INFO [ip getter] Public IP address is 188.241.176.241 (Canada, Quebec, Montréal)
***
2023-11-20T14:43:56Z INFO [vpn] stopping
2023-11-20T14:43:56Z INFO [http server] 200 PUT /status wrote 22B to 172.21.0.1:52474 in 129.197494ms
2023-11-20T14:43:56Z INFO [vpn] starting
2023-11-20T14:43:56Z INFO [wireguard] Connecting to 198.54.131.98:2049
2023-11-20T14:43:56Z INFO [http server] 200 PUT /status wrote 22B to 172.21.0.1:52482 in 108.371437ms
2023-11-20T14:43:56Z INFO [ip getter] Public IP address is 198.54.131.120 (United States, Washington, Fairwood)

You've raised a great point here and it's something I may look into further (as in soon). It wouldn't be to difficult to measure the entire sequence in milliseconds and offer that up as a metric.