search

louislam / uptime-kuma

A fancy self-hosted monitoring tool
https://uptime.kuma.pet
MIT License
60.35k stars 5.4k forks source link

Uptime kuma appears to only bind to primary nic #5262

Closed miversen33 closed 4 weeks ago

miversen33 commented 4 weeks ago

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

🛡️ Security Policy

📝 Describe your problem

Likely related to #3194

I am using the binary installation of uptime kuma in an LXC running on Proxmox. My LXCs tend to have 2 Nics. 1 for non-vm traffic (IE, google, other physical machines on my LAN, etc etc) and 1 for internal traffic (virtual machines).

In this case, it seems my primary Nic for my LXC is my Virtual Machine interface (for the sake of this post, lets call that eth1). My secondary Nic (eth0) is unaccessible within uptime-kuma it seems

Uptime Kuma can communicate over eth1 just fine, talking to all devices available on there, and resolving DNS over this Nic with no issues. However, it cannot talk over eth0.

I validated this by setting up a ping test with uptime kuma to a machine with a hardcoded IP address.

image

As we see in the screenshot, uptime kuma cannot reach this. The logs indicate this as well

Oct 28 03:56:40 uptime-kuma node[2279]: 2024-10-27T22:56:40-05:00 [MONITOR] WARN: Monitor #2 'Nas': Failing:  | Interval: 30 seconds | Type: ping | Down Count: 0 | Resend Interval: 0

To sanity check, I pinged this IP from the uptime-kuma host image

As we see in the screenshot, it is completely accessible.

I went so far as to run tcpdump on the host, binding specifically to eth1 (as that is the nic it would need to communicate over to get to nas) and there is absolutely no traffic during that ping test in uptime-kuma.

As a second sanity check, I setup a DNS check for google.com, using 1.1.1.1 as the DNS server. This too would have to go through eth1 in order to resolve.

image

And indeed it also cannot complete image

The logs show that it is unable to complete the DNS query

Oct 28 03:56:57 uptime-kuma node[2279]: 2024-10-27T22:56:57-05:00 [MONITOR] WARN: Monitor #5 'Google.com': Failing: queryA ETIMEOUT google.com | Interval: 60 seconds | Type: dns | Down Count: 0 | Resend Interval: 0
Oct 28 03:58:21 uptime-kuma node[2279]: 2024-10-27T22:58:21-05:00 [MONITOR] WARN: Monitor #5 'Google.com': Failing: queryA ETIMEOUT google.com | Interval: 60 seconds | Type: dns | Down Count: 0 | Resend Interval: 0

Is there anything I can do to make uptime-kuma not bind to 1 nic?

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

Ubuntu 22.04

🌐 Browser

NA

🖥️ Deployment Environment

miversen33 commented 4 weeks ago

Quick edit, I did also try using 'PING' on another service on the eth0 (the known functioning nic) and it also failed. It appears that the ping health check is not providing ICMP packets? The tcpdump looks different when uptime-kuma sends its pings as opposed to when I execute a ping from the cli.

For reference, I do have other healthchecks working (https seems to be working just fine), so there may just generally be some weirdness with how the Ping health check works?

To clarify, this second attempt at Ping is using the proper NIC, I can see the communication on both sides, but it doesn't seem like an ACK is ever provided on either side. So I am not exactly sure what is going on with PING here. Possibly a different issue than the one I reported which is related to not binding to all available NICs

louislam commented 4 weeks ago

It could be a Docker's limitation.

Try to ping inside the container: https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

miversen33 commented 4 weeks ago

As explained in the issue, I am not running this in docker

I am using the binary installation of uptime kuma in an LXC running on Proxmox. My LXCs tend to have 2 Nics. 1 for non-vm traffic (IE, google, other physical machines on my LAN, etc etc) and 1 for internal traffic (virtual machines).

CommanderStorm commented 4 weeks ago

You should be able to configure which IP-Adress (thus also which interface) Uptime Kuma is served on via the HOST Environment variable.

Having multiple nic's is not something which we have a testcase for notification providers and monitors. We use node and don't set localAddress => We use the defaults. I don't know if the defaults work with the networking configuration you need. Hard to tell from the docs.

I also would CURRENTLY prefer to not add this as a feature to not further complicate this part. That code is already thoroughly undertested and pretty messy.

Trying to solve your issue: It should be possible to simply link aggregate your two nics into one nic and then use that one going foreward as your default nic.

miversen33 commented 4 weeks ago

I'll check that recommendation out :)

Ya I wouldn't recommend allowing NIC configuration, I would assume it has access to all NICs, though that doesn't seem to be the case.

I haven't heard of a link aggregate, I'll have to check that out.

CommanderStorm commented 4 weeks ago

I'll have to check that out

My networking knowlege is pretty basic.. Please remember to post your findings

miversen33 commented 4 weeks ago

I went down the rabbit hole of trying to setup a bond with the 2 NICs using systemd-network and while I was able to get it "setup", I could not get the bond NIC to come online.

I eventually just gave up and decided to have everything go through the main LAN NIC. I am not fond of this solution as that is alot of "internal" traffic (all the VMs are on the same physical hardware) but I don't want to dick around with bond NICs more.

It would be pretty cool if this behaved like most other systems in how it talks to the network :/

CommanderStorm commented 4 weeks ago

It would be pretty cool if this behaved like most other systems

seems like this has not been reported to the node team https://github.com/nodejs/node/issues?q=is%3Aissue+nic

Feel free to request this feature there if you need it

Issue seems resolved as and I don't have more resources to throw at the problem => closing as resolved