[SOLVED] LXC-Container und ping: Seltsames Problem mit der Erreichbarkeit

W

whiterabbit

Renowned Member
Proxmox Subscriber
Dec 19, 2012
525
18
83
Hallo.
Ich habe als LXC-Container auf einem Proxmox-Host einen RustDesk-Server im eigenen Netzwerk laufen. Die Installation lief problemlos über die

Proxmox VE Helper-Scripts (https://community-scripts.github.io/ProxmoxVE/scripts?id=rustdeskserver)​

Der Container ist über das Webinterface und seine IP erreichbar (auch über ping). Zudem sind auf der Firewall die NAT-Regeln eingerichtet, so dass der Zugriff auch über eine VPN-Verbindung bereits funktioniert. Wenn ich hier auf meinem lokalen Rechner über VPN den lokalen RustDesk-Client starte, sehe ich auch, dass die Verbindung zum Vermittlungsdienst erfolgreich aufgebaut werden konnte ("Bereit"). Soweit so gut.

Nun wird's allerdings seltsam: Wenn man länger nichts auf dem Proxmox-Server oder dem LXC-Container gemacht hat, scheint der Container "offline" zu gehen oder nicht mehr richtig zu reagieren?! Das sieht man daran, dass kein ping mehr durchgeht und auch, dass die WebUI vom RustDesk-Server plötzlich nicht mehr erreicht werden kann. Wenn ich dann über Proxmox in die Console des Containers wechsele, dauert der ping auf einen anderen Rechner auch etwas ... erst dann läuft wieder alles normal und auch das Icon im RustDesk-Client wechselt wieder auf grün ("Bereit"). Es scheint so zu sein, dass der Container zwischendurch offline ist oder "sich schlafen legt" oder so ähnlich? Hat jemand eine Idee, wonach man hier schauen kann? Ist das eine LXC-Einstellung, die da nicht stimmt oder was kann das sonst sein?

Besten Dank für einen Tipp.
 
Zwei Auffälligkeiten in der Ausgabe:
Online state: unknown: systemd-networkd überwacht den Online-Status nicht aktiv
eth0: Lost carrier - Gained carrier : Das interface verliert kurz die Verbindung beim Start (hier nur beim Boot, aber das könnte auch im Betrieb passieren)

Diagnose im Container:
journalctl -u systemd-networkd --no-pager | grep -i "carrier"
Das zeigt, ob der Carrier auch nach dem Start verloren geht

Netzwerk-Konfiguration anschauen
cat /etc/systemd/network/*.network

RustDesk-Dienste prüfen
systemctl status rustdesk-hbbs rustdesk-hbbr

Auf dem Proxmox-Host:
# Netzwerk-Bridge prüfen:
ip link show vmbr0
Die Carrier-Logs sind hier der wichtigste Hinweis, wenn eth0: Lost carrier auch im laufenden Betrieb auftaucht, haben wir die Ursache gefunden.
 
Hallo.
Danke für die Hinweise. Ich habe das geprüft. Also der Reihe nach:
Code: 
journalctl -u systemd-networkd --no-pager | grep -i "carrier"
liefert nur diese 4 Einträge für vorgestern. Das deutet auf den Systemstart hin:
Feb 17 19:21:40 rustdeskserver systemd-networkd[209]: lo: Gained carrier
Feb 17 19:21:40 rustdeskserver systemd-networkd[209]: eth0: Gained carrier
Feb 17 19:21:40 rustdeskserver systemd-networkd[209]: eth0: Lost carrier
Feb 17 19:21:40 rustdeskserver systemd-networkd[209]: eth0: Gained carrier
Dann kam:
Code: 
cat /etc/systemd/network/*.network

Da wurde nichts gefunden (leeres Verzeichnis). Aber die Datei

/etc/systemd# cat networkd.conf

existiert und sieht so aus (default, nehme ich an):

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/networkd.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/networkd.conf' to display the full config.
#
# See networkd.conf(5) for details.

[Network]
#SpeedMeter=no
#SpeedMeterIntervalSec=10sec
#ManageForeignRoutingPolicyRules=yes
#ManageForeignRoutes=yes
#ManageForeignNextHops=yes
#RouteTable=
#IPv6PrivacyExtensions=no
#UseDomains=no

[IPv6AcceptRA]
#UseDomains=

[DHCPv4]
#DUIDType=vendor
#DUIDRawData=
#UseDomains=

[DHCPv6]
#DUIDType=vendor
#DUIDRawData=
#UseDomains=

[DHCPServer]
#PersistLeases=yes

Und zuletzt noch:

Code: 
systemctl status rustdesk-hbbs rustdesk-hbbr

● rustdesk-hbbs.service - Rustdesk Signal Server
     Loaded: loaded (/usr/lib/systemd/system/rustdesk-hbbs.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-02-17 19:21:40 CET; 1 day 14h ago
 Invocation: 72e549f47ee706dfad
   Main PID: 91 (hbbs)
      Tasks: 7 (limit: 38143)
     Memory: 8.4M (peak: 10.8M)
        CPU: 22.035s
     CGroup: /system.slice/rustdesk-hbbs.service
             └─91 /usr/bin/hbbs

Feb 17 19:21:40 rustdeskserver systemd[1]: Started rustdesk-hbbs.service - Rustdesk Signal Server.

● rustdesk-hbbr.service - Rustdesk Relay Server
     Loaded: loaded (/usr/lib/systemd/system/rustdesk-hbbr.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-02-17 19:21:40 CET; 1 day 14h ago
 Invocation: 6671c1b7eb24c5ba
   Main PID: 90 (hbbr)
      Tasks: 4 (limit: 38143)
     Memory: 2.1M (peak: 3.3M)
        CPU: 4.217s
     CGroup: /system.slice/rustdesk-hbbr.service
             └─90 /usr/bin/hbbr

Feb 17 19:21:40 rustdeskserver systemd[1]: Started rustdesk-hbbr.service - Rustdesk Relay Server.

Auf dem PVE-Host:
Code: 
ip link show vmbr0

5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a0:... brd ff:...

Sieht eigentlich alles normal aus, oder?
 
Ja, sieht alles normal aus, Carrier OK, RustDesk OK, Bridge UP
Es ist fast sicher ein ARP-Problem
Da der Container keinerlei eigenen Netzwerk-Traffic erzeugt, wenn niemand den RustDesk-Server nutzt, passiert Folgendes:
- Gateway/Router hat ARP-Eintrag für 192.168.20.40, läuft nach 15-30 Min. ab
- Gateway "vergisst" die MAC-Adresse des Containers
- Container ist nicht mehr erreichbar (kein Ping, keine WebUI)
- Sobald du die Konsole öffnest und irgendwas machst -> ARP wird erneuert ->alles geht wieder

Lösung (im Container): systemd-Timer einrichten

# Timer-Unit erstellen
cat > /etc/systemd/system/keepalive.timer << 'EOF'
[Unit]
Description=Network keepalive timer

[Timer]
OnBootSec=60
OnUnitActiveSec=120

[Install]
WantedBy=timers.target
EOF


# Service-Unit erstellen (Gateway-IP anpassen!)
cat > /etc/systemd/system/keepalive.service << 'EOF'
[Unit]
Description=Network keepalive ping

[Service]
Type=oneshot
ExecStart=/usr/bin/ping -c 1 -W 2 GATEWAY-IP
EOF


# Aktivieren und starten
systemctl daemon-reload
systemctl enable --now keepalive.timer

!!! Ersetze GATEWAY-IP durch die tatsächliche Gateway-Adresse des Containers (die aus der networkctl status Ausgabe).

Prüfen:

# Timer-Status prüfen:
systemctl list-timers keepalive.timer
# Nach ein paar Stunden: Ist der Container noch erreichbar?

Damit pingt der Container alle 2 Minuten das Gateway an und hält den ARP-Eintrag aktiv. Der Ressourcenverbrauch ist dabei vernachlässigbar.

Alternativ über cron (systemd ist aber der bevorzugte Weg):
echo "*/2 * * * * root ping -c 1 -W 2 GATEWAY-IP > /dev/null 2>&1" > /etc/cron.d/keepalive
 
HI.
Danke für die neuen Ideen — sehr erhellend!
Das kann schon sein, dass es das ist. Ich habe einen Ping in einer „normalen VM“ laufen lassen, der durchgängig lief. Nur bei dem LXC-Container stockt es.
Aber das Gateway ist in diesem Netzwerk eine OPNSense-Firewall. Die hat für den Rustdesk-Server dessen IP- und MAC-Adresse im ISC-DHCP4 fest eingetragen. Daher dürfte die OPNSense diesen Eintrag doch eigentlich nicht vergessen, oder?
 
Last edited:
DHCP-Reservierung ist nicht dasselbe wie ein ARP-Eintrag, sas sind zwei komplett unterschiedliche Mechanismen:

Die DHCP-Reservierung sorgt nur dafür, dass der Container immer dieselbe IP bekommt. Trotzdem kann der ARP-Cache auslaufen, denn dort steht die Zuordnung: Welche MAC-Adresse gehört zu dieser IP. Wenn dann längere Zeit kein Traffic fließt, verschwindet der ARP-Eintrag und die Erreichbarkeit wirkt plötzlich „weg“. Dein VM-Test passt dazu.
Dass die VM mit dauerhaft laufendem Ping erreichbar bleibt, stürtzt die Theorie. Der konstante Ping-Traffic verhindert, dass der ARP-Eintrag abläuft.

Zwei mögliche Lösungen:

1. Keepalive im Container
Ein kleiner Cron-Job oder ein systemd-Timer, der regelmäßig ein Paket sendet. Ist zuverlässig

2. Statischen ARP-Eintrag auf OPNsense setzen
Das lässt sich direkt auf dem Gateway sauber lösen:
Services → ISC DHCPv4 → [Subnetz] → Eintrag für den RustDesk-Server
Dort gibt es die Option „ARP Table Static Entry“ (Checkbox). Wenn du sie aktivierst, legt OPNsense einen permanenten ARP-Eintrag an, der nicht abläuft. Ganz unabhängig davon, ob der Container gerade Traffic erzeugt oder nicht.
Das ist die sauberste Variante, weil sie die Ursache auf dem Gateway behebt, statt im Container nur Symptome zu überdecken.
 
  • Like
Reactions: Johannes S and whiterabbit
Super. Das probiere ich aus und melde mich dann.
Besten Dank.

Die Warnung in der OPNSense bei den "globalen Optionen" habe ich gesehen: "Warnung: Diese Option wird auch gespeichert, wenn der DHCP-Server deaktiviert ist. Nur die Maschinen, die unten gelistet sind, können mit der Firewall auf dieser NIC kommunizieren. " --
daher habe ich das nun zunächst mal nur für diesen einzelnen Container aktiviert. Mal sehen, ob es nun besser läuft...
 
Last edited:
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom
Back