Netzwerk Probleme bei einem Nginx Proxy Manager CT

nimblefox said:
Wenn ich den befehl update ausführe kommt die fehlermeldung curl: (6) Could not resolve host: raw.githubusercontent.com
Click to expand...
Frag mal bei den Erstellern dieses Scriptes nach, ob möglicherweise irgendwas offline ist.
Und warum ist da ein parent: predeb13 in deiner LXC config?
 
Ernst T. said:
Frag mal bei den Erstellern dieses Scriptes nach, ob möglicherweise irgendwas offline ist.
Und warum ist da ein parent: predeb13 in deiner LXC config?
Click to expand...
Das update problem hat sich schon erledigt. Aktuell ist nur noch das problem, dass die proxys nicht wirklich funktionieren (laut NPM sind sie online, beim aufruf kommt es aber immer zu einem timeout)
Der parent ist da, weil ich einen snapshot machen wollte, bevor ich auf Debian 13 geupgraded habe
 
nimblefox said:
bevor ich auf Debian 13 geupgraded habe
Click to expand...
Aha verstehe.

Zertifikat hast du erstellt? NPM ist manchmal sehr wählerisch bei den Einstellungen. Ich hab einige Dienste die zB: http + Force SSL wollen andere laufen mit https (mit oder ohne Force SSL)
 
Ernst T. said:
Aha verstehe.

Zertifikat hast du erstellt? NPM ist manchmal sehr wählerisch bei den Einstellungen. Ich hab einige Dienste die zB: http + Force SSL wollen andere laufen mit https (mit oder ohne Force SSL)
Click to expand...
Nicht sicher, ob ich das SSL Zertifikat selbst erstellt habe (ist halt n let's encrypt ding)
Würde aber immer noch nicht erklären, wieso das problem erst nach meinem Speicher und IPv4 Problem aufgekommen ist
 
Hallo @nimblefox, das ist ein klassisches DNS-Problem im Container — er kann keine Hostnamen auflösen. Bitte poste die Ausgabe folgender Befehle im Container:
Code: 
cat /etc/resolv.conf
ping -c 3 8.8.8.8
ip a
ip r
Der ping auf die IP zeigt, ob grundsätzlich Netzwerk vorhanden ist oder ob es wirklich nur DNS betrifft.

Zusätzlich bitte auf dem Host:
Code: 
cat /etc/pve/lxc/<CT-ID>.conf
(wobei <CT-ID> die ID deines NPM-Containers ist)
 
Bu66as said:
Hallo @nimblefox, das ist ein klassisches DNS-Problem im Container — er kann keine Hostnamen auflösen. Bitte poste die Ausgabe folgender Befehle im Container:
Code: 
cat /etc/resolv.conf
ping -c 3 8.8.8.8
ip a
ip r
Der ping auf die IP zeigt, ob grundsätzlich Netzwerk vorhanden ist oder ob es wirklich nur DNS betrifft.

Zusätzlich bitte auf dem Host:
Code: 
cat /etc/pve/lxc/<CT-ID>.conf
(wobei <CT-ID> die ID deines NPM-Containers ist)
Click to expand...
Danke für die Nachricht. Die meisten dieser Befehle finden sie im Verlauf des threads. aktuell funktioniert der DNS dienst auch wieder, nur die Proxies sind nicht erreichbar. ich habe das update jetzt auch im haupt-post hingeschrieben
 
Hallo @nimblefox,

Das OpenResty-Problem ist repo-seitig. Debian Trixie verwendet sqv zur Signaturprüfung, und seit 2026-02-01 werden SHA1-basierte Binding-Signaturen abgelehnt. Der OpenResty-Signing-Key nutzt noch SHA1 — das muss upstream gefixt werden.

Als Workaround kannst du das OpenResty-Repo vorerst deaktivieren, da es vom NPM-Build stammt und für den laufenden Betrieb nicht zwingend benötigt wird:
Code: 
mv /etc/apt/sources.list.d/openresty.list /etc/apt/sources.list.d/openresty.list.disabled
apt update
Zum ursprünglichen DHCP-Problem: Dass der CT nach Node-Reboot wieder eine IPv4 bekommt, deutet auf ein Timing- oder Bridge-Problem hin. Falls das erneut auftritt, prüfe im CT:
Code: 
ip a
ip r
journalctl -u networking.service
Und auf dem Node:
Code: 
brctl showmacs vmbr0 | grep "bc:24:11:70:78"
Das zeigt ob der veth des CTs korrekt in der Bridge registriert ist. Speedport-Router sind bekannt dafür, bei DHCP-Requests von virtuellen MACs gelegentlich Probleme zu machen. Falls das öfter vorkommt, wäre eine statische IP für den NPM-CT die zuverlässigere Lösung.
 
Bu66as said:
Hallo @nimblefox,

Das OpenResty-Problem ist repo-seitig. Debian Trixie verwendet sqv zur Signaturprüfung, und seit 2026-02-01 werden SHA1-basierte Binding-Signaturen abgelehnt. Der OpenResty-Signing-Key nutzt noch SHA1 — das muss upstream gefixt werden.

Als Workaround kannst du das OpenResty-Repo vorerst deaktivieren, da es vom NPM-Build stammt und für den laufenden Betrieb nicht zwingend benötigt wird:
Code: 
mv /etc/apt/sources.list.d/openresty.list /etc/apt/sources.list.d/openresty.list.disabled
apt update
Zum ursprünglichen DHCP-Problem: Dass der CT nach Node-Reboot wieder eine IPv4 bekommt, deutet auf ein Timing- oder Bridge-Problem hin. Falls das erneut auftritt, prüfe im CT:
Code: 
ip a
ip r
journalctl -u networking.service
Und auf dem Node:
Code: 
brctl showmacs vmbr0 | grep "bc:24:11:70:78"
Das zeigt ob der veth des CTs korrekt in der Bridge registriert ist. Speedport-Router sind bekannt dafür, bei DHCP-Requests von virtuellen MACs gelegentlich Probleme zu machen. Falls das öfter vorkommt, wäre eine statische IP für den NPM-CT die zuverlässigere Lösung.
Click to expand...
ich habe mich für die statische ip entschieden, da das bei port freigaben auch eine zuverlässigere lösung ist.
aktuell besteht noch mein problem mit den nicht erreichbaren proxies, was ich zu einem teil auf jeden fall auf einen ddclient zurückschließen konnte, der die curl befehle für das erhalten der eigenen ipv4 nicht durchführen kann. wenn ich den client über das terminal vom CT einmal ausführe kommt folgende fehlermeldung:
Bash: 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0WARNING:  found neither IPv4 nor IPv6 address
WARNING:  *.[MeineDomain].de: unable to determine IP address with strategy use=cmd
WARNING:  Could not determine an IP for *.[MeineDomain].de
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0WARNING:  found neither IPv4 nor IPv6 address
WARNING:  [MeineDomain].de: unable to determine IP address with strategy use=cmd
WARNING:  Could not determine an IP for [MeineDomain].de
WARNING:  caught SIGINT; exiting

wenn ich versuche, web als strategy zu nutzen, kommt folgende fehlermeldung:

Bash: 
WARNING:  curl cannot connect to https://api.ipify.org using IPv0
WARNING:  found neither IPv4 nor IPv6 address
WARNING:  *.[MeineDomain].de: unable to determine IP address with strategy use=web
WARNING:  Could not determine an IP for *.[MeineDomain].de
WARNING:  curl cannot connect to https://api.ipify.org using IPv0
WARNING:  found neither IPv4 nor IPv6 address
WARNING:  [MeineDomain].de: unable to determine IP address with strategy use=web
WARNING:  Could not determine an IP for [MeineDomain].de
WARNING:  caught SIGINT; exiting
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back