Thanks tons kind sir. A warm muffin to you!
ingestbot
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.
Supporting appliance based tunnels would probably be a clear path for this project. Challenges may involve key handling and gateway/provider management. If there were a dependable, native API this could make it all the easier.
My little project so far has been biased towards (a surplus of) redundant commodity hardware. The environment where this evolved includes a very early MIPS32 based router so tunneling/proxying/resolving were not an option there.
I'm most definitely inspired here to see about supporting this kind of configuration! pfsense/opnsense have been on my list for years.
Thank you very much. In fact, the more challenging comments and questions inspire new ideas and shine light on knowledge gaps. Some of the funner comments help sharpen my dulling wit.