How to confirm docker container has active VPN access

[truthsword]

⚠️ Please verify that this question has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

I run a qbittorrent container which connects to the 'net via a glutetun vpn container.

I've seen how to monitor the qbittorrent container with Uptime Kuma, but that only tells me whether the qbittorrent container is up (or down).

However... more frequently than I desire, the qbittorrent container “loses” its connection with the VPN, and has no connectivity (even though the container is up).

I'd like a way to test the qbittorrent container's VPN connectivity. One way I've considered is to run curl ipconfig.io from within the container. How might I do that with Uptime Kuma. I would want an alert when the curl command failed.

Is this possible? Thank you.

📝 Error Message(s) or Log

No error.

🐻 Uptime-Kuma Version

Uptime Kuma Version: 1.23.13 Frontend Version: 1.23.13

💻 Operating System and Arch

Debian 12

🌐 Browser

LibreWolf 126.0.1-1

🖥️ Deployment Environment

• Runtime: Client: Docker Engine - Community Version: 26.1.3

[CommanderStorm]

Have you tried to use the http-monitor?
That is our equivalent to curl example.com

[truthsword]

I'm not sure how I would pass that through the container using http-monitor. For example, from the container host command line, I use:
docker exec -it <container_name> curl ipconfig.io

When things are working that returns the VPN IP. When not, the command fails. Maybe I'm overlooking something basic here.

[cvsickle]

Not sure if you've sorted out your issue or not, but I struggled with this at one point.

I used TCP port monitors in Uptime Kuma on the TCP ports that the Gluetun container exposes for all the containers that use it for their network. Those ports showed as down until the containers were restarted.

For fun: at one point, I had uptime kuma send a webhook notification to Home Assistant, which triggered an automation to restart the relevant containers. This worked okay, but I ended up discovering that I can just create a healthcheck for the relevant contianers, and let autoheal restart them. That ended up being the best solution for me, even though I still keep the TCP ports monitored in Uptime Kuma.

In case it helps, here's the health check I added to any containers using the gluetun vpn container as their network:

healthcheck:
    test: curl -s ifconfig.me || exit 1
    interval: 20s
    timeout: 5s
    retries: 2
    start_period: 15s

[truthsword]

I used TCP port monitors in Uptime Kuma on the TCP ports that the Gluetun container exposes for all the containers that use it for their network. Those ports showed as down until the containers were restarted.

This is brilliant. And your heath check code looks good. My approach has been much cruder, using restarter to restart the container at 4 hour intervals. Inevitably that breaks some nice download streams.

This is also helpful when the gluetun container is updated, which breaks connection with most of its client containers.

I'll give this a try.

[CommanderStorm]

When things are working that returns the VPN IP.

Great, so you do a keyword monitor on https://ifconfig.me and expect the VPN IP.
Alternatively, you can build an arbitrairly complex json-query if your VPN does rotate IPs/...
Am I missing something?

When not, the command fails

If you don't care about the result and instead just care about the status code, you can use the http monitor

[truthsword]

If you don't care about the result and instead just care about the status code, you can use the http monitor

Maybe I'm too dense, but the http monitor fields don't seem to fit the commands I use. For example, from the host CLI I enter...

docker exec -it qbittorrent curl ipconfig.io [which normally returns simply 123.456.789.012]

Alternately I can open a bash console from with the qbittorrent container and enter...

curl ipconfig.io

Doing this:

doesn't tell me the status of the qbittorrent container's connection.

It's possible I'm misunderstanding your use of the http monitor.

[cvsickle]

When things are working that returns the VPN IP.

Great, so you do a keyword monitor on https://ifconfig.me and expect the VPN IP. Alternatively, you can build an arbitrairly complex json-query if your VPN does rotate IPs/... Am I missing something?

When not, the command fails

If you don't care about the result and instead just care about the status code, you can use the http monitor

I'm not the person you responded to. Assuming I'm understanding correctly, the issue the OP is having is that the container in question loses all network connection when the VPN container is restarted for any reason. The container still shows as running, but there's no network communication in or out. The TCP Port monitor works great for this scenario, because all traffic on that port will be blocked until the container is restarted and network connectivity is restored.