Netzwerk Probleme bei einem Nginx Proxy Manager CT

dann entsteht das problem, dass mein router dem eine neue IPv4 verteilen müsste, was er wie gesehen schon nicht macht
 
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
 
Ahh Sorry, dann hab ich da was falsch verstanden.

Vor dem Update hat NPM also schon funktioniert?
 
Impact said:
Wie das?
Click to expand...
Habe die alte IPv4 als statische zugewiesen und nach einem neustart war eine verbindung wiederhergestellt (vermutlich, weil der ct nur ipv6 hatte und mein Heimnetz kein ipv6 ins internet hat) siehe #19 ab zeil
 
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:
Das "IPv0" in der Fehlermeldung ist der Hinweis. Das passiert wenn ddclient nicht weiß ob er IPv4 oder IPv6 nutzen soll. Poste mal deine ddclient-Konfig:
Code: 
cat /etc/ddclient.conf
Vermutlich fehlt da ein usev4=webv4 oder es steht was Falsches drin. Teste auch mal ob curl generell aus dem CT rauskommt:
Code: 
curl -4 https://api.ipify.org
Wenn das hängt oder fehlschlägt, hat der CT ein Problem mit ausgehendem HTTPS-Traffic (Port 443). Dann wäre interessant was iptables -L -n auf dem Host zeigt, ob da irgendwelche Regeln den Traffic blockieren.
 
Bu66as said:
Das "IPv0" in der Fehlermeldung ist der Hinweis. Das passiert wenn ddclient nicht weiß ob er IPv4 oder IPv6 nutzen soll. Poste mal deine ddclient-Konfig:
Code: 
cat /etc/ddclient.conf
Vermutlich fehlt da ein usev4=webv4 oder es steht was Falsches drin. Teste auch mal ob curl generell aus dem CT rauskommt:
Code: 
curl -4 https://api.ipify.org
Wenn das hängt oder fehlschlägt, hat der CT ein Problem mit ausgehendem HTTPS-Traffic (Port 443). Dann wäre interessant was iptables -L -n auf dem Host zeigt, ob da irgendwelche Regeln den Traffic blockieren.
Click to expand...
der output vom cat (sicherheitsbereinigt):

Bash: 
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

protocol=dyndns2 \
usev4=webv4, webv4=https://checkipv4.dedyn.io/ \
server=update.dedyn.io \
login=[Mail]@gmail.com \
password='[Passwort]' \
[MeineDomain].de, *.[MeineDomain].de
das usev4 hatte ich bereits geändert, weil ich dachte, dass es daran liegen könnte
Hier der output (bereinigt) nach der Änderung der strategy:
Bash: 
WARNING:  curl cannot connect to https://checkipv4.dedyn.io using IPv4
WARNING:  *.[MeineDomain].de: unable to determine IPv4 address with strategy usev4=webv4
WARNING:  Could not determine an IP for *.[MeineDomain].de
WARNING:  curl cannot connect to https://checkipv4.dedyn.io using IPv4
WARNING:  [MeineDomain].de: unable to determine IPv4 address with strategy usev4=webv4
WARNING:  Could not determine an IP for [MeineDomain].de
WARNING:  caught SIGINT; exiting
Einen Curl befehl einfach so im CT auszuführen funktioniert nicht, es gibt einfach keine Antwort und meine ungeduld macht dann einfach Strg+C.
Und hier einmal die ip-tables:
Bash: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
was ich anhand der daten machen muss, weiß ich nicht. Das müsste man mir bitte sagen.
 
OK, iptables ist sauber. Wenn curl hängt ohne Antwort, deutet das auf ein Routing- oder MTU-Problem hin.
Poste mal die Ausgabe aus dem CT:
Code: 
ip a
ip r
curl -4 -v https://api.ipify.org 2>&1 | head -20
ping -c 3 -s 1400 -M do 192.168.1.1
Das curl -v zeigt, wo er hängen bleibt (DNS, TCP-Connect, TLS-Handshake), und der Ping mit 1400 Byte testet, ob große Pakete durchkommen. Wenn der Ping mit -s 1400 fehlschlägt aber mit -s 1000 klappt, hast du ein MTU-Problem.
Teste auch, ob HTTP funktioniert:
Code: 
curl -4 http://icanhazip.com
Wenn HTTP geht aber HTTPS nicht, ist es ein MTU-Ding. Speedport-Router sind da manchmal zickig mit der Path MTU Discovery.
 
Bu66as said:
OK, iptables ist sauber. Wenn curl hängt ohne Antwort, deutet das auf ein Routing- oder MTU-Problem hin.
Poste mal die Ausgabe aus dem CT:
Code: 
ip a
ip r
curl -4 -v https://api.ipify.org 2>&1 | head -20
ping -c 3 -s 1400 -M do 192.168.1.1
Das curl -v zeigt, wo er hängen bleibt (DNS, TCP-Connect, TLS-Handshake), und der Ping mit 1400 Byte testet, ob große Pakete durchkommen. Wenn der Ping mit -s 1400 fehlschlägt aber mit -s 1000 klappt, hast du ein MTU-Problem.
Teste auch, ob HTTP funktioniert:
Code: 
curl -4 http://icanhazip.com
Wenn HTTP geht aber HTTPS nicht, ist es ein MTU-Ding. Speedport-Router sind da manchmal zickig mit der Path MTU Discovery.
Click to expand...
hier einmal ein quasi dump von all den befehlen:
Bash: 
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:70:78:23 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.122/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2003:ca:4706:15b9:be24:11ff:fe70:7823/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 172783sec preferred_lft 86383sec
    inet6 fe80::be24:11ff:fe70:7823/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

# ip r
default via 255.255.255.255 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.122
255.255.255.255 dev eth0 scope link

# curl -4 -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host api.ipify.org:443 was resolved.
* IPv6: (none)
* IPv4: 172.67.74.152, 104.26.12.205, 104.26.13.205
*   Trying 172.67.74.152:443...
  0     0    0     0    0     0      0      0 --:--:--  0:02:14 --:--:--     0* connect to 172.67.74.152 port 443 from 192.168.1.122 port 46072 failed: Connection timed out
  0     0    0     0    0     0      0      0 --:--:--  0:02:14 --:--:--     0*   Trying 104.26.12.205:443...
  0     0    0     0    0     0      0      0 --:--:--  0:03:36 --:--:--     0* ipv4 connect timeout after 82616ms, move on!
*   Trying 104.26.13.205:443...
  0     0    0     0    0     0      0      0 --:--:--  0:04:59 --:--:--     0* Connection timed out after 300483 milliseconds
  0     0    0     0    0     0      0      0 --:--:--  0:05:00 --:--:--     0
* closing connection #0
curl: (28) Connection timed out after 300483 milliseconds

#ping
PING 192.168.1.1 (192.168.1.1) 1400(1428) bytes of data.
1408 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.628 ms
1408 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.479 ms
1408 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.580 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2053ms
rtt min/avg/max/mdev = 0.479/0.562/0.628/0.062 ms

#curl -4 -v http
# -v um zuzusehen
* Host icanhazip.com:80 was resolved.
* IPv6: (none)
* IPv4: 104.16.185.241, 104.16.184.241
*   Trying 104.16.185.241:80...
* connect to 104.16.185.241 port 80 from 192.168.1.122 port 43600 failed: Connection timed out
*   Trying 104.16.184.241:80...
* connect to 104.16.184.241 port 80 from 192.168.1.122 port 41294 failed: Connection timed out
* Failed to connect to icanhazip.com port 80 after 269936 ms: Could not connect to server
* closing connection #0
curl: (28) Failed to connect to icanhazip.com port 80 after 269936 ms: Could not connect to server
ist es also ein mtu problem? wenn ja: was kann/soll ich machen?
 
Last edited:
Kein MTU-Problem, der Ping mit 1400 Byte geht ja durch. Und HTTP scheitert auch, also ist es nicht TLS-spezifisch.
Das Problem ist deine Routing-Tabelle:
Code: 
default via 255.255.255.255 dev eth0
Das ist Quatsch als Gateway. Da muss dein Router stehen, also 192.168.1.1. Deshalb kommt nix ins Internet raus, obwohl lokal alles geht.
Zum Testen im CT:
Code: 
ip route replace default via 192.168.1.1 dev eth0
curl -4 https://api.ipify.org
Wenn das klappt, musst du das noch dauerhaft eintragen. Geh in die Proxmox WebUI auf den CT -> Netzwerk -> eth0, und trag als Gateway 192.168.1.1 ein (nicht vergessen: CT danach neu starten). Vermutlich hast du beim Umstellen auf statische IP das Gateway-Feld einfach leer gelassen oder falsch eingetragen.
 
  • Like
Reactions: nimblefox and UdoB
Bu66as said:
Kein MTU-Problem, der Ping mit 1400 Byte geht ja durch. Und HTTP scheitert auch, also ist es nicht TLS-spezifisch.
Das Problem ist deine Routing-Tabelle:
Code: 
default via 255.255.255.255 dev eth0
Das ist Quatsch als Gateway. Da muss dein Router stehen, also 192.168.1.1. Deshalb kommt nix ins Internet raus, obwohl lokal alles geht.
Zum Testen im CT:
Code: 
ip route replace default via 192.168.1.1 dev eth0
curl -4 https://api.ipify.org
Wenn das klappt, musst du das noch dauerhaft eintragen. Geh in die Proxmox WebUI auf den CT -> Netzwerk -> eth0, und trag als Gateway 192.168.1.1 ein (nicht vergessen: CT danach neu starten). Vermutlich hast du beim Umstellen auf statische IP das Gateway-Feld einfach leer gelassen oder falsch eingetragen.
Click to expand...
Danke, das hat funktioniert.
 
You must log in or register to reply here.
Top Bottom
Back